Re: sha_block_data_order Crash
Hey Sam, Thanks for the response. I think that is the issue here. I was under the impression that configuring using the 'threads' option would be enough to make OpenSSL thread-safe. That was really helpful!! On Tue, Aug 24, 2010 at 9:23 PM, Sam Jantz wrote: > Have you explicitly made your application thread safe? There are four > functions that you need to implement to make the OpenSSL libraries > themselves thread safe. These are: > > static void locking_function(int mode, int n, const char * file, int line) > static unsigned long id_function(void) > int THREAD_setup(void) > and int THREAD_cleanup > > Once you have these implemented, you call THREAD_setup in the main thread > before you start spawning sub threads, and THREAD_cleanup during shutdown. > This will allow openssl to successfully run the multi threaded. > > For more information on how to implement these functions see the man page > for CRYPTO_set_locking_callback, and CRYPTO_set_id_callback > > I hope that this is new information, and not something you already knew. > > Cheers, > > Sam > > On Tue, Aug 24, 2010 at 6:37 AM, Sayan Chaliha > wrote: > >> Hey all, >> >> Under stressed conditions (multi-threaded apps with several threads using >> OpenSSL at the same time) the function RAND_bytes crashes consistently. >> Anybody have any idea why this is caused and if there's any solution for it? >> >> Attached: >> GDB `disassemble $rip` ourput from core dump. >> >> Stack trace: >> #0 sha1_block_data_order (c=0x2aab118ab4c0, p=, >> num=288230376151706362) at sha_locl.h:256 >> #1 0x2b302f4a1e13 in SHA1_Update (c=0x2aab118ab4c0, data_=> optimized out>, len=18446744073709551592) at ../md32_common.h:325 >> #2 0x2b302f5034ed in ssleay_rand_bytes (buf=0x46d25860 "", num=0) at >> md_rand.c:489 >> #3 0x2b302f502df6 in ssleay_rand_pseudo_bytes (buf=0x2022a54d0 >> , num=1933866968) at md_rand.c:533 >> >> OpenSSL version: 1.0.0a >> >> OS: CentOS 5.4 x86_64 >> >> -- >> Regards, >> Sayan Chaliha >> Webyog Softworks Private Limited >> 2nd Floor, Novel Team Building >> #10, 100 Feet Ring Road >> BTM Layout 1st Stage >> Bangalore - 560068 >> >> +91-9743357501 >> > > > > -- > Sam Jantz > Software Engineer > > -- Regards, Sayan Chaliha Webyog Softworks Private Limited 2nd Floor, Novel Team Building #10, 100 Feet Ring Road BTM Layout 1st Stage Bangalore - 560068 +91-9743357501
Re: SSL/TLS with server names picked from DNS
Hi! * sandeep kiran p wrote on Wed, Aug 11, 2010 at 20:36 -0700: > Ours is an LDAP client application that fetches LDAP server names on > the fly using DNS SRV Resource Records. We then randomly pick one the > servers returned from DNS, establish an SSL/TLS connection with that > server and then perform a bind operation using user credentials (DN > and password). User credentials are protected since everything goes > encrypted between the client and server. > > Recently we discovered that such a mechanism could be vulnerable to a > DNS spoofing attack where an attacker could modify (or drop) the > server list returned by the DNS and inject his/her own malicious > directory server name. Client would then blindly establish an SSL/TLS > connection with that server and would end up handing over the user > credentials to it. Note that, as part of the SSL handshake, the > malicious serve would provide a certificate signed by the same CA that > signed a genuine server certificate. I think this is a common pitfall: the server connected to is authenticated (i.e. it really is ldap.malicious.com) but it is not checked if the peer is /authorized/ to get the credentials. It is like asking someone to show his passport, verifying if the passport is authentic, but neither checking the name written on the passwort nor checking if it is on the guest list at all... If not everyone is authorized, I think you need some definition of permissions, like an association of DN and permissions or a white list. Don't know if major public CAs offer this, but maybe you also could define a dedicated property in the certificate (but all CAs you trust must guarantee to use this properties ONLY for this case - I guess it will become at least very expensive). But maybe some hostname white list is sufficient. This list must be authentic (hardcoded, local config file or dynamic file which is cryptographically signed), so non-DNSSEC'd TXT records won't help of course. But if you do not want to communicate with everyone, why rely on PKI, maybe you just want to have a local list of the certificates of authorized peers? PKI is good to authenticate everyone, without knowing in advance, but seems you do not want this, but just want to communicate with someone known/trusted/authorized in advance. Sometimes PKI seems to me like a hammer making every problem looking like a nail, but in turn it has to advantage that a well researched crypto system is used. Also it should be noted that in case of MITM the link from LDAP client to ldap.malicious.com IS secured! Only the attacker can read the traffic, ensured cryptographically! oki, Steffen --[ end of mail ]-->8=== About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Weird Validation Error
On 08/23/2010 06:19 PM, Bram Cymet wrote: Hi, Does any know of what would cause ctx->error to be set to 0 (X509_V_OK ) with a call to x509_verify_cert() that should result in X509_V_ERR_UNABLE_TO_GET_CRL. From the OpenSSL Source (x509_vfy.h) it looks like that would mean there were uninitialized values but is there anyway for me to figure out what these values are? Thanks, After a little more experimentation I have found that if I run x509_verify_cert() twice in a row with the same CTX everything works the way it is supposed to. The first time it returns 0 and CTX->current_cert is set to NULL. Then after it is run a second time the error is 3 (X509_V_ERR_UNABLE_TO_GET_CRL) and current cert set to something valid. Any idea what would cause this behavior? Could the application (kerberos) be setting up something wrong? Could there be something wrong with my certs? I am fairly sure that there is nothing wrong with my certs as I can run the validation just fine with the openssl command line tools. Thanks, -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. Cell: 613-608-9752 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Just Encryption Using Openssl
On 24-08-2010 15:14, Harshvir Sidhu wrote:
Ben,
theEncryptor::blowfish(unsigned char *data, int data_len, unsigned
char* key, unsigned char *ivec, int enc)
In this function you are passing key argument as char *, i am not
able to find alice's public key in char* format, we received that in 2
buffers and we put that in RSA struct. Which one should i use to pass in
here. Thanks.
// Harshvir
key here is the random key generated by Bob with the call to
ok = RAND_bytes(key, 64);
Bob has this key because he just made it.
Alice can get the key if Bob encrypts "key" with Alice's public
key (received earlier) and sends the encrypted key to Alice, who
can decrypt it with her private key.
By the way, I don't know why this code hashes a 64 byte random
key down to a 20 byte (160 bit) symmetric key, rather than just
exchanging a 20 byte symmetric key initially (I can think of
both good and bad reasons for this).
On Wed, Jul 21, 2010 at 10:07 AM, Ben Jones mailto:b...@bhjones.com>> wrote:
Ok, well assuming you're talking about C++ which is what I'm using,
then to create an RSA key pair you do:
// alice would do this
RSA *rsa = RSA_generate_key(bits, 65537, NULL, NULL);
// alice can then get the public part of the key and send to bob
const int max_hex_size = (bits / 4) + 1;
long size = max_hex_size;
char keyBufferA[size];
char keyBufferB[size];
bzero(keyBufferA,size);
bzero(keyBufferB,size);
sprintf(keyBufferA,"%s\r\n",BN_bn2hex(rsa->n));
sprintf(keyBufferB,"%s\r\n",BN_bn2hex(rsa->e));
int n = send(sock,keyBufferA,size,0);
char recBuf[2];
n = recv(sock,recBuf,2,0);
n = send(sock,keyBufferB,size,0);
n = recv(sock,recBuf,2,0);
// bob can then receive the public key, so on bob's end:
int max_hex_size = (bits / 4) + 1;
char keybufA[max_hex_size];
bzero(keybufA,max_hex_size);
char keybufB[max_hex_size];
bzero(keybufB,max_hex_size);
int n = recv(sock,keybufA,max_hex_size,0);
n = send(sock,"OK",2,0);
n = recv(sock,keybufB,max_hex_size,0);
n = send(sock,"OK",2,0);
rsa = RSA_new();
BN_hex2bn(&rsa->n, keybufA);
BN_hex2bn(&rsa->e, keybufB);
// bob can then generate symmetric key
unsigned char* key;
int n = RAND_bytes(key, bytes); // if n is 0 then system failed in
having enough entropy to gather a strong key and should be
//considered insecure
// bob can then encrypt key with alice's public key, in fact here is
a snippet of a function
// note ivec is an intialisation vector. This is often initialized
to 0 (but doing this is very insecure, but its useful
// to do this for testing purposes)
void
theEncryptor::blowfish(unsigned char *data, int data_len, unsigned
char* key, unsigned char *ivec, int enc)
{
// hash the key first!
unsigned char obuf[20];
bzero(obuf,20);
SHA1((const unsigned char*)key, 64, obuf);
BF_KEY bfkey;
int keySize = 20;//strlen((char*)key);
BF_set_key(&bfkey, keySize, obuf);
//unsigned char ivec[16];
//memset(ivec, 0, 16);
unsigned char* out=(unsigned char*) malloc(data_len);
bzero(out,data_len);
int num = 0;
// enc is whether to encrypt (true) or decrypt (false)
BF_cfb64_encrypt(data, out, data_len, &bfkey, ivec, &num, enc);
memcpy(data, out, data_len);
free(out);
}
// bob is now free to send the ecnrypted key back to alice
Note: you should also look at the open_ssl api. I found this very
helpful.
Cheers,
Ben.
On 21 July 2010 15:41, Harshvir Sidhu mailto:hvssi...@gmail.com>> wrote:
Ben:
Yes thats what i need to do. If you can provide some
example, that will be great.
Thanks.
// Harshvir
On Wed, Jul 21, 2010 at 9:17 AM, Ben Jones mailto:b...@bhjones.com>> wrote:
Well I implemented something very similar recently but using
tcp rather than udp. In my case, alice creates a
public-private key pair and sends public key to bob. Bob
then encrypts randomly generated symmetric key (.e.g
blowish, dsa or aes etc.) with public key and sends the
result to alice. Alice then decrypts with her private key.
Both alice and bob have knowledge of symmetric key which can
then be used for secure communication.
A clear problem with this is a man-in-the-middle attack.
There are functions built into the open ssl framework that
allows you do create such keys manually. If that's what you
need to do, I can give a more concrete ( albeit probably
naive) example...
Cheers,
Ben.
On 21 July 2010 15:0
Re: sha_block_data_order Crash
I am afraid I cannot match your stack trace to the disassembly without either line numbers in the disassembly or a numeric value for the $rip register. On 24-08-2010 13:37, Sayan Chaliha wrote: Hey all, Under stressed conditions (multi-threaded apps with several threads using OpenSSL at the same time) the function RAND_bytes crashes consistently. Anybody have any idea why this is caused and if there's any solution for it? Attached: GDB `disassemble $rip` ourput from core dump. Stack trace: #0 sha1_block_data_order (c=0x2aab118ab4c0, p=, num=288230376151706362) at sha_locl.h:256 #1 0x2b302f4a1e13 in SHA1_Update (c=0x2aab118ab4c0, data_=, len=18446744073709551592) at ../md32_common.h:325 #2 0x2b302f5034ed in ssleay_rand_bytes (buf=0x46d25860 "", num=0) at md_rand.c:489 #3 0x2b302f502df6 in ssleay_rand_pseudo_bytes (buf=0x2022a54d0 , num=1933866968) at md_rand.c:533 OpenSSL version: 1.0.0a OS: CentOS 5.4 x86_64 -- Regards, Sayan Chaliha Webyog Softworks Private Limited 2nd Floor, Novel Team Building #10, 100 Feet Ring Road BTM Layout 1st Stage Bangalore - 560068 +91-9743357501 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: sha_block_data_order Crash
Have you explicitly made your application thread safe? There are four functions that you need to implement to make the OpenSSL libraries themselves thread safe. These are: static void locking_function(int mode, int n, const char * file, int line) static unsigned long id_function(void) int THREAD_setup(void) and int THREAD_cleanup Once you have these implemented, you call THREAD_setup in the main thread before you start spawning sub threads, and THREAD_cleanup during shutdown. This will allow openssl to successfully run the multi threaded. For more information on how to implement these functions see the man page for CRYPTO_set_locking_callback, and CRYPTO_set_id_callback I hope that this is new information, and not something you already knew. Cheers, Sam On Tue, Aug 24, 2010 at 6:37 AM, Sayan Chaliha wrote: > Hey all, > > Under stressed conditions (multi-threaded apps with several threads using > OpenSSL at the same time) the function RAND_bytes crashes consistently. > Anybody have any idea why this is caused and if there's any solution for it? > > Attached: > GDB `disassemble $rip` ourput from core dump. > > Stack trace: > #0 sha1_block_data_order (c=0x2aab118ab4c0, p=, > num=288230376151706362) at sha_locl.h:256 > #1 0x2b302f4a1e13 in SHA1_Update (c=0x2aab118ab4c0, data_= optimized out>, len=18446744073709551592) at ../md32_common.h:325 > #2 0x2b302f5034ed in ssleay_rand_bytes (buf=0x46d25860 "", num=0) at > md_rand.c:489 > #3 0x2b302f502df6 in ssleay_rand_pseudo_bytes (buf=0x2022a54d0 > , num=1933866968) at md_rand.c:533 > > OpenSSL version: 1.0.0a > > OS: CentOS 5.4 x86_64 > > -- > Regards, > Sayan Chaliha > Webyog Softworks Private Limited > 2nd Floor, Novel Team Building > #10, 100 Feet Ring Road > BTM Layout 1st Stage > Bangalore - 560068 > > +91-9743357501 > -- Sam Jantz Software Engineer
Re: Just Encryption Using Openssl
Ben,
theEncryptor::blowfish(unsigned char *data, int data_len, unsigned char*
key, unsigned char *ivec, int enc)
In this function you are passing key argument as char *, i am not able
to find alice's public key in char* format, we received that in 2 buffers
and we put that in RSA struct. Which one should i use to pass in here.
Thanks.
// Harshvir
On Wed, Jul 21, 2010 at 10:07 AM, Ben Jones wrote:
> Ok, well assuming you're talking about C++ which is what I'm using, then to
> create an RSA key pair you do:
>
> // alice would do this
> RSA *rsa = RSA_generate_key(bits, 65537, NULL, NULL);
>
> // alice can then get the public part of the key and send to bob
> const int max_hex_size = (bits / 4) + 1;
> long size = max_hex_size;
> char keyBufferA[size];
> char keyBufferB[size];
> bzero(keyBufferA,size);
> bzero(keyBufferB,size);
> sprintf(keyBufferA,"%s\r\n",BN_bn2hex(rsa->n));
> sprintf(keyBufferB,"%s\r\n",BN_bn2hex(rsa->e));
> int n = send(sock,keyBufferA,size,0);
> char recBuf[2];
> n = recv(sock,recBuf,2,0);
> n = send(sock,keyBufferB,size,0);
> n = recv(sock,recBuf,2,0);
>
> // bob can then receive the public key, so on bob's end:
> int max_hex_size = (bits / 4) + 1;
> char keybufA[max_hex_size];
> bzero(keybufA,max_hex_size);
> char keybufB[max_hex_size];
> bzero(keybufB,max_hex_size);
> int n = recv(sock,keybufA,max_hex_size,0);
> n = send(sock,"OK",2,0);
> n = recv(sock,keybufB,max_hex_size,0);
> n = send(sock,"OK",2,0);
> rsa = RSA_new();
> BN_hex2bn(&rsa->n, keybufA);
> BN_hex2bn(&rsa->e, keybufB);
>
> // bob can then generate symmetric key
> unsigned char* key;
> int n = RAND_bytes(key, bytes); // if n is 0 then system failed in having
> enough entropy to gather a strong key and should be //considered insecure
>
> // bob can then encrypt key with alice's public key, in fact here is a
> snippet of a function
> // note ivec is an intialisation vector. This is often initialized to 0
> (but doing this is very insecure, but its useful
> // to do this for testing purposes)
> void
> theEncryptor::blowfish(unsigned char *data, int data_len, unsigned char*
> key, unsigned char *ivec, int enc)
> {
>
> // hash the key first!
> unsigned char obuf[20];
> bzero(obuf,20);
> SHA1((const unsigned char*)key, 64, obuf);
>
> BF_KEY bfkey;
> int keySize = 20;//strlen((char*)key);
> BF_set_key(&bfkey, keySize, obuf);
>
> //unsigned char ivec[16];
> //memset(ivec, 0, 16);
>
> unsigned char* out=(unsigned char*) malloc(data_len);
> bzero(out,data_len);
> int num = 0;
>
> // enc is whether to encrypt (true) or decrypt (false)
> BF_cfb64_encrypt(data, out, data_len, &bfkey, ivec, &num, enc);
>
> memcpy(data, out, data_len);
> free(out);
> }
>
> // bob is now free to send the ecnrypted key back to alice
>
> Note: you should also look at the open_ssl api. I found this very helpful.
>
> Cheers,
> Ben.
>
>
>
>
> On 21 July 2010 15:41, Harshvir Sidhu wrote:
>
>> Ben:
>>Yes thats what i need to do. If you can provide some example, that will
>> be great.
>>
>> Thanks.
>>
>> // Harshvir
>>
>>
>> On Wed, Jul 21, 2010 at 9:17 AM, Ben Jones wrote:
>>
>>> Well I implemented something very similar recently but using tcp rather
>>> than udp. In my case, alice creates a public-private key pair and sends
>>> public key to bob. Bob then encrypts randomly generated symmetric key (.e.g
>>> blowish, dsa or aes etc.) with public key and sends the result to alice.
>>> Alice then decrypts with her private key. Both alice and bob have knowledge
>>> of symmetric key which can then be used for secure communication.
>>>
>>> A clear problem with this is a man-in-the-middle attack. There are
>>> functions built into the open ssl framework that allows you do create such
>>> keys manually. If that's what you need to do, I can give a more concrete (
>>> albeit probably naive) example...
>>>
>>> Cheers,
>>> Ben.
>>>
>>>
>>> On 21 July 2010 15:02, Harshvir Sidhu wrote:
>>>
Hi All,
I am trying to use encryption over Client/Server machines. My
requirement is that i have to use winsock UDP functions to send and receive
data. Is there some mechanism to perform key and cipher exchange in this
case, like normally SSL_Connect will do this, but in my case i cannot use
that. Is there some suggestion for this?
// Harshvir
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
