Re: non-blocking problem
On Tue, Apr 27, 2010 at 5:48 PM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Apr 27, 2010, piper.guy1 wrote: Hi again, I'm trying to follow the instructions in the OpenSSL reference book, and their example code from their site for setting a socket to 'non-blocking'. Before I made any changes, I was working with good code that was making secure connections with no problems. Essentially: bio = BIO_new_connect(connect_str); BIO_do_connect(bio); ssl = SSL_new(ctx); SSL_set_bio(ssl, bio, bio); SSL_connect(ssl); From the example code, it seemed easy enough to call 'SSL_get_rfd() using the SSL object to get the file descriptor in order to use fcntl() to change the socket to non-blocking. However when I did this, calls to SSL_get_rfd() always return -1. Reading the function description docs, SSL_get_rfd() will return -1 if the BIO is not suitable for file descriptors. The example code doesn't show how their BIO SSL objects were created, and there's no other reference or information on what they mean on how to make them 'suitable'. So, I tried another approach. I created a socket the convention way and did a connect, followed by: bio = BIO_new_socket(sd, BIO_CLOSE); ssl = SSL_new(ctx) ; SSL_set_bio(ssl, bio, bio); SSL_connect(ssl); which also workeduntil I called SSL_get_rfd() after I created the SSL object, which again returned -1. What am I doing wrong? How do you make a BIO object for file descriptors suitable? Well I didn't write that suitable phrase. I'm not sure why you're getting the -1 return does ERR_print_errors_fp(stderr) give anything useful? In the second example you can use the pass descriptor sd for the purpose: all the following calls do is associate it with the SSL structure. 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-us...@openssl.org Automated List Manager majord...@openssl.org Steve and all, Embarrassingly, after looking at my code, I wasn't quite doing what I said I was doing. I was making the call to SSL_get_rfd() BEFORE calling SSL_connect(). Once I called SSL_get_rfd() after SSL_connect() it worked like a charm. thanx /carl h. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign client requirements
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 at all? -Original Message- From: owner-openssl-us...@openssl.org on behalf of piper.guy1 Sent: Mon 4/19/2010 1:27 PM To: openssl-users@openssl.org Subject: 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 dav...@webmaster.com 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
Re: Verisign client requirements
Thanks for your help David. Regards, /carl h. On Tue, Apr 20, 2010 at 9:54 PM, David Schwartz dav...@webmaster.com wrote: Piper Guy1 wrote: 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, It's not a particularly simple process to describe, but it checks the integrity of all the certificates, checks their signatures, and makes sure the chain's links are correct. - the server owns the certificate The certificate is public. Nobody really owns it. What the certificate says, using the www.amazon.com example again, is say that the owner of www.amazon.com is the only person who knows the private key that corresponds with the public key in the certificate. OpenSSL confirms that the entity presenting the certificate knows the private key by challenging them to perform an operation that requires that private key. - make sure the certificate trust chain has a root CA. It follows the chain and makes sure it lands on a root CA that the client trusts. However, all of that does nothing if the certificate is the *wrong* certificate. If I type https://www.amazon.com; in my browser, and all the above checks pass, but the certificate is for www.creditcardstealingscammers.com, I sure as heck don't want to trust the server! 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? As I said, to make sure that you're connected to the server you wanted to be connected to and not the server of a malicious third party. The field is sent in plain text, but so what? Anyone could get it anyway just by connecting to the server. So it's not a secret. 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. Presuming they check the validity of the common name, it sounds like they're doing things the same way everyone else is. If they are not checking the common name, then an active interceptor could hijack the connection if he had the private key corresponding to any certificate whose chain landed on a root CA the client trusts. 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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
non-blocking problem
Hi again, I'm trying to follow the instructions in the OpenSSL reference book, and their example code from their site for setting a socket to 'non-blocking'. Before I made any changes, I was working with good code that was making secure connections with no problems. Essentially: bio = BIO_new_connect(connect_str); BIO_do_connect(bio); ssl = SSL_new(ctx); SSL_set_bio(ssl, bio, bio); SSL_connect(ssl); From the example code, it seemed easy enough to call 'SSL_get_rfd() using the SSL object to get the file descriptor in order to use fcntl() to change the socket to non-blocking. However when I did this, calls to SSL_get_rfd() always return -1. Reading the function description docs, SSL_get_rfd() will return -1 if the BIO is not suitable for file descriptors. The example code doesn't show how their BIO SSL objects were created, and there's no other reference or information on what they mean on how to make them 'suitable'. So, I tried another approach. I created a socket the convention way and did a connect, followed by: bio = BIO_new_socket(sd, BIO_CLOSE); ssl = SSL_new(ctx) ; SSL_set_bio(ssl, bio, bio); SSL_connect(ssl); which also workeduntil I called SSL_get_rfd() after I created the SSL object, which again returned -1. What am I doing wrong? How do you make a BIO object for file descriptors suitable? thanx /carl h. __ 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 dav...@webmaster.com 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 Listopenssl-users@openssl.org Automated List Manager majord
Verisign client requirements
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. 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 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? Any references on the net to help me better understand would be apprciated as well. thanx /carl h. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
wget passphrase
Sorry if this has been ask before. I need to use 'wget' to do a secure file download. It works great at the command line. Unfortunately wget asks for the PEM passphrase. However this will eventually be part of an embedded application so the passphrase prompt can't happen. 1. Can you create PEM's without a passphrase? 2. Should i use Curl which seems to provide an option for passphrases. 3. Any better suggestions (fairly new to security). thanx /carl __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
