SSL (now called TLS)
At the end of the last post, we were at the stage where a client and server could communicate via TCP once they had performed the necessary handshake. The problem with this is that anyone can eavesdrop on this connection, and intercept the messages being sent across. That may be absolutely fine in some cases, but where the data is more sensitive we probably want some additional confidence not only that we are actually communicating with our intended recipient, but that only that recipient will be able to understand our messages.
This is where TLS (Transport Layer Security) comes in. (Aside: TLS Used to be called SSL (Secure Sockets Layer)). This involves yet another handshake (you’ve got to be really good friends before you get to hear each other’s secrets!), which is done in the following way:
- The client sends the server an initial “hello” message, which tells the server which encoding it can handle
- The server responds with its own “hello” message, which contains a few different bits of information for the client:
- Which encodings it would like to use (CipherSuite)
- A session ID – This can be used in future by the client to restart the session, so that the handshake doesn’t need to be repeated
- A server certificate
- Public key of the public/private pair (for encoding/decoding)
- The signature of the server, so the client knows they’re talking to the right one
- The client verifies the server certificate
- Diffie-Hellman key exchange (more on this later)
- The client (optionally) sends a client certificate
- The server verifies that certificate
- The client sends a FINISHED message. This is the first message that is encrypted using the shared key.
- The server sends a FINISHED message. Once both the server and client have decrypted each others FINISHED messages, we know they can understand each other
- Finally, messages can be exchanged securely! Yay!
Diffie-Hellman Key Exchange
This is a method where two (or more) individuals can collaboratively create a shared secret despite sharing information in the public sphere. It’s actually pretty smart, here’s how it works:
Suppose Harry and Ron are trying to communicate securely. They both come up with a public key which they share, e.g. . Next, they each come up with their own secret integer , and send to the other. So
Harry: secret integer 3, send to Ron
Ron: secret integer 4, send to Harry
Harry and Ron then take the number they were sent (), and use that number with their secret integer () to calculate , i.e.
Harry: receives 1 from Ron, calculates
Ron: receives 3 from Harry, calculates
This result is the same! And always will be – i.e. this is their shared secret. Now they can use this to encrypt/decrypt messages to and from one another using it.
Let’s look at what would happen if Draco tried to intercept the messages:
He would know the public key – , and the result of the first calculation, but neither of the secret integers. Therefore, to get to the result of 1 like the other two, he’d have to look at the numbers sent (3 and 1) and try and work out at least one of the secret integers, to then use it in step 2:
Since we’re using small numbers in this example, finding and is a fairly simple task, but in practice with much larger primes this becomes a much more significant ask, even for the most powerful computers. He’s much better off trying Fred and George’s Extendable Ears for eavesdropping…