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 List openssl-users@openssl.org Automated List Manager majord...@openssl.org
