(1 votes, average: 5.00 out of 5)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

December 9, 2020 3

Perfect Forward Secrecy Explained

in Everything Encryption, Hashing Out Cyber Security

Perfect Forward Secrecy Ensures HTTPS Traffic Stays Encrypted – Even if the Private Key is Later Compromised

Imagine for a second that someone breaks into your house. They can theoretically take whatever is in your place at that moment. That’s a scary enough thought right there. But what if it went a step further? What if they could also pick from everything that’s ever been in your house in the past? And then be able to steal any future item you purchase, as well? Sounds like a nightmare scenario, doesn’t it?

Unfortunately, the same thing can happen with your data. Encryption keeps it safe, but only as long as your private key is safe. We all dread the thought of one of our private keys being compromised, ending up in the hands of a hacker. Your future communications would immediately be at risk. Not only that, but what’s stopping them from examining your past data for juicy, sensitive information that they can exploit for their own gain?

But don’t worry, it’s not all doom and gloom. Cryptographers have once again come to the rescue! A solution was created to deal with exactly this sort of problem, and it’s called “perfect forward secrecy.” Long story short, it prevents future security incidents from compromising past encrypted data.

More and More Site Owners Are Taking Advantage of Perfect Forward Secrecy

Even better, it’s a security feature that is continuing to become more and more common. All major browsers support it, as do post-Windows XP operating systems. SSL Labs found in their October 2020 scan that 21.8% of surveyed sites supported perfect forward secrecy with all modern browsers and 64.5% supported perfect forward secrecy with most browsers. Only 1.2% of sites didn’t support perfect forward secrecy at all.   

The numbers keep going up, and the support of industry giants certainly hasn’t hurt, either. Google has been using it with Gmail and other products for years now, and Apple made perfect forward secrecy a requirement on the App Store in 2017. When TLS 1.3 was introduced, the Internet Engineering Task Force (IETF) mandated perfect forward secrecy, only allowing cipher suits that offered it. It’s an important part of the future of cryptography, and for good reason.

So how exactly does perfect forward secrecy work? Why is it such a powerful security feature? And how can you go about enabling it on your own server?

Let’s hash it out.

The Need for Perfect Forward Secrecy

Without the use of perfect forward secrecy, the repercussions are far more severe if a private key is compromised. Suddenly, an attacker instantly has access to all the past data that was transmitted between a client and server using a particular key. Hypothetically, they could record encrypted traffic for as long as they like, waiting until they’re able to get their hands on the private key. Then, once they have it, they can go back and decrypt everything they’ve been logging.  

Let’s say you login to your online bank using HTTPS to protect your password as it’s sent over the internet. Next year, a hacker manages to get their hands on your bank’s TLS private key after the sysadmin accidentally uploads the private key to GitHub. Could a hacker use that private key to decrypt your session data from last year and get your password? Without forward secrecy, the answer is yes.

Hackers can do this when perfect forward secrecy isn’t present due to the nature of the key exchange between the client and the server. First, the client creates a pre-master secret, which is encrypted with the public key of the server. Then, it’s sent to the server, where it’s decrypted with its private key. Now, both the client and server have the pre-master secret.

From this point forward, session keys are generated based on the pre-master secret, and are used for the back-and-forth communication. These session keys are called the master secret. But what if the server uses the same private key repeatedly for the pre-master encryption process? Then, if an attacker were able to steal that key, they’d be able to eavesdrop on and decrypt all the server’s encrypted communications, past data included.

To make this scenario happen, the attacker would monitor traffic to obtain the two random numbers used in the encryption process (one by the client and one by the server). They are transmitted in plain text, so it wouldn’t be difficult. They could also obtain the encrypted pre-master secret. Since they now have the server’s private key, they can decrypt the pre-master secret with it. At this point, they have all the pieces of the puzzle necessary to generate the master secret, and thus decrypt all the session data.

One particular session may not contain any sensitive data, but if hackers are watching long enough then there’s a good chance that they’ll eventually be able to find something worth their while.

Threat Prevention With Perfect Forward Secrecy

Heartbleed Proves Why Perfect Forward Secrecy is Necessary

You may remember hearing about the Heartbleed vulnerability. It was an OpenSSL bug that was discovered in 2012 and eventually patched in 2014. Hackers took advantage of a server operation called a “heartbeat request”, which was usually used to determine if the server was still online.

With Heartbleed, attackers told the server that they were going to send the server a 64KB heartbeat request message, but instead they sent a much smaller one. The server would reply with the short message that was originally sent to it, but since the server thought it was supposed to be replying with a longer one, it would pad the rest of the message with whatever data happened to be in its memory. The attack could be run over and over to gather large amounts of data, which could contain literally anything – passwords, personal data, session data, even the server’s private key.

