March 23, 2023 0

Mitigating Session Data Exposure: Perfect Forward Secrecy Explained

in Cyber Security

(12 votes, average: 5.00 out of 5)

Loading...

Perfect forward secrecy in TLS 1.3 is what helps to prevent the encrypted session data you’ve sent or received from being decrypted should the receiving server’s private key become compromised at a later time

When people think about encryption, they think about it from the general perspective that it’s a way to protect data confidentiality. And while that’s true, there’s far more to it than that. Every time a user connects to your secure website, their browser and your server exchange information that creates a secure session. This is known as an SSL/TLS handshake, and it’s done by both parties exchanging data to create session keys they can use to encrypt and decrypt data. 

Sounds great, right? But what if the process of exchanging key-related information isn’t secure and the server’s private key or the secret shared session key becomes compromised? Then you’ll find out just how quickly things can go wrong and how past session data relying on even one of a compromised key can become exposed.

This article will explore perfect forward secrecy to understand what it is and why it’s critical to data security on the internet.

What Is Perfect Forward Secrecy?

Generally speaking, perfect forward secrecy, or PFS, is the “secret sauce” that prevents all the encrypted data you’ve sent previously via encrypted sessions from being decrypted by bad guys, even if your server’s private cryptographic key gets compromised in the future.

If you’re raising a quizzical eyebrow, give us a moment to explain. When you connect to a secure website, you’re connecting via a secure session that requires the use of cryptographic keys that, if not stored securely, can fall into the wrong hands. Perfect forward secrecy is about preventing data shared via secure (encrypted) connections from becoming exposed due to key compromise issues by

• Using a new private key each session, and
• Not allowing session keys to be stored for future use.

In a more technical sense, perfect forward secrecy is a set of key agreement protocols designed to keep your session keys — i.e., the keys you use to transmit data to a website’s server in a typical website connection — secure, even if the server’s private key becomes compromised. It does this by making session keys one-time use tools, much like how medical providers use hypodermic needles and medical gloves once and then dispose of them.

To understand perfect forward secrecy more fully, you have at least a basic understanding of encryption. So, let’s detour briefly to quickly recap what encryption is and circle back by talking about how PFS plays a role in internet security.

An Overview of Encryption and PFS’s Role In Creating Secure, Encrypted Sessions

In general, encryption is the process of taking plaintext, readable data and converting it into something that can only be read by someone who has a specific key. Encryption is considered a two-way process because encrypted data is designed to be decrypted using the appropriate private key:

• Asymmetric encryption. In this method of encryption, there are two keys that split those duties — a public key that encrypts it and a private key that decrypts it. This combination of keys is used to create a secure channel through which important key-related values are shared between parties. This data is used to create a symmetrically encrypted session that will be used for the rest of the connection to exchange data with less computational overhead.
• Symmetric encryption. In this type of encrypted connection, there’s one key that encrypts and decrypts data. In this case, this is the secure session key that’s generated by both parties using their private keys in combination with publicly shared values they exchange through the SSL/TLS handshake process, which we’ll explain in just a moment.

What happens when that secure session key becomes compromised? Nothing good, we assure you. But we’ll speak more to that in a bit. But first, let’s consider your website as an example.

When a customer connects to your website, their browser and your web server engage in a TLS handshake. This is a process that enables their client to verify your server’s identity, protect data integrity, and create a secure session that protects data confidentiality. (It’s also what enables them to use the secure HTTPS protocol and makes the little padlock icon appear in their browser’s address bar.)

But what does this process look like? When a customer connects to your website via a TLS handshake:

• Their client and your server use asymmetric encryption to exchange cipher information and special values that can be used to create a symmetric session key.
• The client uses your web server’s public key to encrypt its value so that no one (aside from your server) can read it.
• Your server then uses that data, along with special parameters, to create that secret session key to enables it to establish a secure session with the customer’s client. This symmetrically encrypted connection is what will be used for the rest of the session.

Perfect Forward Secrecy Is Mandated in TLS 1.3

Traditionally (up through TLS 1.2), a server used RSA or traditional Diffie-Hellman key exchange functions:

• RSA key exchanges involve sharing key-related data is transmitted between parties.
• Diffie-Hellman key exchanges involve both parties exchanging public values (non-sensitive data) they combine with their individual secret values to generate a single key.

These traditional key exchange scenarios involved using the server’s key to protect the secure session key values it would share. This was great so long as the server’s private key didn’t become compromised. If that key were to become compromised, then the attacker could use it to decrypt any data they’ve saved that was encrypted using the key’s corresponding public counterpart.

To avoid this from happening in TLS 1.3, the Internet Engineering Task Force (IETF) mandated the use of ephemeral (i.e., dynamic and unique) key values as part of the SSL/TLS handshake. This entails using the elliptic curve Diffie-Hellman ephemeral (ECDHE) key exchange instead of the traditional, non-ephemeral DH. This way, every secure session that’s created using an SSL/TLS handshake has its own set of parameters (rules) that create the session.

According to the IETF:

“In contrast to TLS 1.2, TLS 1.3 provides additional privacy for data exchanges by encrypting more of the negotiation handshake to protect it from eavesdroppers. This enhancement helps protect the identities of the participants and impede traffic analysis. TLS 1.3 also enables forward secrecy by default which means that the compromise of long term secrets used in the protocol does not allow the decryption of data communicated while those long term secrets were in use. As a result, current communications will remain secure even if future communications are compromised.”

In a static key exchange, such as a traditional Diffie-Hellman key exchange, one or both of those parameters can be reused. But despite what any earth-saving activists say, not everything should be recycled. (At least, this is true when it comes to public key cryptography). For example, in a Diffie-Hellman ephemeral, or DHE, key agreement, those parameters have to change to create each new session and can’t be reused. This changing of the values every session enables perfect forward secrecy, meaning that every session is independent of those that precede and follow them.

