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.
What’s perfect forward secrecy?
Perfect forward secrecy (also called forward secrecy) is an encryption system that frequently and automatically changes the keys used to encrypt and decrypt exchanges between clients and servers. These temporary private key exchanges improve security because it limits exposure by isolating communications. A unique key is generated for every individual session initiated by a user. That way, if the most recent key is compromised, data from any other session will not be affected.
With traditional encryption, on the other hand, when a user initiates a session with a client, the entire exchange is encrypted using the same special key. If that key becomes compromised, so does all of the information that is shared within each portion of the exchange.
There are two types of secrecy: forward and backward. Perfect forward secrecy guards against future compromises of past sessions, which could cause the loss of sensitive data such as passwords or additional secret keys. Backward secrecy helps mitigate compromises of past sessions and the loss of sensitive data from them. While both serve to protect data from past sessions, they differ in intent: forward secrecy is preventative while backward secrecy is remediating.
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 compromises 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. Becausethey 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 uses the Ephemeral Diffie-Hellman key exchange protocol, which generates a one-time key that’s used only for the current network session. At the end of the session, the key is discarded. Cyber attackers can still record TLS 1.3 ciphertext and try to crack the encryption later on, but it’s a very difficult process that could require loads of computing power over the duration of months or longer.
There was the possibility for forwarding secrecy in older TLS versions, but now it’s mandatory! Sometimes security features won’t be used thoroughly until they’re made to be mandatory, so it’s an excellent development.
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 the 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 also discourages brute force attacks, which can eventually penetrate even very secure encryption. It’s simply not worth the time and computing power to try combinations of security keys that are limited to a single exchange. For this reason, perfect forward secrecy ensures that brute force attacks won’t be as worthwhile.
How to Enable Perfect Forward Secrecy
To enable perfect forward secrecy, configure your webserver only to use recent cipher suites that include perfect forward secrecy.
Experts at Avi Networks recommend taking the following steps to enable perfect forward secrecy. The goal is to make sure that the user and server machines must agree upon the encryption type. Therefore, when configuring forward secrecy, set your servers up to make compliant cipher suites available:
- Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
- Ephemeral Diffie-Hellman (DHE)
The key exchange must be ephemeral, meaning the server and client will generate a unique set of Diffie-Hellman parameters and use the keys just once per session. The exchange-related encryption is deleted from the server after the transaction ends, which ensures that any given session key is almost useless to hackers.
If possible, select Elliptic Curve DHE suites. These are faster than the standard DHE counterparts.
To determine whether perfect forward secrecy is enabled, refer to the security details of a site. If it is using “ECDHE” or “DHE” then it is currently using forward secrecy.
It’s important that you prioritize perfect forward secrecy over other security methods to ensure it works properly. It is also important to halt long duration session tickets or session IDs. These hold onto session information on the user’s side for extended periods of time—sometimes until the system is rebooted.
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 components of intrusion prevention systems inspect packets that travel through them, looking for malware or other types of cyberattacks. An intrusion prevention system will typically use decryption keys used throughout the network to decrypt packets so their contents can be inspected. Web firewalls often look for indications of SQL injection attacks with packet inspection. But if specific keys are only used for limited data transmission sessions, packet inspection becomes very challenging indeed.
If only the endpoints of TLS 1.3 sessions, the specific clients and servers, have decryption keys, the security appliances that exist somewhere in between become blind to the content of their 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.
(This post has been updated. It was originally published on May 7, 2019.)
Get a 30 Day Free Trial of TLS Protect Cloud, Foolproof Certificate Management.
Related posts
