I understand basically how SSL works: Communications between my
computer and a secure site (including this one!) are encrypted so
anybody trying to eavesdrop on what is sent back and forth is able to
read just gibberish.  I also understand that the encrypted information
is based on an encryption key.  What I don't understand is, what is
there to prevent an eavesdropper from "listening in" during the
handshake when the two computers set up the encryption key? Obviously,
if you could "listen" to both sides of the handshake to find out what
the encryption key is while it is being established, it would be
possible to decipher the rest of the communication.

I don't need any links to explanations of how SSL works unless it
answers this specific question in language I can understand; I've seen
quite a few explanations of SSL, and it's just this one aspect that
puzzles me. If you know the answer without doing any research, feel
free to explain in your own words.

Thanks!

Hello, I hope this information helps!

SSL uses a technique called public-key encryption. Each side of an SSL
transaction has a shared 'public key'. This public key is exchanged -
Party A sends their public key to Party B, Party B sends their public
key to Party A. In addition to both sides having a public key that is
shared, each side also has a private key that is not shared.
Each side can then encrypt their data with the opposite ends public
key ( Party A uses Party B's public key to encrypt, Party B uses Party
A's, etc ). The data thus encrypted can only be decrypted with the
corresponding parties private key - which is not shared during the
initial 'handshake'.

Feel free to rate this answer or to ask for clarification!

---

Clarification of Answer by dandrick-ga on 05 Jun 2002 07:57 PDT

Just adding a line to my original answer - I think you pretty much had
a good idea on how SSL worked, you were just missing the 'key' part of
it, the private key. It works exactly as you described in your
question pretty much except that anyone listening in during the
exchanging of the public keys wouldn't know the corresponding private
keys needed to decrypt whatever information passes between the two
parties.

I would have required a clarification to the answer as given, and I'm
sure I would have received it if I had asked.  But what I was really
looking for was in the first comment (by Iaint), or more precisely one
of the cryptography pages he linked to, which led me to other places
that answered my question.  The key (no pun intended) was looking for
sites that explained cryptography rather than ones that explained
encryption (even though they're very closely related).  What I hadn't
understood -- even though it's obvious now when I read explanations of
SSL -- is the asymmetric nature of the encryption and decryption keys.
 Now that I understand that, everything's obvious.  Thanks to both
Dandrick and Iaint!

I think the point to grasp to make this fully comprehensible is that
of public/private key-pair cryptography. There are many, many articles
on this subject, ranging from the horrendously mathematical down to
simple easy-to-understand explanations of the concept, as well as a
number of excellent books.

In essence, the private key (which is NEVER transmitted) cannot be
derived from the public key, which it is therefore safe to transmit. A
useful analogy is that instead of two people passing each other a
locked box and a key to open it, one passes an unlocked box, the other
puts their message inside, locks it and returns it. The original
person then uses his key to open the box -- because the key is never
sent from one person to another, it remains secure.


Some good resources:

http://developer.netscape.com/docs/manuals/security/pkin/contents.htm
-- deals specifically with SSL and HTTPS.

http://www.faqs.org/faqs/cryptography-faq/part06/ -- includes some
information about the mathematical algorithms involved.

http://home.ecn.ab.ca/~jsavard/crypto/publ05.htm -- a good basic
introduction with links to further reading.

If you find yourself interested by the world of cryptography (and I
think it's a fascinating subject) you might also want to consider
reading the following book:

The Code Book, Simon Singh, 4th Estate 2000, ISBN 1857028899. The
definitive entry in the popular science realm when it comes to the
history of codes, ciphers and code-breaking. Avoids getting too bogged
down in mathematical details.

Answer and comment gave good references on study of cryptography,
Asker asked for specific explanation and answer given: "private key is
never
transmitted" is not really providing that. Private keys are not
transmitted in the handhake of a given session, but they have to get
to be associated with the
corresponding public key somehow. 

This 'somehow' is "Web of Trust", done commercially by 'certificate
vendors'
or by community based PGP-related groups (see reference 2 and 3)
bellow.

Simple example may illuniante this issue: Say, I want to send you a
message.
I encode it with private key (I made up) and I publish the public key.
 If you have my public key then you(and anyone else) can decode itand
know the message and know it was not altered during the transmission.

 If someone will pretend to be me and sends you a different (fake)
public key, he can still fool you. So, you need to go to the third
(trusted) party [whose public key you know] and check that my
published key is indeed mine.
 That someone is the certificate authority (commercial or community
based). And so on. I send them my public key and they know it is from
me and they publish it. You know their public key (it should come with
the computer - really) and
 you pick the public keys of other people from them.
In summary:
 There has to be a trusted intermediary - a third party - as your
intuition correctly guessed - to make it work. In principle, that
secure connection to a third party can be used to transmit a private
key. It is not really needed
and done that way - but the public-key-cryptography does not eliminate
need
for a separate path, to either pass private keys or to athenticate
public keys.
general reference:
http://www.cs.caltech.edu/~adam/local/trust.html

http://www.epinions.com/help/faq/show_~faq_wot

Certificate vendors:
http://directory.google.com/Top/Computers/Security/Public_Key_Infrastructure/PKIX/Tools_and_Services/Third_Party_Certificate_Authorities/
Community based solution
http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto-1.html

A hope this answered your question. Did it?

Although you may feel  comfortable with the answer you were given
above, it is not a correct representation of how SSL works with a web
browser. Unless you have generated a public key/private key for
yourself and bought a certificate, you do not have a public key.  In
fact, you don’t have a private key either.

When you go to a secure web site, your browser will establish a
connection with that remote site, and give a port and address for the
remote site to respond to.  The remote site will send you a copy of
its certificate.  The certificate is encoded using the private key of
a certifying authority such as Verisign.  Data encrypted with a
private key can be decrypted with a public key and data encrypted with
a public key can be decrypted with a private key.  Your web browser
will have the public keys of the certifying authority in its database.
 It does NOT need to get these from the web, or your security could be
compromised.  This database comes with your browser when you get it
from Microsoft, Netscape, Opera or whichever vendor made your browser.
 In order for somebody to forge a certificate, he or she would need to
have the PRIVATE key of the certifying authority.  If the certificate
is altered in any way, your browser will be able to tell when it goes
to open the certificate.

The certificate contains identifying information about the web page
such as its domain name and host name, and its public key.  Since you
got the public key from the certificate, you know that it has been not
been tampered with and your browser will then compare the name of the
web site against the one in the certificate.  If they do not match,
you will get a warning. You now know that you not only have a
certified public key, but you also know that it matches the web
address of the site you are visiting.

If you encrypt something with the site’s public key, that site and
that site only can decrypt it with its private key.  However, if that
site encrypted something with its private key, not only could you
decrypt it with its public key, but also anybody who intercepted the
information could do the same.  This is true since any person could
easily get the public key of the web site from its certificate.  Also,
the process of using public/private key encryption is expensive in
terms of computer resources compared to a straight symmetric key. If
the process did nothing more than what was explained up until now, you
would have an inefficient solution that really only works in one
direction.

A symmetric key is one that can be used to encrypt or decrypt data,
but both parties must know it.  Your computer will generate a
symmetric key to be used for the rest of the conversation with the
remote site.   Since your computer has a verified public key for the
remote site, it can send that symmetric key back to the remote site
encrypted with its public key.  That site, and only that site, can now
decrypt that symmetric key to use for the rest of the session by using
its private key.  If the encrypted key gets intercepted, it does no
good since nobody without the remote site’s private key can use it. 
That site can now send private data to you, which your browser and
only your browser can decode since it is the only other computer with
that symmetric key.  And of course your browser can now sent
information encrypted with that symmetric key to the remote browser,
since it has the key.

Your computer and the remote computer are both aware that there is an
active session, and neither one has any use for this symmetric key
once the session ends.  If you reconnect to this web site at a later
date, the process starts from scratch.

This entire process assures that no data need be sent unencrypted,
including the key itself.  It also assures that no other party can use
the data or get the key, and that if somebody were to somehow get a
copy of the only non-public key that is transmitted, it would do no
good in the future.

Hi,

A few additional points to note, since you have probably downloaded
your Web Browser from the internet you will have downloaded with it
the Certificates of the Root certification authorities.

You must take steps to verify the authenticity of these certificates
by some out of band channel (for instance some newspapers publish the
fingerprints of these certificates for you to check against).
Otherwise you never have any more security than the security of the
original download.

This being the case, do not transmit any information you would not
have sent over the original link (the one you downloaded your browser
on) without first verifying the root certificate. Of course you may
have obtained your browser some other way (like on a Microsoft Windows
CD) which may be more secure.

I would still try and verify the root certificates if you plan to use
SSL for any serious application.  Of course if an attacker wants to
compromise your information he is more lightly to try and break in by
other means than attacking the SSL protocol (taking advantages of
insecure software, and social engineering attacks are much easier).

Hope that helps
  flamingpenguin-ga

ps.
http://www.verisign.com/repository/root.html
Is VeriSign's root certifcate page, but like I said above you 
need an out of band verification as well.

Flaming penguin pointed out that you must verify the root certificate
or this whole thing is not valid.  It's theoretically possible for you
to end up with wrong information about the certifying authority, but
it's close to impossible.

Remember that when you download a certificate, its authenticity is
checked using the public key of the certifying authority.  This key
comes from a database that is already in your browser.  When you
loaded windows or installed Netscape or Opera or Mozilla or your
favorite browser, the information he is talking about is already
there. It's not something that you download independently off the
Internet.
If you don't understand this, read my previous comment thoroughly
until you understand it.

In order for somebody to tamper with this, they would have to force
your browser to have an invalid key in its database.  If I were to
create a phony public key for a certifying authority and get it into
your browser, then I could create phony certificates and put them on
sites to fool you.  The problem with this is that as soon as you went
to a legitimate site with a certificate, it would fail.  So it might
work if I knew that you are going to a specific secure site and no
others, but for practical purposes if you use your browser to visit
sites of your choice, this type of charade would not work.  And it
still presupposes that I have access to your browser to corrupt it in
the first place.

If I spoofed Microsoft so that when you went to download a new copy of
your browser, I substituted my own corrupt copy, I could then fool
you.  But I would then have to have a credible looking phony copy of
any secure web site you would ever visit and a fake certificate for
each, or the scheme would fall apart.  I would have to intercept all
of your Internet traffic and redirect it to one of my sites each and
every time you clicked on a secure site.  In short, I'd have to be
able to read your mind months ahead of time to figure out where you
might be planning to go on the web.

If somebody had that capability, having you verify the keys
independently is of little use, unless you do it literally before each
transaction. If they could get into your browser and change the keys
around, they might have done it after you already checked them and
verified them.  But then again, it's theoretically possible for
somebody to make a hacked version of your browser that displays the
legitimate keys to you when you browse them but uses keys from a
different source when you connect to a site.

All this is creative science fiction.  For practical purposes, it
cannot happen.  Unless you are exchanging information that is
literally worth a billion dollars, it wouldn't pay for a team of
people to even try to go to the lengths necessary to do this.  It
would be much easier to just put a gun to your head and ask you for
the information.