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