SSL Example

How does SSL work? This is something that every developer should understand, even if they never use the information. It's quickest to explain what happens when I use a service like Mochimarks, my bookmarking app that supports HTTPS.

Before we start, note that Mochimarks has a private key and a public key. Our fundamental assumption (backed up by proofs and research and studies and so on) is that when you encrypt a message using the public key, the message can realistically only be decrypted with the private key. This kind of encryption is called Asymmetric Encryption. The alternative is Symmetric Encryption, where a single key is used by both sides for encryption and decryption.

Secondly, note that there exists an entity called the Certificate Authority (CA), which exists to manage certificates. Each browser and OS comes with a list of Certificate Authorities and corresponding public keys that it knows it can trust.

Now let's step through the flow when I try to access Mochimarks.

1. My browser tries to connect to the Mochimarks server by sending an http request.
2. The Mochimarks server replies with a request to establish a https connection instead by sending an https request.
3. My browser sends an https request.
4. The Mochimarks server replies with a certificate. This certificate is digitally signed by a Certificate Authority and includes the Mochimarks server's public key.
5. My browser checks the https certificate and agrees to use https to connect. The least intuitive step here is how my browser decides it can trust the CA. First, my browser determines the CA that signed the certificate. My browser checks that it trusts the CA against its built in list of trusted CAs. The browser uses the public key of the CA to encrypt a message, which it then sends to the CA. If the CA can respond with the original message, then my browser knows it can trust the CA.
6. My browser chooses a random new symmetric key K to use for its connection to Mochimarks. It encrypts K under Mochimarks's public key. A third party can not decrypt K without the private key, which only Mochimarks has. My browser sends K to Mochimarks.
7. Mochimarks decrypts K using its private key. Now both my browser and the Mochimarks server know K, but no one else does.
8. Anytime my browser wants to send something to Mochimarks, it encrypts it under K; the Mochimarks server decrypts the message upon receipt. Anytime the Mochimarks server wants to send something to my browser, it also encrypts it under K, which my browser decrypts upon receipt. So at this point, we're using symmetric encryption.

Why bother with the Symmetric Encryption when we can use the safer Asymmetric Encryption? Asymmetric Encryption is much slower (more computationally expensive, more data, more steps), so while it's fine to do it once per session, it would cause problems if it was used for every request.