What Is Perfect Forward Secrecy?

...and what does it mean for you?

Note: TLS 1.3 now mandates Diffie-Hellman Ephemeral (DHE) key exchanges, aka Perfect Forward Secrecy, for all TLS sessions. Click to hear ExtraHop's VP of Security explain what that means for you.

Explain It Like I'm Five

Perfect Forward Secrecy (PFS) is style of encryption—like Diffie-Hellman or ephemeral Diffie-Hellman key exchanges—that enables short-term, completely private key exchanges between clients and servers: the cyber security Cone of Silence.

Perfect Forward Secrecy

Normally, servers have special encryption keys they use to keep communication sessions private and secure. Whenever Cindy the Client wants to chat with Stan the Server, Cindy comes up with a secret (the "pre-master secret") and encrypts it using Stan's special key. They use this encrypted pre-master secret to continue encrypting the rest of their conversation.

The only people who can decrypt what Stan and Cindy talk about are the ones who know Stan's original key, like his trusty Network team. The Network team is responsible for tracking down the source of any bugs that muck up Stan's system, so it's important for them to know what Stan talks about and with whom.

Trouble is, Stan uses the same key to encrypt every pre-master secret with every client—which means if a hacker were to figure out that single encryption key, they could spy on all of Stan's conversations without anybody knowing.

Sara the Server, on the other hand, uses Perfect Forward Secrecy (PFS) to secure her conversations.

When Cindy the Client starts a conversation with Sara, Cindy and Sara huddle to come up with a unique encryption key—their pre-master secret—that is completely private and will only last for that particular conversation. This is where the Cone of Silence comes in: Without involving Sara's long-term key, Sara and Cindy decide their encryption key behind closed doors. No one, not even Sara's own Network team, can see or hear how they decide their unique key.

This way, if a hacker got their hands on Sara's long-term key, they still wouldn't be able to decrypt any secure conversations. Even if they stole a unique PFS encryption key, only Sara's communications with Cindy would be vulnerable.

Why Is Perfect Forward Secrecy So Hot Right Now?

Two big things happened in the last five years to throw more PFS schemes into the cyber security ring:

First Edward Snowden showed us just how much network traffic has secretly been collected by the United States government—and if one group could run a mass surveillance program, so could others. For the first time in human history, global secret surveillance was not only a possibility but a reality.

That said, the IT community had lived with an inherent degree of risk for years. The longer you keep a secret, the more time you give bad guys to figure it out. Luckily, long-term SSL keys were secure enough that this danger seemed manageable.

Then the Heartbleed vulnerability proved how simple an OpenSSL attack could really be. After years of putting up with long-term SSL keys and still reeling from the Snowden revelations, the community rumbled louder for a more transient method of key exchange.

Fast forward a few years? Apple has decided all App Store apps must use PFS encryption—and in March 2018, the Internet Engineering Task Force finalized the new TLS 1.3 standard, which mandates perfect forward encryption for all TLS sessions.

Unfortunately, the beauty of Perfect Forward Secrecy is also its biggest problem: hackers can't decrypt your data … but unless they utilize one of two very specific decryption methods, neither can your own team.

How to Decrypt Perfect Forward Secrecy

The only ways to decrypt PFS sessions are to route traffic through a set of TLS inspection devices, or to install an agent on the server. One of these doors leads to safety and the other leads to death. (Or at least, to a higher potential of performance issues.)

Door #1: TLS inspection devices establish themselves as false endpoints between a client and server, thereby tricking both. That leads to two distinct TLS sessions with the inspection device smack dab in the middle. More TLS sessions means more resource requirements, and the fact that an inspection device must actively finagle its own session with each legitimate endpoint means you risk breaking TLS authentication and causing other problems.

Door #2: Installing an agent on the server means integrating a third party solution with your server so they can grab those encryption keys from the inside and provide visibility without breaking each individual TLS session in half. There's a wide variety of agents capable of carrying out this process, and how much pressure this method puts on your resources depends entirely on how lightweight that agent ends up being.

ExtraHop Reveal(x) Decrypts PFS in Real Time

We won't lie, we hope the fact that you read this far means you might be on the hunt for a better way to support the TLS 1.3 standard while providing your IT Ops and Security teams the visibility they need to actually keep doing their jobs.

ExtraHop Reveal(x) is the only network traffic analyzer that gives you the ability to decrypt Perfect Forward Secrecy in real time (and with "need-to-know" control over exactly which packets you decrypt and who's allowed to see them), and it's completely out-of-band so won't impact network performance in the slightest. Reveal(x) uses ML to auto-detect and correlate threats inside your enterprise, then gives you the fastest, most efficient path to root cause.

Check out the live, interactive online demo to see how Reveal(x) helps SecOps—and the rest of your org—support modern encryption and still act with confidence and speed!

Subscribe to our Newsletter

Get the latest from ExtraHop delivered straight to your inbox.