How does SSL work anyway?

We talk a lot about how SSL is useful, but how exactly does it work? Most systems today use SSL v3/TLS v1 rather than “SSL”, and the nitty gritty details are found in RFC 2246. However, that’s only part of what goes on, and certificate validation and path building (RFC 4158) and X.509 certificates (RFC 5280) are also important. This post is only concerned with the SSL/TLS protocol itself, and when the other RFCs are needed “magic happens.” If you’re interested, I highly recommend reading through the RFCs. I do assume that you’ve got basic certificate and PKI knowledge while reading this. If you don’t, Mike wrote a great series on it.

SSL/TLS is a handshake. It’s like the secret handshake you used in grade school to get into your clubhouse. That’s how your friends knew you and knew that you belonged. SSL/TLS is how the server and client know each other and decide to trust each other. Instead of the handshake being secret though, the handshake itself is public, and the information passed is based on PKI.

There are two “modes” for SSL authentication – server authentication and client authentication. When you go to your bank’s web site, and log in through a web form, you’re using server authentication. When a server asks you to authenticate, you’re using client authentication. Client authentication implies that the client is also authenticating the server (not always). Each follows a slightly different protocol, but they’re similar.

Server Authentication

1. When you go to an SSL server, the client (your web browser) says, “Hey, I want to use SSL, here’s a list of all the ciphers I support and some random number to start the key generation.”
2. The server selects a cipher, generates a random number, and sends these along with the server certificate to the client.
3. The client verifies the server’s certificate (RFC 5280), and generates a random string. The client encrypts the string with the server’s public key and sends it back to the server. Now, the only way the server can read this “pre_master_secret” is if it has the private key associated with that public key.
4. Both the client and the server use the “pre_master_secret” and the two random numbers to create the encryption and MAC keys (based on the cipher the server chose). The MAC key is used for message authentication. This whole process uses the Diffie-Hellman key exchange protocol.
5. Once both sides have computed these values, they will compute the hash of all the messages they’ve sent so far and sends it to the other side. Each side checks that the hash of all messages matches. That way, they can be sure that the handshake wasn’t tampered with.

Now, both the client and the server know what encryption algorithm and key to use, and that the server is trusted.

Client Authentication

Client authentication is very similar, since it still has to create the key and verify the server’s identity. But now, the server wants to know the client’s identity. So, as part of step 2 above, the server also says, “Here’s a list of all CA’s I’ll accept, give me a certificate.” From there, the protocol changes. In step 3, the client sends their certificate, the encrypted string (encrypted with the server’s public key), and a signed (random) string. The server verifies the certificate. Then the protocol continues at step 4 above.

Other SSL protocols

There are other protocols that are part of SSL that most people don’t see. These are session resumption, re-handshake (i.e., restart), and server gated cryptography. The details are all in the RFC. However, unless you’re implementing SSL, you probably won’t need these details.

References

I highly recommend Rescorla, E. SSL and TLS: Designing and Building Secure Systems for anyone who wants to get more in depth – and it had pretty pictures that sometimes make more sense.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!