Edgar Muniz Berlinck already gave an overview, and the response of Onosendai describes the protocol very well, but I would like to complement it with the motivation behind the protocol (and make some minor corrections).
When a client (say, Alice) connects to a server (Bob) over the Internet, this connection is indirect - Alice sends the message to Charlie, who sends it to Dave, who sends it to Mallory who sends it to Bob. Bob responds to Mallory, who passes it on to Dave, who sends it to Charlie who sends it to Alice. It is not always known which exact path the packages will take, nor can it be guaranteed with certainty that all nodes are honest. How to ensure that the communication between Alice and Bob is confidential (no one in the middle sees her), righteous (no one in the middle changes it) and authentic (at the other end of the communication there has to be Bob, not someone posing as Bob)?
Cryptography - originated centuries ago in the military, and only popularized in the civil environment after the emergence of the Internet - seeks to solve this problem: sending secure messages through an insecure communication channel. There are two types of encryption: symmetric (the two pairs share a secret) and asymmetric (one of them has a secret that the other does not have). SSL/TLS uses both: asymmetrical to ensure authenticity, and symmetrical to confidentiality and integrity.
Then answering your first question: there is a different key to each connection - the symmetrical one, which is the result of the "handshake protocol" (Handshake) as described by Onosendai. However, the pair(s) of asymmetric keys(s) (the server’s public and private key, and optionally also the client’s) do not change frequently. But that’s no problem, because the private is never revealed, and the public - as its name says - does not need to be kept secret...
(Updating: after a rereading of the Handshake, I realize that there is a public/private pair that is generated at each connection and used to transmit the asymmetric key. A "key cipher key" - Key Encryption Key or KEK. However, the pair whose public key is contained in the certificate, this yes does not change frequently: its typical validity is two years, and it is only used to sign, never to encrypt.)
And how is this key pair (public, private) used to guarantee authenticity? First, the server sends the client its public key. Eventually, he sign something with its private key - proving to the client that he really is the "owner" of the public key. So far so good, but how can Alice be sure that the key she received saying came from Bob really came from Bob? Here comes a case of the egg and the chicken:
Se Alice you already know Bob’s public key (i.e. has saved Bob’s key associated with his computer identity - for example, the domain that belongs to Bob), so it’s quiet. Otherwise, she needs someone she trusts to step in (how to check Bob’s signature if Alice has nothing to compare it to? ). This is done through a certified. A certificate is:
- A public key...
- ...associated with an identity (a name)...
- ...and the pair signed by someone trustworthy.
There’s more than one way to do this - Certification Authorities (CA), Trust Networks (Web of Trust), Notaries, etc. I can’t tell you what the SSL/TLS protocol supports, but the most common is the use of Certification Authorities. They are, roughly, a set of companies whose public key already comes inlaid in the software you use. If you are using Firefox, for example, you can check who they are by Ferramentas -> Opções -> Avançado -> Certificados -> Certificados (de novo) -> Autoridades
.
(Note that the ICP-Brasil is not on that list... already noticed that whenever you try to enter a secure Government website the browser gives an invalid certificate alert?)
If you have for example a website, and you want it to be available safely to the general public, there’s not much to do but pay for one of these companies to verify your identity and sign your certificate (creating the certificate is the least one can do). Taking into account that not every OS or browser recognizes all CA. But if all you want is to distribute an application to a restricted audience (say, something that will only be accessible to your company’s employees) you can also create a Root Certificate - used to sign other certificates - and install it manually in the users' browser. Thus avoiding having to pay for this service.
(Always remembering that the means to distribute this root certificate has to be safe. Egg and chicken, remember? You could take it by hand, on a flash drive for example, but to distribute via internet you would need again help from someone you already trust...)
Closing then, after the delivery and verification of the certificate (which is a relatively slow process, as pointed out by Onosendai, but only the first time, when the certificate is not in the cache), it is necessary to ensure the authenticity of Alice. This can be done also via certificates, but the most common is to omit this step (later, the use of a simple username and password tells the site who the user is - without being part of the SSL/TLS protocol). After both are authenticated, symmetric encryption is used - this is very fast - for normal communication.
+1 per describing Handshake
– jean