I’ve written about SSL/TLS here before, and concluded that it’s generally a safe way of maintaining secure communications for sensitive data and eCommerce transactions. For the most part that conclusion still holds true, in spite of later revelations about the trustworthiness of some algorithms. But there is a theoretical chink in the armor of SSL that I didn’t address before. I thought it would be interesting to write about it and how it could be solved — and is solved by some online services.
I’m going to keep this article at a fairly high level and not go into as much depth about SSL, so you might want to read the earlier article (and crypto experts out there should keep in mind that I’m deliberately simplifying).
In order to set up secure connection along which data will be encrypted, it’s necessary for there to be a shared secret between the server and the client. They each have to know and agree on a key or similar that can be used to encrypt data passing between them.
SSL has a clever way of generating this shared secret. When the client first connects, after the initial hello messages, the server sends a certificate that contains the public part of a public/private key pair. The client uses that public key to encrypt a premaster secret, which it then sends to the server. Data encrypted with the public key of the server can only be decrypted with the matching private key. The server decrypts the premaster key with its private key. Both the client and the server carry out some mathematical operations to generate shared session keys, which are used to encrypt the rest of the communication.
The weakness in the system lies with the server’s private key. If that’s made available to bad guys or stolen, then intercepted communications may be decrypted.
Perfect forward secrecy (PFS) is intended to close that hole. Session keys are still generated, but the process is different and the shared secret is never transmitted across the Internet. With PFS, both the client and the server generate a new public-private key pair and share their public keys. Both ends then use their private key and the other party’s public key to calculate a shared secret — the shared secret is identical. This process is called the Diffie-Hellman Key Exchange. The math involved here is seriously complicated, but if you’re interested, take a look at this excellent non-mathematical explanation or this paper (which is math heavy).
Usually the shared secret is then used to generate a symmetric key, which is more efficient than using a public-private key for large amounts of data.
Because the public-private key pairs are generated for each connection and not stored long-term on the server, the weakness in SSL as it’s traditionally used is closed.
The bad news is that PFS adds complexity and increased resource use, so it has not seen widespread adoption. Twitter uses it, and so does Google, among others, but the vast majority of sites don’t offer perfect forward secrecy.
Photo credits: RLJ Photography NYC