It most certainly did Rene. Thanks for the complete response. Now I have to go away and digest it :-)
Regards, /carl h. On Mon, Apr 19, 2010 at 5:12 PM, Rene Hollan <rene.hol...@watchguard.com> wrote: > 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 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 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 > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
