Re: possible user error / memory leak using RSA_new() and RSA_free();
Steve & Mounir, Thanks a lot for answering my questions. Stuart - Original Message From: Dr. Stephen Henson To: openssl-users@openssl.org Sent: Mon, April 19, 2010 4:38:14 PM Subject: Re: possible user error / memory leak using RSA_new() and RSA_free(); On Mon, Apr 19, 2010, Stuart Weatherby wrote: > Thanks Steve, > > After commenting out lines 24 & 25 there is still unfree'd memory: > http://www.openssl.org/support/faq.html#PROG13 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Projecthttp://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible user error / memory leak using RSA_new() and RSA_free();
On Mon, Apr 19, 2010, Stuart Weatherby wrote: > Thanks Steve, > > After commenting out lines 24 & 25 there is still unfree'd memory: > http://www.openssl.org/support/faq.html#PROG13 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible user error / memory leak using RSA_new() and RSA_free();
Thanks Steve,
After commenting out lines 24 & 25 there is still unfree'd memory:
Stuart
==8155== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==8155== malloc/free: in use at exit: 528 bytes in 10 blocks.
==8155== malloc/free: 137 allocs, 127 frees, 13,340 bytes allocated.
==8155== For counts of detected errors, rerun with: -v
==8155== searching for pointers to 10 not-freed blocks.
==8155== checked 227,584 bytes.
==8155==
==8155== 528 bytes in 10 blocks are still reachable in loss record 1 of 1
==8155== at 0x4A05809: malloc (vg_replace_malloc.c:149)
==8155== by 0x35156DAD51: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351567EAC8: lh_new (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351565B4C4: (within /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351565B5E5: (within /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351565B98A: (within /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351567698F: BIO_set (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x3515676A19: BIO_new (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x351569DE71: PEM_ASN1_read (in /lib64/libcrypto.so.0.9.8e)
==8155== by 0x400836: main (rsatest.c:30)
==8155==
==8155== LEAK SUMMARY:
==8155== definitely lost: 0 bytes in 0 blocks.
==8155== possibly lost: 0 bytes in 0 blocks.
==8155== still reachable: 528 bytes in 10 blocks.
==8155== suppressed: 0 bytes in 0 blocks.
- Original Message
From: Dr. Stephen Henson
To: openssl-users@openssl.org
Sent: Mon, April 19, 2010 3:12:53 PM
Subject: Re: possible user error / memory leak using RSA_new() and RSA_free();
On Mon, Apr 19, 2010, Stuart Weatherby wrote:
> Hi List,
>
> I am trying to figure out why there is a memory leak using RSA_new & RSA_free:
> Below is a code sample (which will produce a memory leak) and the relevent
> valgrind output. I have checked the documentation but I still fail to see my
> error.
>
> As I understand the docuumentation, RSA_free() is the only required call to
> free memory allocated using the RSA_new() function.
>
> Thanks,
>
> Stuart
>
>
> int main (void)
> {
> FILE *fp;
> RSA *p = NULL;
> char *pt = "hi\0";
> char pt_0 = *pt;
> int pt_len = strlen(pt);
> unsigned char *ct;
> int ct_len = 0;
>
> if ((p = RSA_new()) == NULL)
> return 1;
> if ((fp = fopen ("pub.key", "rb")) == NULL)
> return 2;
> if ((p = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL)) == NULL)
> {
> fclose(fp);
> return 3;
> }
> fclose(fp);
> ct = malloc(RSA_size(p));
> if(RSA_public_encrypt(pt_len,(unsigned char *) pt,ct, p,
> RSA_PKCS1_OAEP_PADDING) == -1)
> return 4;
> free(ct);
> RSA_free(p);
> return 0;
> }
>
You are allocating an RSA structure then completely overwriting the pointer
with a new one. Leaving the original as the leak.
Delete the RSA_new() call.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible user error / memory leak using RSA_new() and RSA_free();
Hi,
Remove the unecessary call to RSA_new and the memory leak will
disappear!! (The variable p est allocated by PEM_read_RSA_PUBKEY)
Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr
On 4/19/2010 11:07 PM, Stuart Weatherby wrote:
Hi List,
I am trying to figure out why there is a memory leak using RSA_new& RSA_free:
Below is a code sample (which will produce a memory leak) and the relevent
valgrind output. I have checked the documentation but I still fail to see my
error.
As I understand the docuumentation, RSA_free() is the only required call to
free memory allocated using the RSA_new() function.
Thanks,
Stuart
int main (void)
{
FILE *fp;
RSA *p = NULL;
char *pt = "hi\0";
char pt_0 = *pt;
int pt_len = strlen(pt);
unsigned char *ct;
int ct_len = 0;
if ((p = RSA_new()) == NULL)
return 1;
if ((fp = fopen ("pub.key", "rb")) == NULL)
return 2;
if ((p = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL)) == NULL)
{
fclose(fp);
return 3;
}
fclose(fp);
ct = malloc(RSA_size(p));
if(RSA_public_encrypt(pt_len,(unsigned char *) pt,ct, p,
RSA_PKCS1_OAEP_PADDING) == -1)
return 4;
free(ct);
RSA_free(p);
return 0;
}
Here is the valgrind output:
==2330== 528 bytes in 10 blocks are still reachable in loss record 2 of 2
==2330==at 0x4A05809: malloc (vg_replace_malloc.c:149)
==2330==by 0x35156DAD51: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e)
==2330==by 0x351567EAC8: lh_new (in /lib64/libcrypto.so.0.9.8e)
==2330==by 0x351565B4C4: (within /lib64/libcrypto.so.0.9.8e)
==2330==by 0x351565B5E5: (within /lib64/libcrypto.so.0.9.8e)
==2330==by 0x351565B98A: (within /lib64/libcrypto.so.0.9.8e)
==2330==by 0x351566F9B3: RSA_new_method (in /lib64/libcrypto.so.0.9.8e)
==2330==by 0x40083D: main (rsatest.c:24)
==2330==
==2330== LEAK SUMMARY:
==2330==definitely lost: 168 bytes in 1 blocks.
==2330== possibly lost: 0 bytes in 0 blocks.
==2330==still reachable: 528 bytes in 10 blocks.
==2330== suppressed: 0 bytes in 0 blocks.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible user error / memory leak using RSA_new() and RSA_free();
On Mon, Apr 19, 2010, Stuart Weatherby wrote:
> Hi List,
>
> I am trying to figure out why there is a memory leak using RSA_new & RSA_free:
> Below is a code sample (which will produce a memory leak) and the relevent
> valgrind output. I have checked the documentation but I still fail to see my
> error.
>
> As I understand the docuumentation, RSA_free() is the only required call to
> free memory allocated using the RSA_new() function.
>
> Thanks,
>
> Stuart
>
>
> int main (void)
> {
> FILE *fp;
> RSA *p = NULL;
> char *pt = "hi\0";
> char pt_0 = *pt;
> int pt_len = strlen(pt);
> unsigned char *ct;
> int ct_len = 0;
>
> if ((p = RSA_new()) == NULL)
> return 1;
> if ((fp = fopen ("pub.key", "rb")) == NULL)
> return 2;
> if ((p = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL)) == NULL)
> {
> fclose(fp);
> return 3;
> }
> fclose(fp);
> ct = malloc(RSA_size(p));
> if(RSA_public_encrypt(pt_len,(unsigned char *) pt,ct, p,
> RSA_PKCS1_OAEP_PADDING) == -1)
> return 4;
> free(ct);
> RSA_free(p);
> return 0;
> }
>
You are allocating an RSA structure then completely overwriting the pointer
with a new one. Leaving the original as the leak.
Delete the RSA_new() call.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Verisign client requirements
I think you need a tutorial in how X.509 hierarchies and chains of trust work. Consider a public and private key pair: if I have a private key and you have the corresponding public key, you can decrypt something I encrypt. This permits all sorts of interesting possibilities: If I encrypt something, and you can decrypt it to its plain text form, it establishes that it came from me, or that I somehow vouch for it (by encrypting it in the first place). Now, simply decrypting something that has been encrypted will not guarantee that what you get isn't gobbledygook. However, if what you decrypt is, somehow internally consistent, it can mitigate that possibility. So, consider an X.509 certificate. It contains, among other things, a public key, key algorithm, what the certificate can be used for, expiration timestape, and, most importantly, a SIGNATURE (and a signature algorithm). This signature is the encrypted hash (according to the specified signature algorithm), of the rest of the certificate. It is encrypted by the private key corresponding to the certificates ISSUER (which might be the same as the subject of the certificate itself, for root, or other "self-signed" certificates). Let that sink in for a bit. If you have the public key corresponding to the private key that was used TO ENCRYPT THE CERTIFICATE HASH TO MAKE THE SIGNATURE, you can decrypt that signature, and compare it to what the hash over the rest of the certificate is. If they match, you can assure yourself that the owner of the private key that "signed" the certificate vouched for its authenticity. In your case, this means vouching for all the elements of the certificate being BOUND to one another. Specifically, that the common name is BOUND to the public key in the certificate, and therefore to the owner of the corresponding private key. So, if you trust who signed the certificate (and have their public key), and verify that they signed the certificate, you can be assured that traffic from the server named in the common name will be encrypted by the private key corresponding to the public key in the certificate. This "public key of who signed the certificate" is, of course, just stored in yet another certificate. So, you can imagine a "chain" of certificates with public keys that correspond to private keys that have been used to encrypt the hashes of the contents of subsequent certificates in the chain. The chain starts with a "root" certificate who's corresponding private key encrypted the hash of the certificate to make a "self-signed" certificate. So, sending the common name in a certificate in "plain text" does not offer any means to tamper with it in transit, since, if that happened, the signature of the certificate would be wrong. All it does is reveal the common name of the site that offered the certificate. Evesdroppers can tell the site you contacted, but they can likely do than anyway via DNS, so this does not leak any extra information. Do you follow so far? So, all the server needs is its certificate (which somebody signed), and private key. It DOES NOT NEED to send the certificate that corresponds to the private key that signed it... but the browser (or other client) must have it. Otherwise you can't trust the site you reach. This is why server certificates from "well-known" certificate authorities (like Verisign. Thwaite, etc.) are so valuable: your browser already trusts the issuer (Whether this is actually a good thing, given how many such issuers there are, is debatable: would you really want to trust a Chinese certificate authority to sign the certificate provided by your American bank? Not to disparage the Chinese (the reverse situation would be just as suspect), but there the lack of legal recourse against organizations in different jurisdictions claiming a trust relationship is problematic.) Now, if all you want to do is secure traffic between two sites, you CAN have your server use a self-signed certificate, and somehow separately get that certificate to your clients (say, postal mail). Then, when that certificate is presented, you can verify it. Many home routers that provide secureed web-based administration do this: after all, if you contact the router, and it's on your desk, you can pretty much trust that your traffic to it has not been intercepted. Certificate hierarchies are designed to avoid the need to have certificates from ALL your secured correspondents: you just need to trust the few organizations that issue all the certificates you will encounter. The simple (non-self-signed) example involves a root certificate and a server certificate. But, there can be many "intermediate" certificates inbetween. SSL allows the server to send these, lest the client does not have some of them. Starting from the trusted root certificate, the client can verify intermediate certificates in turn until it finally verifies the server certificate. Has that helped
possible user error / memory leak using RSA_new() and RSA_free();
Hi List,
I am trying to figure out why there is a memory leak using RSA_new & RSA_free:
Below is a code sample (which will produce a memory leak) and the relevent
valgrind output. I have checked the documentation but I still fail to see my
error.
As I understand the docuumentation, RSA_free() is the only required call to
free memory allocated using the RSA_new() function.
Thanks,
Stuart
int main (void)
{
FILE *fp;
RSA *p = NULL;
char *pt = "hi\0";
char pt_0 = *pt;
int pt_len = strlen(pt);
unsigned char *ct;
int ct_len = 0;
if ((p = RSA_new()) == NULL)
return 1;
if ((fp = fopen ("pub.key", "rb")) == NULL)
return 2;
if ((p = PEM_read_RSA_PUBKEY(fp, NULL, NULL, NULL)) == NULL)
{
fclose(fp);
return 3;
}
fclose(fp);
ct = malloc(RSA_size(p));
if(RSA_public_encrypt(pt_len,(unsigned char *) pt,ct, p,
RSA_PKCS1_OAEP_PADDING) == -1)
return 4;
free(ct);
RSA_free(p);
return 0;
}
Here is the valgrind output:
==2330== 528 bytes in 10 blocks are still reachable in loss record 2 of 2
==2330== at 0x4A05809: malloc (vg_replace_malloc.c:149)
==2330== by 0x35156DAD51: CRYPTO_malloc (in /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351567EAC8: lh_new (in /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351565B4C4: (within /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351565B5E5: (within /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351565B98A: (within /lib64/libcrypto.so.0.9.8e)
==2330== by 0x351566F9B3: RSA_new_method (in /lib64/libcrypto.so.0.9.8e)
==2330== by 0x40083D: main (rsatest.c:24)
==2330==
==2330== LEAK SUMMARY:
==2330== definitely lost: 168 bytes in 1 blocks.
==2330== possibly lost: 0 bytes in 0 blocks.
==2330== still reachable: 528 bytes in 10 blocks.
==2330== suppressed: 0 bytes in 0 blocks.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Verisign client requirements
David, Sorry for my late response. (pulled in another direction for a while). But i still have a few holes in my understanding (and maybe my head!!). Here are some facts about our implementation: 1. The server does not have my root certificate. 2. I do not have the server's root certificate. 3. I do not store any server or Verisign certificates. 4. The server does not request my client certificate. So based on what you said below, and knowing the above: > This is precisely what a browser does. Again, using the > "https://www.amazon.com"; example, OpenSSL takes care of getting the > certificate from the server, making sure the certificate is valid, checking > that the server owns the certificate, and making sure the certificate's > trust chain has a root CA that is on your trusted list. However, > www.badguys.com could also pass all those tests. .how does OpenSSL (or can our implementation of OpenSSL): - make sure the certs are valid, - the server owns the certificate - make sure the certificate trust chain has a root CA. > So that leaves you to check > the common name on the certificate and make sure it's the *right* name -- > that is, the server you wanted to reach. I also noticed when i sniffed the wire that the common name field is in clear text. What's the point of verifying that? Based on the 4 points above, would you say that our implementation is not very strong? I don't have the security expertise to challenge the server guys so it's basically status quo, which my gut tells me is not very strong. thanx /carl h. On Mon, Apr 5, 2010 at 5:04 PM, David Schwartz wrote: > > Piper.guy1 wrote: > >> Hi, >> >> Please understand I'm a newbie to security if my question sounds >> rather elementary. >> >> The embedded product I'm working on requires a secure connection to >> our server that uses a Verisign certificate to authenticate. I've been >> porting the OpenSSL examples from the O'Reilly publication so far and >> I have been successfully able to make a secure encrypted connection >> without authentication. (example client1.c). Our next step it to >> implement authentication using a Verisign cert. > > Usually, when people talk about "authentication", they mean the server > authenticating the client. The client always makes sure it has reached the > correct server. I presume, what you are talking about is the same check that > every browser does. When you punch "https://www.amazon.com"; into your > browser, your browser makes sure the server you reach presents a certificate > for "www.amazon.com" that is signed by a CA your browser trusts -- and then > it makes the server prove it knows the private key corresponding to the > public key in that certificate. > > Is that all you're trying to do? > >> 3rd party CA's are talked about in the book very nicely but the focus >> is on the server, and very little is discussed regarding what the >> client needs to implement, unless I'm not reading in the right place, >> or there's very little else for the client to do. >> >> It would seem that I would have to implement much of example >> client2.c; or essentially call: >> >> 1. SSL_CTX_load_verify_locations() with the trusted certificates file > > Correct. And the trusted files should include the root certificates your > client trusts. It must include the Verisign root certificate that your > server's trust chain starts with (or ends with, depending on how you look at > it). > >> 2. SSL_CTX_set_verify() with the SSL_VERIFY_PEER flag set >> >> Do I have to add anything else to the trusted certificates file or >> will OpenSSL magically know to authenticate with Verisign? >> >> Is this all I need to do? > > The problem with this is it will wind up accepting any certificate whose > trust chain's root is one of your trusted certificates, yours or not. The > best solution to this problem is to confirm that the certificate presented > has as its common name the name your client is trying to reach. > > This is precisely what a browser does. Again, using the > "https://www.amazon.com"; example, OpenSSL takes care of getting the > certificate from the server, making sure the certificate is valid, checking > that the server owns the certificate, and making sure the certificate's > trust chain has a root CA that is on your trusted list. However, > www.badguys.com could also pass all those tests. So that leaves you to check > the common name on the certificate and make sure it's the *right* name -- > that is, the server you wanted to reach. > > DS > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > __ OpenSSL Project http://www.openssl.org User Support Mailing List
Re: Multi Threaded questions
On Mon, 19 Apr 2010 11:09:33 -0700 "Jeremy Farrell" wrote: > That's the usual way to handle significant numbers of connections. > For many programs handling a small number of connections, two threads > per connection is the normal approach. It's simpler, and much easier > to port between OSes. Horses for courses. I think that depends on simplicity (or complexity) of your application and how much shared data you have. Having two I/O threads (one for reading, one for writing) for each socket, means you need to use locking and condition variables to signal the start/completion of I/O. Making sure that you test the right predicates in a proper way, and avoid race conditions, can be quite tricky. A simple call to poll() might be much easier. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Multi Threaded questions
> > > However do you really need to use multiple concurrent threads > > > with the same SSL object? Think of it as a TCP socket, each > > > thread has a list of open sockets, or SSL objects, there is > > > no need to share it with other threads. > > "David Schwartz" wrote: > > > > Actually, it's pretty common to do that with TCP connections. > > You may have one thread that's blocked trying to read from the > > connection all the time while another thread tries write to the > > connection as it discovers data that needs to be sent. You can't > > do this with OpenSSL. (At least, not precisely the same way.) > Sad Clouds wrote: > > It's a bad way of doing network programming. No, it's a perfectly good, sensible, straightforward and simple way to do network programming. > A server can potentialy > have 1000s of open sockets, if you have two threads for each sockets, > (one for reading, one for writing), pretty soon you'll run out of > memory. Scheduling all those threads will have a negative impact on > performance. Indeed. That makes two-threads-per-connection inappropriate for use with thousands of connections on most systems. Many network programs have a maximum of one or two connections, or another small number; for such programs having separate read and write threads can be a simple elegant solution. > The usual way to handle concurrent connections is to set sockets > non-blocking and use event notification - poll, epoll, kqueue, ports, > etc. That's the usual way to handle significant numbers of connections. For many programs handling a small number of connections, two threads per connection is the normal approach. It's simpler, and much easier to port between OSes. Horses for courses. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Multi Threaded questions
Hi Sads, On Mon, Apr 19, 2010 at 3:32 AM, Sad Clouds wrote: > On Sun, 18 Apr 2010 21:11:40 -0700 > "David Schwartz" wrote: >> Sad Clouds wrote: >> >> > > 1) According to the FAQ, "an SSL connection may not concurrently >> > > be used by multiple threads". Does this mean that an SSL >> > > connection can be used by different threads provided access is >> > > limited to one at a time? >> >> > I assume that having a mutex for each SSL object would prevent it >> > from being concurrently used by multiple threads. So this should be >> > OK. >> >> Yes, that works. However, you can't use blocking operations in that >> case. Otherwise, a thread trying to write to the connection would be >> blocked potentially for ever as some other thread blocked trying to >> read from the connection held the connection lock. > > That's not the way to do it on Unix. > >> > However do you really need to use multiple concurrent threads with >> > the same SSL object? Think of it as a TCP socket, each thread has a >> > list of open sockets, or SSL objects, there is no need to share it >> > with other threads. >> >> Actually, it's pretty common to do that with TCP connections. You may >> have one thread that's blocked trying to read from the connection all >> the time while another thread tries write to the connection as it >> discovers data that needs to be sent. You can't do this with OpenSSL. >> (At least, not precisely the same way.) > > It's a bad way of doing network programming. A server can potentialy > have 1000s of open sockets, if you have two threads for each sockets, > (one for reading, one for writing), pretty soon you'll run out of > memory. Scheduling all those threads will have a negative impact on > performance. The 2.5 and above kernels uses a constant time scheduling algorithm, so the performance hit should be incurred on resource usage and not scheduling. I would expect that the 'penalty for resource usage' would be page faults due to swap file use and contention for the CPU by the threads. See http://www.informit.com/articles/article.aspx?p=101760&seqNum=2. (If you meant 'running all those threads...', please disregard this comment). > The usual way to handle concurrent connections is to set sockets > non-blocking and use event notification - poll, epoll, kqueue, ports, > etc. > Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Binding outgoing SSL connection to certain IP address
On Mon, 19 Apr 2010 11:58:51 +0200 (CEST) Ondrej Jombik wrote: > I do need this for client side. Machine where connection is > originating has several IP addresses and the remote machine will > accept connection only from one of those. So I need to choose exactly > one source IP address when creating connection. > > Can your example be modified for this? > The code for the client side is very similar. So you set IP address and port number and then call bind() to associate source IP address with the socket, otherwise OS kernel will choose IP address for you. To connect to the server you call connect(). Once you have a connected socket, you creae SSL object, call SSL_set_fd() to associate connected socket with SSL object and then call SSL_connect() to initiate SSL handshake. I think this should work, just give it a try. > Also I noticed that in your example there is no BIO used at all. Now > I'm even more confused, since I thought that BIO is something like > must-have when dealing with SSL connections. > > If I ever properly create socket with desired properties, ie. correct > originating source address and correct destination address and port, > should I pass this socket to SSL with SSL_set_fd() or to BIO with > BIO_set_fd() ? I think there are different ways of associating file descriptors with SSL objects. Calling SSL_set_fd() and passing it connected socket should automatically associate that socket with SSL object and create the necessary BIO. Have a look at the man page for SSL_set_fd if in doubt. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[FWD] Error: SSL: couldn't create a context!
Forwarded to openssl-users for public discussion. Best regards, Lutz - Forwarded message from sumit sengupta - DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1271681043; bh=EWieRuvM759TV601L/2vGiP1boYErqP6lbAkC+avdWQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME- Version:Content-Type; b=1/f80QspsxSnB3VtXzWaPcwSKu1AVEVnKmnVaDFKVLqcrwkwOiVi2iBmGdz/wuL7OTuDHM Q2ZGPjWPE1WxFFeI3kHjsQSlt6zS8oKKz/WI2hE/s+PJxETfog0kxgfCRtRzPOss8PFxjDkA 20cVfd6q6oE+Gp2EDAy63JxpTLbaA= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME- Version:Content-Type; b=P8R5R0/zKRh5lxYKNGJsyoaV2nOflyWyw/mTvYaEbyPOqGxuQhlB8gfWapy1zBuwFVtuHD 0eHA9n+EeBBTng0YNrVNJbxmeqtZZmSl3XJnX+GPKfkDlM4Ej4lFUv6u0uWZWC6C9f330lgN j0C5otx4uTTpDHI4uwCJoUzZg+5F4=; Date: Mon, 19 Apr 2010 05:44:03 -0700 (PDT) From: sumit sengupta Subject: Error: SSL: couldn't create a context! To: r...@openssl.org Cc: sumit_sn...@yahoo.co.in System: FreeBSD4 openssl-0.9.7g_1 and latest versions Type of Request: Bug report Description: Throwing an error "SSL: couldn't create a context!" intermittently when the OpenSSL function SSL_CTX_new() fails. As of now couldn't figure out the actual reason which causing this error to come up. If you have any experience on how to debug, please share. Thanks, Sumit Sengupta - End forwarded message - -- Lutz Jaenicke jaeni...@openssl.org OpenSSL Project http://www.openssl.org/~jaenicke/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSLv23_method in OpenSSL 1.0.0
On Sun, Apr 18, 2010, Luigi Auriemma wrote: > Hey, > > I have noticed that a client ssl connection initialized with the > classical SSLv23_method no longer works in OpenSSL 1.0.0. > > This has been tested on both Windows (mingw) and Linux and both > connecting to a v2 and v3 server with the same result, while there is no > problem using it with OpenSSL 0.9.8n or using SSLv2_method and > SSLv3_method separately. > Obviously all the used libraries have been compiled from scratch using > the default settings (./Configure gcc ; make). > > Can you confirm this problem? > Well if that was a known problem it would've been fixed... On significant enhancement of SSLv23 in 1.0.0 is that the deprecated SSLv2 ciphers are disabled by default and have to be explicitly enabled using the cipher string. Additionally if there are no SSLv2 ciphers supported (i.e the default) OpenSSL 1.0.0 will no longer send out an SSLv23 compatible client hello. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Binding outgoing SSL connection to certain IP address
I do need this for client side. Machine where connection is originating
has several IP addresses and the remote machine will accept connection
only from one of those. So I need to choose exactly one source IP
address when creating connection.
Can your example be modified for this?
Also I noticed that in your example there is no BIO used at all. Now I'm
even more confused, since I thought that BIO is something like must-have
when dealing with SSL connections.
If I ever properly create socket with desired properties, ie. correct
originating source address and correct destination address and port,
should I pass this socket to SSL with SSL_set_fd() or to BIO with
BIO_set_fd() ?
Anyway thank you for your help.
Ondrej
On Mon, 19 Apr 2010, Sad Clouds wrote:
On Sun, 18 Apr 2010 23:35:16 +0200 (CEST)
Ondrej Jombik wrote:
[ Please Cc me in the answer as I'm not in the list. Thank you. ]
I was googlig for over two days and now I'm stuck. The thing I would
like to accomplish is to bind outgoing SSL connection to certain IP
address.
Our server has several IP addresses, but remote machine will accept
connections only from certain address, which I need to bind client to.
What I have learned I need to create my own filedescriptor (socket)
which will be binded to desired local IP address and connected to
desired remote host.
But how to join this FD with BIO? I know there is BIO_set_fd(), but
this is simply not working well for me. It does nothing. Do someone
have some working snippet of code with this? I would much appreciate
it.
From your description I don't understand if you're trying to bind a
particular IP address on client or server side.
Anyway, you need to use bind(2) system call AND set your IP address.
Then you can call SSL_set_fd() to set connected socket, this should
automatically create the needed BIO for SSL object. Below is a server
code example, which accepts connections only on IP address 192.168.1.1
#define SERV_ADDR "192.168.1.1"
#define SERV_PORT 8000
int listenfd, connfd;
socklen_t clilen;
struct sockaddr_in cliaddr, servaddr;
/* Create IPv4 socket */
if((listenfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
perror("socket() error");
exit(1);
}
memset(&servaddr, 0, sizeof(servaddr));
servaddr.sin_family = AF_INET;
inet_pton(AF_INET, SERV_ADDR, &servaddr.sin_addr);
servaddr.sin_port = htons(SERV_PORT);
if(bind(listenfd, (struct sockaddr *)&servaddr, sizeof (servaddr)) < 0)
{
perror("bind() error");
exit(1);
}
if(listen(listenfd, BACKLOG) < 0)
{
perror("listen() error");
exit(1);
}
/* Accept client connections */
clilen = sizeof(cliaddr);
if((connfd = accept(listenfd, (struct sockaddr *)&cliaddr,
&clilen)) < 0 )
{
perror("accept() error");
exit(1);
}
...
/* Handle SSL connections */
if((ssl = SSL_new(ssl_ctx)) == NULL)
{
printf("SSL_new() error\n");
exit(1);
}
if(SSL_set_fd(ssl, connfd) != 1)
{
printf("SSL_set_fd() error\n");
exit(1);
}
if(SSL_accept(ssl) != 1)
{
printf("SSL_accept() error\n");
ERR_error_string_n(ERR_get_error(), buf, 2048);
printf("%s\n", buf);
exit(1);
}
--
Ondrej JOMBIK
Platon Technologies Ltd., Hlavna 3, Sala SK-92701
+421 903 PLATON - i...@platon.org - http://platon.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Two questions about the certificate revocation
Dear OpneSSL support team Could you please answer to my questions: 1. What process occurs when we revoke the certificate with the command: openssl ca -revoke 2. Why openssl software allows to one Certification Authority(CA) to revoke certificate signed by another CA. Thank you in advance Best regards Armenuhi Abramyan
Re: Binding outgoing SSL connection to certain IP address
On Sun, 18 Apr 2010 23:35:16 +0200 (CEST)
Ondrej Jombik wrote:
> [ Please Cc me in the answer as I'm not in the list. Thank you. ]
>
> I was googlig for over two days and now I'm stuck. The thing I would
> like to accomplish is to bind outgoing SSL connection to certain IP
> address.
>
> Our server has several IP addresses, but remote machine will accept
> connections only from certain address, which I need to bind client to.
>
> What I have learned I need to create my own filedescriptor (socket)
> which will be binded to desired local IP address and connected to
> desired remote host.
>
> But how to join this FD with BIO? I know there is BIO_set_fd(), but
> this is simply not working well for me. It does nothing. Do someone
> have some working snippet of code with this? I would much appreciate
> it.
>From your description I don't understand if you're trying to bind a
particular IP address on client or server side.
Anyway, you need to use bind(2) system call AND set your IP address.
Then you can call SSL_set_fd() to set connected socket, this should
automatically create the needed BIO for SSL object. Below is a server
code example, which accepts connections only on IP address 192.168.1.1
#define SERV_ADDR "192.168.1.1"
#define SERV_PORT 8000
int listenfd, connfd;
socklen_t clilen;
struct sockaddr_in cliaddr, servaddr;
/* Create IPv4 socket */
if((listenfd = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
perror("socket() error");
exit(1);
}
memset(&servaddr, 0, sizeof(servaddr));
servaddr.sin_family = AF_INET;
inet_pton(AF_INET, SERV_ADDR, &servaddr.sin_addr);
servaddr.sin_port = htons(SERV_PORT);
if(bind(listenfd, (struct sockaddr *)&servaddr, sizeof (servaddr)) < 0)
{
perror("bind() error");
exit(1);
}
if(listen(listenfd, BACKLOG) < 0)
{
perror("listen() error");
exit(1);
}
/* Accept client connections */
clilen = sizeof(cliaddr);
if((connfd = accept(listenfd, (struct sockaddr *)&cliaddr,
&clilen)) < 0 )
{
perror("accept() error");
exit(1);
}
...
/* Handle SSL connections */
if((ssl = SSL_new(ssl_ctx)) == NULL)
{
printf("SSL_new() error\n");
exit(1);
}
if(SSL_set_fd(ssl, connfd) != 1)
{
printf("SSL_set_fd() error\n");
exit(1);
}
if(SSL_accept(ssl) != 1)
{
printf("SSL_accept() error\n");
ERR_error_string_n(ERR_get_error(), buf, 2048);
printf("%s\n", buf);
exit(1);
}
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Binding outgoing SSL connection to certain IP address
[ Please Cc me in the answer as I'm not in the list. Thank you. ] I was googlig for over two days and now I'm stuck. The thing I would like to accomplish is to bind outgoing SSL connection to certain IP address. Our server has several IP addresses, but remote machine will accept connections only from certain address, which I need to bind client to. What I have learned I need to create my own filedescriptor (socket) which will be binded to desired local IP address and connected to desired remote host. But how to join this FD with BIO? I know there is BIO_set_fd(), but this is simply not working well for me. It does nothing. Do someone have some working snippet of code with this? I would much appreciate it. Thank you! [ Please Cc me in the answer as I'm not in the list. Thank you. ] -- Ondrej JOMBIK Platon Technologies Ltd., Hlavna 3, Sala SK-92701 +421 903 PLATON - i...@platon.org - http://platon.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Multi Threaded questions
On Sun, 18 Apr 2010 21:11:40 -0700 "David Schwartz" wrote: > > Sad Clouds wrote: > > > > 1) According to the FAQ, "an SSL connection may not concurrently > > > be used by multiple threads". Does this mean that an SSL > > > connection can be used by different threads provided access is > > > limited to one at a time? > > > > I assume that having a mutex for each SSL object would prevent it > > from being concurrently used by multiple threads. So this should be > > OK. > > Yes, that works. However, you can't use blocking operations in that > case. Otherwise, a thread trying to write to the connection would be > blocked potentially for ever as some other thread blocked trying to > read from the connection held the connection lock. > That's not the way to do it on Unix. > > However do you really need to use multiple concurrent threads with > > the same SSL object? Think of it as a TCP socket, each thread has a > > list of open sockets, or SSL objects, there is no need to share it > > with other threads. > > Actually, it's pretty common to do that with TCP connections. You may > have one thread that's blocked trying to read from the connection all > the time while another thread tries write to the connection as it > discovers data that needs to be sent. You can't do this with OpenSSL. > (At least, not precisely the same way.) It's a bad way of doing network programming. A server can potentialy have 1000s of open sockets, if you have two threads for each sockets, (one for reading, one for writing), pretty soon you'll run out of memory. Scheduling all those threads will have a negative impact on performance. The usual way to handle concurrent connections is to set sockets non-blocking and use event notification - poll, epoll, kqueue, ports, etc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
