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.
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
- Key Stores & Trust Stores: There are a bunch of different file formats for SSL that might be handy to be aware of:
- .pem (public cert, also shows up as .cert/.crt/.cer)
- .key (has private key for the cert)
- .p12/.pkcs12 (encrypted container for both public/private key)
- You might even have a trust store that lists the only services and CAs you trust, which is better than having everyone trust everyone. A trust store is basically just a list of certificates you trust.
- Mutual vs. one-way SSL in mutual SSL, both machines need to present their certs, verify and trust each other. This makes a lot of sense in the land of services. When browsing the web however, this process is one-way. Your computer will verify the server is really Google, but Google is not verifying your computer.
- This whole process is pretty computationally expensive (I think crypto generally is?), so people like to use a connection pool to amortize the cost of the SSL handshake. With connection pools, connections are kept open so they can be reused by many requests.
- What’s SSL/TLS all about? TLS is newer than SSL, but for the same purpose so they get used interchangeably in conversation.