(H.T.T.)P.S., I love you
Alice and Bob are a married couple who live on the Lower East Side of Manhattan. They are deeply in love, though they fight occasionally.
One winter, Bob dies of an unencrypted website connection, and Alice realizes how much he meant to her, as well as how insignificant their arguments and differences were.
This 2007 internet-protocol-based movie, or ‘net flick’ for short, dramatized the under-explored topic of network security for a popular audience.
Tragically, it was overshadowed in the box office by a movie of a similar name, with the same romantic leads. Perhaps this explains why it never achieved much prominence. In fact, I can find no mention of H.T.T.P.S. I love you online at all.
Let this blog post be a monument to its memory.
Now, to properly understand the driving narrative force, we first need to cover the basics of HTTPS, as the movie assumes a fair amount of background knowledge which the average cinema-goer may not remember from their Internet License test.
What’s the most important thing in a relationship?
That’s right: a secure and authentic connection.
In the case of the web, HTTPS is what we use to establish that secure and authentic connection, on which the ability to communicate depends. That is to say, anyone eavesdropping on the love-letter — or any kind of letter, for that matter— will get an earful of gobbledegook (secure), and, secondly, the recipient can be sure that the letter originated with the one whose signature and soft scent it bears, and hasn’t been tampered with by a rival (authentic).
The difference between HTTP and HTTPS is the addition of a layer, a layer of secure sockets, called a Secure Sockets Layer (SSL) (or TLS, but people still call it SSL because old habits die hard).*
There are two phases to the protocol. The first is the ‘handshake’, and the second is the conversation itself, the usual back-and-forth of request and response.
Let’s talk about the conversation part first. It is encrypted by a relatively simple ‘session key’. That’s a two-way key, meaning if you know what it is, you can use it to easily reverse the encryption to ‘decode’ the message (‘symmetric cryptography’). For example, it might be ‘go forwards/backwards by 2 letters in the alphabet’ (a ‘Caesar cipher’).
Game over if that secret key is discovered: anyone could use the key to eavesdrop on your embarrassing sweet nothings. That’s why the exchange of the session key is done using Slightly More Secure Cryptography, otherwise known as public key cryptography, otherwise known as asymmetric cryptography, more on which later.
The handshake
This is a mechanism which lets the the two love-birds exchange:
- the session key
- what kind of encryption they plan to use
- and a special certificate.
The session key
This is the thing that is going to enable the actual messages — the whole conversation that comes after the handshake — to be encrypted.
The certificate
Any good romantic date, in my experience at least, starts with one party presenting the other with their ID card, to prove who they are. Now, that ID card could either be signed by the one wearing it, in which case it’s ‘self-signed’ and not all that trustworthy, or it could be one of the more fancy kind.
The fancy kind effectively says to the client, “I really am Bob — just ask Charlotte! Signed, Charlotte.”
If you don’t know Charlotte all that well, you then ask her to present her own ID card, which reads “I really am Charlotte — just ask Daniel! Signed, Daniel.”
This dubious merry-go-round continues, passing the buck of trust up a chain from certificate to certificate, until it gets back to a ‘root certificate’ that is built into the browser itself, an ultimate source of trust. Hooray! Alice now trusts Bob is Bob, and can get on with the date.
Public key cryptography
What certificate authorities are really certifying — once they have done the due diligence of checking that the people claiming to own a company or a domain really are the people running it, which is one of those tedious jobs that we keep humans around for — what they are really certifying is that someone owns the public key on the certificate. That key will be one of an asymmetric pair of keys which are arbitrarily assigned the labels ‘public’ and ‘private’. These keys are the results of some complicated maths which produced a one-way function, which means that once something is encrypted with one of these two keys, only the other one can decrypt it, no backsies (‘asymmetric’).
(In fact, you can find the public key for Medium on the certificate for this webpage, by clicking the little padlock up in the address bar and clicking through to the certificate details.)
The key insight (do not acknowledge the pun) here is that the client wraps up the all-important session key in a five-pound note and encrypts it using not a key of its own, but the server’s public key — the one in the certificate. That ensures that anyone who knows the session key, which unlocks the conversation, must be the server, because they are the only one who has the private key.
But how can we be sure that the server belongs to the right person? That is the other function of the certificate, beyond providing the public key. Namely, to verify that the public key which Bob (as the server) is claiming as his is actually correct, and that it isn’t an impostor. Because if you encrypt your love-letter with Eddie’s public key, then Eddie can decrypt it with his private key, and that’s no good at all.
Why not just do the whole thing with asymmetric cryptography?
We don’t encrypt the whole conversation with asymmetric cryptography partly because it’s much slower than symmetric cryptography. That way we get the speed of symmetric cryptography with the security benefits of public key cryptography.
Integrity
The final piece of the SSL puzzle is data integrity. This ensures that nothing has been lost in transit (or changed maliciously). This is sometimes called a checksum, or a digest, or a hash. It’s a signature that’s generated from the content of the letter in a deterministic, irreversible way, which can be performed by sender and recipient to ensure that their copies are identical. There is a good explanation of this at the start of the RailsConf 2019 video in the list of links.
Having explained that technical background to the movie, I have run out of room to discuss the beautiful plot and compelling cinematography. Some day I will finish my review of this fascinating story, but in the meantime, I hope you enjoyed learning about HTTPS and SSL.
*SSL is the general case of this security protocol, and ‘HTTPS’ is when it’s applied to HTTP.
Links and further viewing:
RailsConf 2019 — Modern Cryptography for the Absolute Beginner by Jeffrey Cohen (on public key cryptography in general)
What is SSL, TLS and HTTPS?: enough of these metaphors, what actually literally happens?
