Perfect forward secrecy (PFS), also simply known as forward secrecy, is a cryptographic method of ensuring the security of data transactions between a client and a server.
It guarantees that session keys will not be compromised, revealing past communications, even if the private keys to a particular exchange are revealed by an attacker. This is achieved by generating new (ephemeral) session keys for every transaction.
While PFS offers a high degree of security, it is not a foolproof method and is vulnerable to breaches in the context of a man-in-the-middle (MITM) attack.
Read more below about how perfect forward secrecy works, where its vulnerabilities lie, and how to enable it!
Perfect Forward Secrecy Security Assessment
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
What is Perfect Forward Secrecy?
To understand PFS, it is necessary first to understand the basics of data transfer between clients and servers and asymmetric encryption methods, such as those used in the Secure Shell (SSH), Secure Sockets Layer (SSL), and Transport Layer Security (TLS) protocols.
Asymmetric encryption
To secure online communications and protect them from third parties in asymmetric encryption, a pair of keys (public and private) are used. Each part holds the private key secret, whereas the public key is available to the outside world.
For a client to send a message to a server, they utilize the server’s public key to encrypt that message. After the encrypted message is sent, the server utilizes its private key to decrypt the message and read it. I.e., the public key cannot be used to decrypt the message, only to encrypt it.
How does the Initial Connection Negotiation and Authentication between Client and Server Occur?
The client must initiate the handshake process to establish a secure connection to the server and authenticate itself. During this initial handshake, they will send a message to the server and specify the ciphers that they support, along with a random number (#1). The server responds to this by specifying the cipher that it will use with the client, along with a random number of its own (#2), and its SSL/TLS certificate.
The client then follows up by creating a pre-master secret (PMS) which they encrypt with the server’s public key. Once the server receives this encrypted pre-master secret, it uses its private key to decrypt it. At this point, both the client and the server have the random numbers and the pre-master secret.
Based on all of this, a symmetric session key (the master secret) is generated by both parties that they will use henceforth when communicating with each other. I.e., the server’s private key is used both during the authentication stages and when encrypting the shared master secret with the client.
But since the server’s private key is used in both instances, this means that if it is revealed by an attacker, it can be used to decrypt any communications between client and server. This also remains valid between different sessions – where the session key varies – because the private key is still part of generating the shared secret.
If an attacker has recorded or downloaded and stored encrypted traffic between a client and a server over a period of time, once they gain access to the key, they can decrypt all of this information. The Heartbleed bug, a type of OpenSSL attack, presented this challenge since it allowed the server’s private key to be extracted.
How Perfect Forward Secrecy works
Implementing perfect forward secrecy is one way to avoid the dangers of a server’s private key being stolen. PFS overcomes this vulnerability by utilizing a key exchange algorithm separate from the encryption method. In this way, the authentication process is separated from encryption.
This is achieved by using the Ephemeral Diffie-Hellman (DHE) or the Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange mechanism.
In this scenario, the server’s private key is still used for authentication, but one of the above two mechanisms is used to agree on the master secret, i.e., the session key. This is an ephemeral session key, meaning that the server will generate new Diffie-Hellman parameters for each session (or a single message, page load, etc.).
Since these parameters can never be reused, they are considered ephemeral and thereby offer an additional layer of security between the private key and the session key, as well as between sessions.
Moreover, when using a Diffie-Hellman key exchange, servers and clients do not exchange session keys in a typical way during the handshake process. Instead, a session key is generated independently by both parties, with no prior knowledge of each other. This means that the session key cannot be obtained by monitoring the data transferred at that moment. And, due to the complexity of the mathematical operations involved in generating a single session key, a brute force attack cannot be launched effectively to hack the key.
Finally, even if an attacker obtains the session key, the data they will be able to retrieve is very small. This makes perfect forward secrecy a safe key agreement protocol method.
Using Perfect Forward Secrecy with SSL/TLS
During the handshake in SSL and TLS protocols, the cipher suites that will be used to encrypt data are negotiated between the client and the server. PFS is compatible with TLS and SSL since neither mandates the exact cipher suites to be used.
This means that you can set up the server only to use the suitable cipher suites that support perfect forward secrecy, i.e., either type of Ephemeral Diffie-Hellman key exchange. This is also known as “server gating” in that the server resists utilizing any other type of encryption cipher than the ones specified in the setup.
Giving priority to DHE or ECDHE and disabling other types of encryption is important in the context of the FREAK attack. During a FREAK attack, a server may be triggered to use weaker forms of protection than the highest ones possible. This makes the server vulnerable to attacks via older versions or via different encryption methods.
Vulnerability information
Perfect forward secrecy contains several possible vulnerabilities.
PFS is intended to hinder attackers from obtaining session keys that would allow them to decipher communications. What forward secrecy cannot prevent is an attack that seeks to influence how the session key, i.e., the encryption key, is generated.
Suppose an attacker is capable of modifying the functioning of the session key generator, thereby making the random values that are generated for the purpose of the key exchange predictable. In that case, they will be able to decipher all future communications. This was the problem with the Dual Elliptic Curve Deterministic Random Bit Generator, which had a backdoor that allowed the generator to be modified in such a way.
Perfect forward secrecy also does not protect against a man-in-the-middle attack (MITM), in which an attacker can record and modify communications between a server and a client. While PFS protects against the decryption of such communication, it cannot prevent it from being collected if an attacker positions themself in the middle. In principle, obtaining and keeping such records leaves the door open for them to be deciphered in the future once quantum computing becomes more widely available.
Though not a vulnerability in itself, one of the reasons for the slow adoption of PFS on a wider scale is the additional computing resources required by the server to generate unique session keys. PFS also lacks legacy support which also somewhat limits its implementation.
Finally, implementing PFS results in a lack of internal visibility of data. Since it encrypts network communications, tech teams cannot locate problems and fix them because they cannot decrypt the traffic. There are workarounds to this problem, such as installing an SSL/TLS inspection device to act as an intermediary.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
How to Enable Perfect Forward Secrecy?
To enable PFS, configure your webserver only to use recent cipher suites that include PFS. See the following article for details: Secure TLS Configuration
Here is how to configure PFS manually in Nginx and Apache.
Enabling PFS in Nginx
- То locate your SSL protocol configuration on the server type (assuming /etc/nginx as the base directory):
grep -r ssl_protocol /etc/nginx- Proceed to add the following lines to the configuration:
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_prefer_server_ciphers on;- Set the SSL cipher and choose your preferred cipher configuration (with or without RC4, or RC4 as a last resort). The configuration currently recommended is:
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';- Restart Nginx using:
sudo service nginx restart
Enabling PFS in Apache
- То locate your SSL protocol configuration on the server type (assuming /etc/apache as the base directory):
grep -i -r "SSLEngine" /etc/apache- Proceed to add the following lines to the configuration:
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on- Set the SSL cipher and choose your preferred cipher configuration (with or without RC4, or RC4 as a last resort). The configuration currently recommended is
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';- Restart Apache using:
apachectl -k restart
Why should I use Perfect Forward Secrecy?
If you’re planning to use TLS/SSL connections, you’ll need to ensure that the session keys remain safe even when the private key is compromised. This is where Perfect Forward Secrecy comes into play. If you don’t implement Perfect Forward Secrecy, you may lose control over the encryption keys once the private key is compromised, allowing attackers to read all past communications.
PFS Video Explanation
FAQs
Is There Any Way I can Avoid Using Perfect Forward Secrecy?
There’s no easy way around it. A MITM attack is still possible but requires considerable effort on the attacker’s part.
What Is The Difference Between Perfect Forward Secrecy and Forward Secrecy?
Perfect forward secrecy is a feature of a protocol or system that ensures that the session keys cannot be decrypted by an adversary who obtains the private key.
Forward secrecy is the property of individual sessions. It ensures that session keys are unavailable to an eavesdropper who obtains the session key material. Forward secrecy is important because it allows users to reuse their existing credentials without fear of compromising their privacy.