This brings us to our next related talking point…

Forward Secrecy vs Perfect Forward Secrecy — Believe It Or Not, They’re Not the Same

It’s likely, at some point, you’ve come across the term forward secrecy. When you look at the words perfect forward secrecy and forward secrecy, and organizations often use the terms synonymously, it’s easy to think they’re the same. (Look at the IETF quote above for such an example.)

However, there is actually an important difference between these two terms:

• Forward secrecy is something that is enabled simply by using a traditional (non-ephemeral) Diffie-Hellman key exchange. This entails two parties connecting using a mutually calculated secret key that’s never exchanged directly. However, both parties will use that same shared key for future sessions.
• Perfect forward secrecy is something you’ll need to take things a step further to achieve. This will require using an ephemeral cryptographic key, such as through an ephemeral Diffie-Hellman key agreement. What this means is that each new session will require a unique key, regardless of whether it’s two new parties or two parties that have connected previously.

Let’s consider these two concepts using the following illustrations:

Image caption: A set of basic graphics that illustrate the difference between forward secrecy and perfect forward secrecy.

How Perfect Forward Secrecy Works

At its core, perfect forward secrecy is what results when you use a unique encryption/decryption key for every SSL/TLS session. The way to achieve PFC is to use ephemeral Diffie-Hellman or elliptic curve ephemeral Diffie-Hellman key exchanges as part of the SSL/TLS handshake.

Why Perfect Forward Secrecy Is Necessary

On its own, forward secrecy would be fine in a perfect world — a magical place where every person, company, and organization adheres to secure key management best practices. But since this is the real world and they often don’t — and since cybercriminals are always looking for ways to get their hands on everyone’s private keys to decrypt data they’ve saved from previous sessions they intercepted — then it means that the server’s private key could become compromised down the road.

This is why ephemeral Diffie-Hellman key exchanges are mandated in TLS 1.3; they ensure that new Diffie-Hellman key exchange parameters are utilized for each session. This way, bad guys who’ve been saving up encrypted data from your sessions won’t be able to decrypt it later because the key will be destroyed after use and will not be stored on the server. It mitigates the potential damages and data exposure you’d otherwise sustain if you used the same session key for each user to secure their subsequent connections.

Cipher Suites That Support Perfect Forward Secrecy

Now that we know what perfect forward secrecy is, what it does, and why it’s necessary, let’s take a look at the cryptographic cipher suites (i.e., combinations of cryptographic algorithms) that make it possible. To do this, we’ll compare it to TLS 1.2 cipher suites so we can see the differences between them.

TLS 1.2 Cipher Suites

According to NIST’s special publication 800-52 revision 2, TLS 1.2 cipher suites are combinations of protocols and algorithms for key exchanges, encryption, and message authentication. For example, a TLS 1.2 cipher suite looks something like this:

                Protocol_KeyExchangeAlgorithm_WITH_EncryptionAlgorithm_MessageAuthenticationAlgorithm  

In all, there are 37 cipher suites supported by TLS 1.2. However, supporting all of them isn’t necessarily advisable because some of them don’t support PFS. Here’s a quick visual of how one of these cipher suites look:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS 1.3 Cipher Suites

Now, let’s compare this to a TLS 1.3 cipher suite, which discards the key exchange algorithm and uses this format instead:

                Protocol_AHEADcipherMode_HashCipher

In that previously linked resource, NIST recommends only four cipher suites that TLS 1.3 servers should be configured to support:

1. TLS_AES_128_GCM_SHA256
2. TLS_AES_256_GCM_SHA384
3. TLS_AES_128_CCM_SHA256
4. TLS_AES_128_CCM_8_SHA256

There is a fifth cipher suite that the IETF says TLS 1.3 supports — TLS_CHACHA20_POLY1305_SHA256 — but that wasn’t included on NIST’s list of recommended cipher suites.

To enable perfect forward secrecy, TLS 1.3 cipher suites are ones you’ll want to support on your server. This is because, in TLS 1.3, session keys are generated only for that current session. Once the session ends, the key gets discarded like last year’s gym shoes — never to be seen or used again.

Still be sure to support ephemeral-key cipher suites as well (those that identify DHE or ECDHE for the key exchange function), though, so you don’t ostracize visitors whose browsers only support TLS 1.2.

How to Enable Perfect Forward Secrecy

If you want to enable PFS for connections on your website, then you’ll need to:

• Enable TLS 1.3 on your web server. You can do this by purchasing and installing an SSL/TLS certificate on your website and setting your server to support TLS 1.3 protocols.
• Adopt elliptic curve Diffie Hellman (ECDHE) or Diffie-Hellman ephemeral (DHE) key exchanges. However, be careful to structure the list of cipher suites your server supports in a particular order. Place ECDHE cipher suites at the top of the list and have DHE cipher suites fall in line after that.

You can still include non-DH cipher suites that may be supported by browsers as a last resort, but keep in mind that this will not offer perfect forward secrecy.

Final Thoughts on Perfect Forward Secrecy

While we’d love to say that TLS 1.3 and its mandated perfect forward secrecy are the standard, we’re just not to that point within the industry. But the good news is that we’re getting there, little by little.

Data from Qualys SSL Labs shows that in February 2023, 99.9% of the 150,000 SSL/TLS-enabled websites they analyzed supported TLS 1.2, and 60.4% supported TLS 1.3. Now, compare this to the 59.8% of the sites they analyzed the previous month that supported TLS 1.3. While this number isn’t necessarily where we want to be within the industry, it’s still great news because it means we’re heading in the right direction as a whole.

• #perfect forward secrecy
• #PFS