How do HTTPS keys get shared?

Question

I am only a beginner who doesn't know much about HTTPS. I have heard that the protocol uses some kind of a key which shared between the two parties. If an attacker wishes to attack could he be able to capture the key and perform an attack on the connection?

Answer 1

No, an attacker listening to the SSL connection is unable to get a copy of the keys.

This is actually a fairly fundamental property of SSL (or any other protocol that encrypts traffic); we're encrypting the traffic because someone might be listening in, and we want to prevent them from being able to understand the traffic. We do this by having the two side share keys, and using those keys to encrypt the traffic. If the guy in the middle could recover the keys, they could listen in. Hence, any encryption protocol must have some story why someone in the middle cannot recover the keys.

Actually, SSL can do it a number of ways, depending how what the two sides agree on (the "ciphersuite"). I'll describe the most common method.

This method (which I believe is used when, say, you're doing a connection with Amazon) depends on the magic of Public Key Cryptography. What this allows us to do is have one side (the Server) generate two related keys, the "public key" and the "private key". Someone can encrypt a message with the "public key"; however the public key does not allow you to decrypt; in essence, it acts as a "one-way" box. However, someone with the private key can decrypt messages.

So, here is a simplified summary of it works: you (the client) ask the Server for a copy of its public key; it gives it to you. Then, you pick a random value (the "premaster secret"; at your level, you can think of it as the session key), and encrypt that with the servers public key, and send that. The server then receives the encrypted value, and then decrypts it. At this point, both sides share the same premaster secret (the client because it originally picked it, the server because he just decrypted it), and so can use that value to come up with the session keys.

Now, here is what someone in the middle hears:

• The Server's public key.

• The random value encrypted with the public key.

Now, the Server's public key does not allow him to decrypt the random value (remember, the public key allows only encryption), and so he cannot learn the value that was shared.

Now, if you think about this, one thing may occur to you: how does the client know that the public key he got was actually the Server's public key; couldn't someone who can modify messages in the middle substitute his own public key and pretend to be the server? Well, SSL does have defenses against that; however, that involves more Public Key Cryptography, and so I'll leave that out for another day.