Internetworkers: http://www.ibiblio.org/internetworkers/

[Tanner Lovelace <clubjuggler AT gmail.com>]

On 11/30/05, Tony Spencer <tony AT tonyspencer.com> wrote:
> I only can guess that ssl traffic is basically proxied throught the
> cert provider. Only a guess.

And a horrible one at that.

> I'm sure there are guys here that could explain it.

I'll give it a try.

There are two (optionally 3) things you want SSL to do.

1. Encrypt the connection between a client and a server
2. Make sure the server is who they say they are.
3. (optional) Make sure the client is who they say they are.

Doing #1 is trivial.  There are many good references to how the
encryption works (including the one Jason posted) so I'll let you
google for that (http://en.wikipedia.org/wiki/Secure_Sockets_Layer
is a good one) and concentrate on 2 & 3, which are really the same
thing, just in reverse of each other.

For #2, how do you tell that the server is who they say they are?
You can't just trust them because we know there are all these
phishing scams out there that want you to believe they're your
bank and you really need to enter all your information there RIGHT NOW!
Well, public key encryption gives us a solution.  Basically, all
public key encryption does is split the encryption key into two
parts.  You encrypt a message with one part and it can only
be decrypted with the other part.  You keep one part private (the
private key) and you publish the other one (the public key).  If people
want to talk to you, they go look up your public key, use that to
encrypt a message, and then since only you have the private part
you're the only one that can read it.  But, suppose you want to
prove that a message came from you.  Well, since either part of
the key can encrypt, just encrypt it with the private part of the key
and then anyone who wants can go luck up the public part,
decrypt the message and  be assured that it came from someone
who had your private key.  This is called "signing" and is how you
can tell that something comes from a particular place.  Of course,
the devil is in the details, specifically, how do you get the public key?

Now, with things like PGP (Pretty Good Privacy) or SSH, getting
the public key is kind of ad-hoc.  But, for something like the web,
this won't do.  No one's going to go make sure they get a website's
public key before they visit it, so there's got to be an easier way.
There is, and it's called 3rd party verification.  Basically, browsers
are preloaded with the public key of a bunch of "trusted" (by whom?)
organizations that can then turn around and "verify" other keys.  How
do they verify other keys?  By signing them, of course.  They basically
take the public keys and information about a website you want to visit
and encrypt them with their private key.  When you visit a website, it says,
here's my public key and my information and here's the same thing
encrypted with the 3rd party's private key.  Since you already have the
3rd party's public key preinstalled in the browser, it uses that to decrypt
the information and compares them.  If they match, everything is cool.
If they don't, something's wrong.  This works because the 3rd parties
keep their private keys extremely private so some random website
can't encrypt their details with it and fool you.

Now, there are some variations on this.  A chained certificate is basically
what it says.  Instead of the details being encrypted by the 3rd party's key
that's already in your browser, they're encrypted by one whos information
is encrypted by the 3rd party.  So you have to check one and then check
the other.  This can be extended as long as you want and that's probably
why you had delays with your older certificate.

Note, btw, that if you can get your public automatically installed in
the browser,
you can do whatever you want without having to worry about any other
3rd party.  I believe this is what CACert has been trying to do with mozilla
(mozilla bug #215243), but you can also do it yourself, if you want to have
your users take an extra step (this works well for a small number of known
users, but not very well at all for something like an e-commerce website).
TriLUG does this by letting the users load their public key at
http://www.trilug.org/cgi-bin/loadCAcert.cgi

Anyway, that's the short story about SSL certificates.  I could go into
much, much more detail, but if you've reached the end of this message,
then I'd be very surprised. :-)

Cheers,
Tanner

--
Tanner Lovelace
clubjuggler at gmail dot com
http://wtl.wayfarer.org/
(fieldless) In fess two roundels in pale, a billet fesswise and an
increscent, all sable.