Before we start talking about Perfect Forward Secrecy (PFS), let’s understand a little bit about the context of how we got here. In the initial moments of using the Internet, in our communications between client and server there was little concern about maintaining security. This was not a focus at the time.
Then, around 1994, a company called Netscape Communications Corporation (originally Mosaic Communications Corporation), which at the time was developing a browser called Netscape – and if you, like me, remember it, I want to tell you that we are old – started to introduce the idea of secure communication. For this purpose, they used a protocol that would guarantee the integrity and privacy of the data.
And this is how this communications security process started, which was reinforced in 1999 by the Internet Engineering Task Force (IETF), making it a communication standard. This evolved and we arrived at the newer versions of the current protocol called SSL.
You can also listen to the audio version of this article:
SSL is an excellent protocol, safe in its latest versions, but still strongly attached to the use of cryptographic keys that must be exchanged and used for the encryption of the entire communication channel.
What happens is that all content is encrypted using this key exchanged between the client and the server. However, as secure as it is, the entire content uses only a single key.
Thinking about this, we can imagine a scenario where an exploiter can capture all traffic exchanged during the communication process. Even though he cannot access the content – because it is encrypted – he can store this content and then seek to compromise or obtain the key used for encryption. This is a real scenario and has already been demonstrated as possible.
Finally, we reach the relevant thinking in order to understand the PFS.
PFS – Perfect Forward Secrecy – what is it
Without going too far into the details of building the protocol, PFS is a cryptographic model where temporary encryption keys are produced between the client and the server.
So, what is different with the model used by TLS?
Imagining a normal communication between a client and a server using TLS, we will have the use of a secret key just like in PFS. But when we make a new communication, or from another client user with the same server, we will use the same secret key to establish the new connection – and that is the difference.
Therefore, for each of the sessions created between the client and the server, there is also the creation of a unique and individual key, guaranteeing the exclusivity of the key for that session.
That means that if there is the leaking of the content from that session, without the key nothing can be accessed, nothing has changed in relation to the model already known. However, as we have one key per session, the key can only be used for generated content.
Thus, with a focus on protecting the transport layer data, PFS has become a security standard. As such, it must be observed by the developers for the implementation of messaging services and/or even for systems that focus on ensuring user privacy.
In this way, message exchange systems that use PFS as a model can change cryptographic keys as often as they exchange messages. To reinforce this, the Internet Engineering Task Force recently published a document revising the TLS standard and now requiring the use of PFS for all connections as mandatory.
How to use PFS – Perfect Forward Secrecy
Using PFS is quite simple, as it works on sites that use SSL or TLS.
Therefore, as we know, SSL and TLS are cryptographic protocols that allow secure connection communication to exist.
Knowing this, in order to ensure the secure connection between the server and the user’s machine, both must agree on the type of encryption that will be used.
To ensure that PFS is used, you simply need to configure your servers to offer these two communication protocols:
• Ephemeral Diffie-Hellman (DHE)
• Ephemeral Elliptic Curve Diffie-Hellman (ECDHE)
However, the exchange of keys must be configured so that they are used only once. In the process, this is called ephemeral key exchange. After the transaction takes place, the encryption related to the exchange is deleted from the server. And it is this process of exclusion that ensures that to every new connection a new key will be created.
Enabling PFS on your NGINX and Apache servers
If you check a website’s security settings and see that “ECDHE” or “DHE” is used, this server is already using PFS.
The majority of modern servers will already have this configured.
Even so, if you still don’t have PFS enabled, we can show in the examples below that it is quite simple.
Nginx
First, locate your SSL protocol configuration (assuming / etc / nginx is the base directory for your Nginx installation):
1. You must first locate your SSL configuration file (/ etc / nginx)
grep -r ssl_protocol / etc / nginx
2. Once you find it, just add these lines to the file.
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_prefer_server_ciphers on;
3. Define which ciphers will be used, and for that you have some options. What you should be aware of is what level of compatibility with older browsers you want, but you can choose the list below, for example:
ssl_ciphers ‘EECDH + AESGCM: EDH + AESGCM: AES256 + EECDH: AES256 + EDH’;
4. Now just restart the service:
sudo service nginx restart
Apache
1. Locate the configuration file:
grep -i -r “SSLEngine” / etc / apache
2. Add these lines to the file:
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
3. Define the ciphers to be used:
ssl_ciphers ‘EECDH + AESGCM: EDH + AESGCM: AES256 + EECDH: AES256 + EDH’;
4. Restart the service:
apachectl -k restart
It is important to note that even though it is easy to configure PFS, it is also easy to configure it incorrectly. This may mean that, even if enabled, it may not be the type of security you are using.
And one of the most common mistakes is simply to enable support for DHE or ECDHE and not enable these methods as a priority on the server. This means that if another security method is prioritized by the server, this is the one that will be used.
What might be a good idea is to disable all other types of security if you have decided to use PFS. This can prevent a Freak Attack.
Likewise, it is important that you disable long-term session IDs or even session tickets. This is because in these two parameters there is information related to the sessions, even after the session ends on the user side.
Where Perfect Forward Secrecy is used
PFS is and has been strongly adopted by information providers since its inception, and is known as a crucial security feature.
One example is signal, the message protocol for end-to-end encryption that is now used in WhatsApp, Google Allo and Facebook Messenger, making PFS more popular.
Known as the “double ratchet” system, the signal protocol creates a new key for each message. More recently, a new feature has emerged that is a feature that allows messages to self-destruct.
One of the first use cases was in 2011 when Google started delivering Gmail, GSuite – still called Google Docs – and for its users who use its search engine a communication using PFS.
In addition, Twitter has also started offering PFS to all users since 2013. In 2016, Apple started to adopt a mandatory new protocol for all iOS applications that require the use of App Transport Security.
Get in touch with our AppSec Specialists
An evolutionary process
With this article our goal was to present a new possibility of security in communications, and we believe that we managed to start a little curiosity for those who did not know PFS, we really hope that it had just been the beginning.
What matters is to understand that security is an evolutionary process and we always have new things that can be even more used in the systems and applications we create.
See you in the next article.
