What Is Perfect Forward Secrecy in SSL/TLS?

Everything you need to know about TLS perfect forward secrecy — summed up in layman’s terms

If you ask a hundred ordinary web users to identify a safe website from an unsafe one, 90 of them would likely point to the padlock in the browser address bar. In one way, it’s good; in another way, not so much. It’s good in terms of users being able to identify SSL-enabled websites, and it’s a concern because not all SSL-enabled websites are safe.

Today, we’re going to talk about SSL/TLS perfect forward secrecy (PFS), an SSL/TLS feature that most of website administrators aren’t aware of, leave alone the common users. In a nutshell, it’s a way to protect individual channels of communications even in the unlikely event that a hacker cracks a server’s private key.

But before digging deep into what perfect forward secrecy in SSL is, let’s first understand a major security flaw within public key cryptography.

Key Exchange Insecurity: How Private Key Compromise Could Result in a Catastrophe

As you might know, SSL/TLS certificates work on cryptographic method known as public key infrastructure. In this methodology, two cryptographic keys are used for authentication between the server and the browser. The public key, which is publicly available, is used for the encryption of the data, and the private key, which is stored securely on the web server, decrypts the data encrypted by the public key.

In the traditional key exchange, the private key essentially becomes the heart of the SSL/TLS ecosystem. Therefore, if a malicious actor gets their hands on a server’s private key, they can use it to intercept encrypted traffic for any amount of time and decrypt it. =

Such a flaw is possible because the SSL/TLS secure protocol uses something called a “pre-master secret” for verification of the client and web server. When the client (a user’s browser) comes into contact with the web server, it   encrypts a random string of bytes using the public key and sends it to the web server. Using its private key, the web server decrypts the pre-master secret to authenticate itself to the browser. Once this is done — and if everything goes according to plan in terms of it being successful— the server uses the pre-master secret to generate a symmetric session key that’s used for encryption of the data transmission. This way, the data is actually encrypted by a third key, not the private key.

However, upon compromise of the private key, a hacker could decrypt the pre-master secret, and use that to obtain the session key(s). Which would mean that all of the past and present data can be at the fingertips of the cybercriminal. That’s quite dangerous, isn’t it? This is why people turn to perfect forward secrecy in SSL as a solution to the weaknesses of traditional key exchange methods.

Perfect Forward Secrecy in SSL: What It is and How It Can Save Us from Disaster

As we saw, the reason behind damage that private key compromise incidents could cause is its use for the authentication of the “pre-master secret.” What if we eliminate this vulnerability altogether? We’ll be able to protect our data from a potential private key compromise, right? Well, that’s what SSL perfect forward secrecy (or TLS perfect forward secrecy, if you’d prefer that term) is all about.

Instead of deriving the shared secret (session key) from public/private key pair like in an asymmetric encryption key exchange, TLS perfect forward secrecy uses a cipher suite that utilizes the Diffie-Hellman key exchange. The Diffie-Hellman key exchange generates a new set of Diffie-Hellman parameters for each session. Because the DH ephemeral key exchange relies on mathematical calculations rather than a true authentication mechanism, it means that even if a cybercriminal gets their hands on the server’s private key, it won’t be of any use for helping them crack the encryption.

In layman’s terms, super complex mathematical formulas are used to generate an ephemeral or temporary session key for each session, and this key is used to encrypt data. So, once the session is over, the old key will be of no use and a new key will have to be generated. That’s why even if a hacker somehow cracks the session key, they can read the data of the current session only, unlike what we saw previously. This helps you to mitigate or minimize potential damage. And mind well, cracking the session key is mightily difficult as it’s derived from a mathematical formula.

A Small Problem with SSL/TLS Perfect Forward Secrecy

As we saw, perfect forward secrecy involves a complex Diffie-Hellman key exchange. As a result, calculating such a complex mathematical formula adds to the computational load of a server. But this is a pretty minor overhead that web servers should be able handle without much of a problem. If you implement it with ECC (elliptical curve cryptography), then the process is quite a bit faster. The challenge, though, is that certificates using ECC aren’t very popular or as widely accepted as certificates that use RSA-based key exchange.

How Can I Implement Perfect Forward Secrecy?

Implementing SSL perfect forward secrecy is quite easy to achieve when you have the right tools at your disposal. Something you’ll want to do is ensure that you’re using the ECDHE key exchange instead of the standard RSA key exchange method. This isn’t to say that you won’t want to use the RSA public key encryption algorithm — you just won’t want to use the RSA key exchange, which is prone to issues and has actually been eliminated in TLS 1.3.

Many web servers such as Nginx support it automatically on SSL-enabled websites. On other servers, all you need to do is to keep the elliptic curve Diffie-Hellman and DH ciphers at a higher priority than other ciphers on your server’s list of cipher suites. In return, web browsers will automatically extend support for perfect forward secrecy.

Simple and elegant. Isn’t it?