I’ve been having to sit down and actually learn how SSL happens. I mostly knew it from HTTPS as encrypting HTTP / internet browsing but it turns out it also provides the useful functionality of authentication, i.e. how do I know who you say you are. This is pretty useful in the land of services communicating over the network, because not only do you want the communication encrypted but you also want to make sure that you’re only talking to and accepting requests from people you trust.

Authentication and The Handshake

An SSL session first starts off with a handshake: a back and forth communication between two machines where they first identify themselves and then set up encryption for the rest of the session. An interesting problem here is even if you have a great encryption mechanism, how do you guarantee you’re communicating with the right person? What stops anyone from just claiming, “Hey it’s me your friend, Google, give me your password”? More accurately, the server presents a public key and you would like some proof that this is actually Google’s public key.

This is addressed by having a third party, a Certificate Authority (CA), verify someone’s identity and then issue out certificates that can be used as proof. As long as you trust the CA isn’t issuing them irresponsibly and they can’t be faked, it works out. A similar example would be a driver’s license: if you want to verify someone’s identity, you can ask to see their driver’s license, trusting the third party that issues the licenses (the government).

The certificate contains a bunch of stuff like version, issuer, validity dates, but most interestingly the server’s public key and the CA’s signature. When a CA issues out a certificate, it at the very least confirms that the public key being presented in the certificate is owned by the machine/organization requesting the certificate (by confirming they have the private key). Then if everything is good, the CA signs the certificate. (The CA is supposed to go through whatever bureaucratic/background checks are needed to make sure that some random person doesn’t just get a certificate claiming to be Google. Not sure how much this actually happens.)

A lot of this depends on public/private key encryption, which is probably what comes up for a developer. The gist is you have two keys, one is publicly shared and the other is kept secret (they’re aptly named). If someone encrypts a message with your public key, it can only be decrypted with your private key so only you can read the message. The other way around works too: if you encrypt something with your private key, it can be verified with the public key (so only you could have encrypted it), which can work as a signature.

So another way of looking at it is the CA provides the service of verifying a public key presented by a server is owned by the organization/service the server is claiming to be. It signs this with it’s private key, so you can verify the certificate was not forged.

There are a lot of CA’s in the world, and companies might even have internal CA’s/infrastructure around this process called Public Key Infrastructure (PKI). A lot of this process seems to come down to if you trust the issuer of the certificate.

The rest

At this point the two machines can be sure each other is who they say they are. They then come up with a temporary/disposable symmetric key that they can use to encrypt the rest of the session. This way different sessions are isolated from each other, and if things get compromised later, saved communications aren’t necessarily compromised.

After that, you’ve got encrypted communication for your application!

Other neat things