Since the heartbeat request is a routine event it never gets logged, so you can’t go back and see what data was actually sent. See the problem here? If the server’s private key was in fact compromised, the hacker can intercept and decrypt traffic and no one would have any idea. With perfect forward secrecy however, this entire scenario can’t happen.

Protection in a Post-Quantum World

The proliferation of quantum computers is inevitable, and it’s really just a matter of time before they are available for general use by the public at large. When that day arrives it will render many cryptographic algorithms useless, exposing data that was originally thought to be secured. So, what’s to stop a hacker from collecting encrypted data now with the intention of saving it until they can get their hands on a quantum computer and crack it?

The answer is nothing. In fact, many cybercriminals are currently carrying out this type of attack, commonly referred to as “harvest and decrypt.” Specifically, they’re carrying out the “harvest” portion of the attack in the present day, while the “decrypt” part has to wait for quantum computing. Waiting a few years is a small price to pay, however, if the end result is the decryption of high-value information like state secrets, financial records, or confidential intellectual property.

Where does perfect forward secrecy come into play then? It protects your data because of the symmetric encryption methods used. A quantum computer can’t break it because it won’t have all the pieces of the puzzle that it needs. The session key doesn’t get exchanged over the network, rather it is generated independently by both parties based on complex equations. You can read more about asymmetric & symmetric encryption, and how they work together here.

Without perfect forward secrecy and symmetric encryption however, your data is vulnerable to a harvest and decrypt attack. Let’s look at a standard SSL/TLS handshake, for example. If you can break the private, asymmetric private key, then you can use that to decrypt the handshake. Then you have what you need to determine the session key.

How Perfect Forward Secrecy Helps 

Perfect forward secrecy is a feature of SSL/TLS that prevents an attacker from being able to decrypt the data from historical or future sessions if they’re able to steal the private keys used in a particular session. This is achieved by using unique session keys that are freshly generated frequently and automatically. The session keys are also not directly sent back and forth, since they are created using a method that doesn’t depend on any known prior knowledge (the Diffie-Hellman key exchange protocol).  Therefore, an attacker can’t get the session key by decrypting the data sent during the handshake. 

By using unique session keys, attackers are only be able to view the data specific to a particular exchange. The risk exposure is thus greatly reduced. Hackers will be less likely to target a server utilizing perfect forward secrecy since their efforts will result in access to a relatively tiny amount of data. There’s no future gain to be had for the attacker either since new parameters are being constantly generated.

In practice, the website you’re visiting may switch session keys every time an encrypted page is reloaded. Your phone calling app may switch keys after each call. And your messaging app may switch keys after every message sent in a conversation. As a result, the theft of one key doesn’t compromise anything else – neither sensitive information nor other keys.

Perfect Forward Secrecy in SSL/TLS

As you may know, part of the SSL/TLS handshake involves the server and client agreeing on the cipher suite to be used for encrypted communication. For perfect forward secrecy to be implemented, a compliant type of encryption must be used. Currently, two key exchange algorithms will work:

• Ephemeral Diffie-Hellman (DHE)
• Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)

One of the keys (no pun intended) is that exchanges must be ephemeral, which means that the session keys are one-time use only. And since they are based on random values supplied by each party in the exchange, each new key is unique. After each use, all the encrypted information relating to the transaction is deleted and new Diffie-Hellman parameters are generated. This is what limits the use of a compromised session key to one particular session only.

The other key is the Diffie Hellman key exchange protocol itself. Thanks to the complex mathematical operations behind Diffie-Hellman, the session key cannot be obtained via brute force.  This is because, as we mentioned earlier, it’s not actually sent sent at any point and is generated via an independent mathematical method. It makes the server’s private key useless to the attacker because the corresponding public key is never used to encrypt anything.

Things to Know Before Implementing Perfect Forward Secrecy

Before you deploy perfect forward secrecy on your website, there’s a few things you should know:

• More processing power needed. This is due to the fact that a unique session key must be generated for each new transaction. Of the two key exchange algorithms we discussed, ECDHE is the faster of the two, but still results in an increased processing requirement of roughly 20%. This could possibly lead to slowdowns that can impact your customers.
• Lack of legacy support. While nearly all current browsers and operating systems support perfect forward secrecy, older servers and operating systems don’t. This is something to keep in mind if you are still using older hardware somewhere in your organization.
• No internal visibility of data. With perfect forward secrecy, your own internal teams will be blind to your encrypted network communications. If you have server problems for instance, then it can make diagnosing and fixing them a bigger challenge than it would otherwise be. There are solutions to this however, like installing an SSL/TLS inspection device on the server.
• What ciphers your server is already using. You can check in your browser to see which cipher is being used by your HTTPS connection. Here’s a quick-hit article from GSX that walks you through the steps for identifying which cipher is being used by an HTTPS connection in Chrome and Firefox.

