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