In this article we have reviewed what is Perfect Forward Secrecy and how it works. Here we will discuss the way to check if your server supports FS.

There are lots of ways to check whether the server uses the key exchange that provides Forward Secrecy.
In this section we will review only a few of them, which, in our view, might come in handy.

Method 1. Check the connection details in your browser.

You can easily detect whether the FS is supported by the server with your browser.

For Google Chrome the procedure will look as follows:

1. Connect to the website you wish to check.
2. Hit the green padlock sign in the URL address bar.
3. Switch the tab to Connection.
4. Here you can check the key exchange mechanism negotiated by both parties during the session establishment.

We have learned that only DHE and ECDHE key exchanges provide the Forward Secrecy, so let’s take a look at a few examples:

In this example we can see that our connection to Namecheap is secured using the RSA algorithm (AES_128_GCM) for the authentication purposes only, while the session key generation relies on ECDHE key exchange mechanism.

The above example shows the pure RSA usage. The long-term keys are used both for the server’s authentication and for the session key generation by means of RSA key exchange mechanism.

The last example shows how Google Chrome determines the DHE key exchange mechanism.

For Mozilla Firefox, the check is performed in exactly the same way:

1. Connect to the website you wish to check.
2. Hit the grey or green (in case the EV SSL is being used) padlock sign in the URL address bar.
3. Press the More Information... button.

4. In a new window you will see whether the connection is established using the key exchanges that provide FS (ECDHE, EDH) or not.

Again, we see that the RSA keys are used here for authentication purposes, the first part of the line (which contains ECDHE) is for the key exchange and the second part (AES ...) is for the encryption itself.

Non-FS connection will look like this:

Method 2. Check it with SSL Labs server test.

Another easy way to check the support of the FS key exchanges is to run the SSL Labs test.
Just enter the domain name you wish to check and hit the Submit button.

This global tool allows you to check a great number of the server-side and SSL-related settings and see the grade of the current configuration.

In order to preeminently check the support of the Forward Secrecy property, after the server analysis is completed, you will need to scroll the results page down to the “Protocol Details” section and check the value of the Forward Secrecy parameter:

Sometimes, you can see the following result:

This means that the server is configured to prioritize the key exchanges that provide FS when connecting to modern browsers, however, has a few non-FS cipher suites enabled to include the support of legacy systems.

If the server does not support the FS property, you’ll be notified about that on the Summary page:

Method 3. Check it with OpenSSL.

OpenSSL toolkit also allows you to check the support of the FS key exchanges.
The following commands should be used:

openssl s_client -connect example.com:443 -cipher "ECDHE, EECDH"
openssl s_client -connect example.com:443 -cipher "DHE, EDH"

Be sure to change the example.com to the domain you wish to check.

ECDHE, EECDH and DHE, EDH define the Elliptic-Curve Diffie-Hellman and Diffie-Hellman Ephemeral key exchange mechanisms respectively.

If the command results in a “sslv3 alert handshake failure” error, the Forward Secrecy property is not supported by the server.

Note: If the server’s certificate uses SNI, you’ll need to include the “-servername example.com” option. Example:

openssl s_client -connect example.com:443 -servername example.com -cipher "ECDHE, EECDH"

FS at Namecheap hosting

At Namecheap, we are keeping our finger on the pulse of the modern technologies, therefore, the Forward Secrecy is deployed on all our hosting servers, including the Value, Premium, Business and Reseller plans.

Taking into account the aforementioned vulnerability in DHE and DHE_EXPORT ciphers with the weak DH group called Logjam, the support of the DHE key agreement was completely disabled. ECDHE is used instead.

Elliptic-Curve Diffie-Hellman (ECDHE) key exchange avoids all known feasible cryptanalytic attacks, and modern web browsers now prefer ECDHE over the original DHE key exchange mechanism.

This, however, brings up some compatibility issues with legacy browsers, like IE6 on Windows XP.

Conclusion

All in all, Forward Secrecy is a great improvement in securing the encrypted traffic transmitted through the public channels. It mitigates the risk of the previous sessions’ secrecy to be disclosed if the server’s secret key is compromised. Unfortunately, it is not so widespread as it should be. According to the SSL Pulse, about 30% of all the websites using SSL/TLS protocols do not provide the Forward Secrecy at all. We hope the situation will change soon, as the RSA key exchange mechanism is going to be deprecated in the upcoming release of TLS 1.3.