Implementing Perfect Forward Secrecy on Your Server   

This process for enabling perfect forward secrecy support on your server is a pretty simple process, and most modern servers are already configured for it. If not, you can generally do so in four straightforward steps:

1. Go to the SSL protocol configuration
2. Add the SSL protocols
3. Set an SSL cipher that’s compatible with perfect forward secrecy
4. Restart your server

We’ll get to the specific configuration process for both Nginx and Apache servers shortly.

While perfect forward secrecy is easy to enable, it’s also easy to incorrectly configure it. Below are a few important things to remember as you’re going through the process:

• Compatible ciphers have been available since SSLv3, but we recommend making sure you have support for the latest TLSv1.3 protocol (which, as we covered, mandates perfect forward secrecy)
• Not only must you pick the right cipher suites, but you must make sure they are ordered correctly:
  • You’ll want a Diffie-Hellman key exchange that’s ephemeral as well (since it generates a different session key for each new session)
  • Make sure to include and prioritize Elliptic Curve DHE suites, since they’re faster than regular DHE
  • The Logjam attack, which was discovered in 2015, targets DHE with weak DH group and DHE_EXPORT cypher suites. Therefore, we recommend you disable DHE-EXPORT cipher suites, and use the custom DH group instead. Then, adjust the size of the DH key in the custom group to match whatever the current standard long-term key size is (2048-bit, as of this writing).
    • If your server doesn’t have an option for custom DH groups or to adjust the DH key size, then simply disable DHE cipher suites altogether and use ECDHE.
  • A common mistake is to include the appropriate cipher suites but then forget to enforce the order of them. Enabling support for DHE/ECDHE isn’t enough for perfect forward secrecy, they must be given priority by the server. To force perfect forward secrecy, simply disable other types of ciphers (The FREAK attack for example, also discovered in 2015, was an exploit that forced the server to use one of the lower priority and weaker cipher suites).
• Disable longer-duration session IDs and tickets that may retain data after a user ends their session. Sometimes it even takes a full reboot to fully purge the server of old session tickets.

After completing all of the above steps, the top of your list of cipher suites should look something like this:

• TLS_EDCHE_RSA_WITH_AES_128_CBC_SHA
• TLS_EDCHE_RSA_WITH_AES_256_CBC_SHA
• TLS_EDCHE_RSA_WITH_3DES_EDE_CBC_SHA

Configuring Perfect Forward Secrecy on Nginx

Note: These directions are applicable only to specific versions of Linux.

1. Locate the SSL protocol configuration with the following command:

grep -r ssl_protocol /etc/nginx

2. Add the SSL protocols to your configuration:

ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

ssl_prefer_server_ciphers on;

3. Set the correct SSL ciphers, and reference our tips in the previous section in order to pick the right ones. The example below works well on modern servers and provides a high level of security:

ssl_ciphers ‘EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH’;

4. Restart your server:

sudo service nginx restart

Configuring Perfect Forward Secrecy on Apache

Note: These directions are applicable only to specific versions of Linux.

1. Locate the SSL protocol configuration with the following command:

grep -i -r “SSLEngine” /etc/apache

2. Add the SSL protocols to your configuration:

SSLProtocol all -SSLv2 -SSLv3

SSLHonorCipherOrder on

3. Set the correct SSL ciphers. You can do this using the following command to provide high security on a modern server:

SSLCipherSuite “EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH”

4. Restart your server:

apachectl -k restart

Here are some additional resources that may be useful:

• Apache.org’s article SSL/TLS Strong Encryption: How To
• Qualys’s article Configuring Apache, Nginx, and OpenSSL for Forward Secrecy

Set Up Perfect Forward Secrecy to Protect Your Data Moving Forward

As the TLS protocol has advanced, the concept of perfect forward secrecy has continued to grow in importance. With this evolution has come increased adoption for its implementation by web browsers, operating systems, communication software, and industry giants all over the world. As a result, more and more site owners can now use it to further boost security and protect their data.

If you’re using legacy systems without perfect forward secrecy, you should strongly consider upgrading. It will take some time and effort, but in the end it’s a small price to pay for the benefits provided. You’ll be a much less attractive target to attackers, since even a successful attack won’t gain them much, if anything.

Either way, the industry is moving in the direction of perfect forward secrecy, and it’s inevitable that it will be a requirement in the future. It’s up to you whether to make the switch now or wait until it’s absolutely necessary. However, if you deal with sensitive information or are subject to data regulation laws, then it’s nothing but a good idea to embrace perfect forward secrecy as soon as possible.