Perfect Forward Secrecy (PFS) constantly generates new, temporary keys for each communication session. This "ephemeral key" approach ensures that even if a single key is compromised in the future, only the data from that specific session is vulnerable, significantly limiting data exposure. Unlike older encryption methods where one key unlocks all past and future sessions, perfect forward secrecy prevents attackers from decrypting past conversations or future communications, even if they obtain a single key.
Perfect forward secrecy surpasses traditional encryption methods in that, in older methods, when a user begins a session with a client, the same unique key encrypts the entire communication. If this key is ever breached, it jeopardizes all the information exchanged in each part of that session.
Secrecy in encryption can be categorized as either forward or backward. Perfect forward secrecy is designed to protect against future breaches affecting previous sessions, potentially safeguarding sensitive information like passwords or other secret keys. On the flip side, backward secrecy focuses on addressing breaches that have already occurred in past sessions, helping to secure sensitive data from those incidents. While both types aim to secure data from previous sessions, their approaches differ: forward secrecy is about proactive prevention, whereas backward secrecy deals with corrective action.
Several years ago, I wrote a blog about why TLS 1.3 is such a huge improvement over previous versions. Basically, the protocol was rewritten from the ground up to secure new encryption environments. While this radical rethinking is incredibly valuable to our future security, it may also require us to rethink the ways that we implement features such as TLS/SSL inspection. As you may have guessed, I’m talking about perfect forward secrecy, which is possibly the most significant reason why TLS 1.3 is more secure.
TLS Machine Identity Management for Dummies
Why is perfect forward secrecy important?
Perfect forward secrecy prevents previously recorded and encrypted sessions and communications from being retrieved and decrypted by a cybercriminal who may compromise long-term keys at any time in the future. Even if cybercriminals are able to steal a private key from a particular session, they will only be able to view the data specific to that particular exchange. This greatly reduced risk exposure because new parameters are being constantly generated.
Unique session keys are freshly generated for each session, so they are not exposed while being sent back and forth. Because they are created using the Diffie-Hellman key exchange protocol, the session keys do not depend on any prior knowledge. That safety precaution prevents a cybercriminal from gaining access to a session key by decrypting the data sent during the handshake.
How does perfect forward secrecy work?
Here’s the simplest way I can describe forward secrecy. Imagine if a new key was generated each time I went to unlock the front door of my apartment, with a changing lock to match. When I unlock the front door and go into my apartment with all of my heavy grocery shopping, I drop my key into my mailbox. That’s okay because next time I lock my front door and go out into the city to do more grocery shopping, a newly generated key appears in my purse, and the lock on my front door again changes to match. It doesn’t matter if a burglar acquires my old house key, it was only good for the last time I entered my apartment. Cool system, eh?
Here’s a more technical explanation, pertaining to how forward secrecy is implemented in TLS 1.3.
TLS 1.3 employs the Ephemeral Diffie-Hellman key exchange protocol. This protocol creates a temporary key, uniquely generated for a single network session. Once the session concludes, this key is immediately discarded. While hackers might attempt to intercept and decode TLS 1.3 encrypted data, the complexity of this task is formidable, often demanding extensive computational resources and potentially taking months or even longer.
In earlier versions of TLS, the implementation of perfect forward secrecy was a possibility, but in TLS 1.3, it has become a required feature. This shift is significant in the realm of cybersecurity, as often security measures are not fully used until they are mandated. Thus, making perfect forward secrecy obligatory in TLS 1.3 represents a substantial advancement in securing digital communications.
Benefits of perfect forward secrecy
One of the biggest benefits of perfect forward secrecy is that it provides far better protection by generating a unique session key for each transaction. This reduces the amount of information that is vulnerable if an attack happens to be successful—cybercriminals would only be able to access data from a single compromised exchange. Theoretically, this should make servers protected by perfect forward secrecy less appealing targets because the minimal rewards they offer would not be worth the time and effort it took to obtain them.
Perfect forward secrecy effectively reduces the feasibility of brute force attacks, which, given enough time, can break through even highly secure encryption. The effort and computational resources required to crack security keys that are exclusive to a single transaction are generally not justifiable. Consequently, by limiting the potential gains of such attacks, perfect forward secrecy plays a crucial role in diminishing their value and effectiveness.
How to Enable Perfect Forward Secrecy
To activate perfect forward secrecy, it's essential to set up your web server to exclusively use modern cipher suites that incorporate perfect forward secrecy. Specialists at Avi Networks outline specific measures to implement perfect forward secrecy effectively. These steps are aimed at ensuring a mutual agreement between user and server machines on the type of encryption to be used. As part of this configuration for perfect forward secrecy, it's crucial to arrange your servers in a way that they use recent cipher suites that comply with this protocol:
- Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
- Ephemeral Diffie-Hellman (DHE)
For perfect forward secrecy to be effective, the key exchange process should be ephemeral. This means that both the server and client need to generate a one-time set of Diffie-Hellman parameters, using these keys solely for the duration of a single session. Once the session is concluded, the server eliminates any encryption related to that exchange, rendering the session key virtually ineffective for hackers. This approach ensures that each session's key offers minimal utility to potential cyber intruders.
When possible, opt for Elliptic Curve DHE (ECDHE) suites. They offer a speed advantage over their standard DHE counterparts, making them a more efficient choice for implementing perfect forward secrecy.
To verify that a site is using perfect forward secrecy, check its security details. Presence of “ECDHE” or “DHE” in the security specifications indicates that the site is using forward secrecy.
Proper functioning of perfect forward secrecy requires prioritizing it above other security techniques. Additionally, it's crucial to discontinue the use of prolonged duration session tickets or session IDs, as they retain session information on the user's end for extended periods, occasionally persisting until the system undergoes a reboot.
Perfect forward secrecy and inspection complications
The mandatory forward secrecy in TLS 1.3 makes your network transferred data more secure from cyber attackers. But there are some downsides to perfect forward secrecy.
Network security devices, such as parts of intrusion prevention systems, actively scan packets that travel through them to identify potential malware or different forms of cyberattacks. Typically, an intrusion prevention system relies on decryption keys, widely used across the network, to decrypt these packets for a thorough examination. Web firewalls, for example, often use packet inspection to detect traces of SQL injection attacks. Yet, when specific keys are employed exclusively for short-term data transmission sessions, as seen in perfect forward secrecy, the task of packet inspection becomes considerably more complex.
If only the endpoints (the clients and servers) in TLS 1.3 sessions have the decryption keys, then the security appliances located in between can't see what's inside these packets.
The financial services industry in particular considers it to be important that their security appliances can inspect packets throughout their networks. So they may stick with TLS 1.2 for the time being, where forward secrecy is only optional.
TLS 1.3 proxy servers are another possible option for some organizations. With proxy servers, TLS 1.3 is communicated to the end user, and then the proxies establish new TLS 1.2 sessions through the data center to servers. That’s probably the best way to implement TLS 1.3 while enabling packet inspection, and the IETF TLS committee endorses that approach.
Conclusion
In the cryptography community, many people expect that quantum computers that can crack encryption will debut within the next decade. With NIST support, it’s possible that TLS 2.0 will be available in a few years with post-quantum capabilities. So, some organizations may choose to wait until the soon-coming quantum age.
As far as web servers and email servers are concerned, I still think as much TLS 1.3 adoption as possible is the best way to go right now.
As you've explored the intricacies and benefits of perfect forward secrecy, it's clear that managing your TLS protocols effectively is crucial for robust cybersecurity. This is where Venafi TLS Protect comes into play. It offers unparalleled management and security for your TLS certificates, ensuring that your adoption of perfect forward secrecy is as effective as it is seamless. With Venafi TLS Protect, you can automate the lifecycle of your TLS certificates, enhance your security measures, and ensure compliance with industry standards. Don't leave the security of your communications to chance. Embrace the power of perfect forward secrecy with the added assurance and sophistication of Venafi TLS Protect.
(This post has been updated. It was originally published on May 7, 2019.)
Get a 30 Day Free Trial of TLS Protect Cloud, Automated Certificate Management.
Related posts