Perfect Forward Secrecy: An Insurance Policy for your Encrypted Data

Published on 13 February 2016

As we already know, SSL/TLS couples the best parts of asymmetric and symmetric cryptography to provide a robust mechanism for securing data-in-flight. However, because the key exchange for the symmetric portion of the transaction occurs over the secure channel forged with your public key, whomever holds your private key can reliably decrypt all data intended for your consumption.

What happens though, if someone passively collects your encrypted traffic and merely waits? One of two things might occur: either your private key could be compromised at some point in the future, allowing the attacker to decrypt data going back in time, or computers might progress to the point that they can now brute force the entire keyspace relative to the size of your private key. (Remember Moore’s law?)

What can we do about this? It turns out, that via a mechanism referred to collectively as “Perfect Forward Secrecy” (PFS) we can address this potential avenue of vulnerability by both sides of the communication agreeing upon a new symmetric key for every transaction. Now, even if the attacker compromises the private key for the asymmetric portion of the exchange (no small feat), he’d have to separately brute force each communication. “Wait”, you might ask “How can they agree upon a new temporary key without passing it in the clear somehow?” An Algorithm called Diffie-Hellman provides the answer. Diffie-Hellman allows both parties to derive the same key value based on an initial shared secret. A web server is passed some parameters which are used by both the server and the client in order to play this game of constantly changing up the symmetric key. It’s worth noting that we cannot just use Diffie-Hellman which due to the nature of symmetric encryption, notably does not provide authentication, only private communication. If you want to see this in action for yourself, you can capture some encrypted traffic without a DHE cipher, and feed your private key into Wireshark (www.wireshark.org/). Wireshark will return your communication in the clear. Performing this exercise again, this time using a cipher marked DHE or ECDHE, it will not.

As it turns out though, this method, if implemented improperly, can create more problems than it solves. The very high profile “Logjam” attack in recent months exploits the fact that many web servers shipped with an entirely static (or merely unchanged default) set of Diffie-Hellman parameters shorter than the RSA key size used to authenticate. An attacker would act as a Man-In-The-Middle, and force the client and server to agree upon the easiest mutually supported cipher to crack. (This is a theme when it comes to SSL/TLS vulnerabilities, and at this point the safest thing to do is assume that you’re only as secure as your weakest support cipher). In many cases, attackers now merely had to attack 1024 bit Diffie-Hellman key exchange instead of a 2048 bit or above RSA exchange. Even more horrific, is the fact that because so many servers relied on the same initial secret, pre-computation attacks against those parameters (sometimes even entirely unchangeable without upgrading the web server itself) became possible. (These sorts of pre-computation attacks are of the same sort used with Rainbow Tables, and are frequently used against WPA2 Wireless Networks that seed encryption with commonly used SSIDs).

Have you ever received one of the following error messages from a browser:

“"SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)”

“ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY”

Newer web browsers attempt to mitigate some of these security concerns by disallowing access to websites that use Diffie-Hellman primes (one of those parameters we mentioned earlier) 1024 bits or less. This poses a problem for Administrators, especially if they haven’t seen the error before. If you’re maintaining a service accessible over the web, and your site throws up one of these errors, you’re going to want to fix it as quickly as possible. When it comes to SSL/TLS, trust is the name of the game, and every client who encounters this error might be made to feel uneasy with the security your service provides.

Administrators have four main options in dealing with this problem, each with pros and cons:

You can generate custom Diffie-Hellman parameters greater than 1024 bits. Even if your parameters are of adequate size, this is considered a best practice to introduce additional entropy and make your server safe against pre-computation attacks.
You can switch to Elliptic Curve Diffie-Hellman Ephemeral Ciphers (ECDHE), which derive their uniqueness from parabolic curves. These ciphers also have the benefit of being much faster, however come at the detriment of only being supported by newer clients.
If your Web Server does not support changing your ciphers at all, you can set up an SSL-terminating reverse proxy with software such as Nginx. Nginx can accept requests on behalf of your clients, and transparently re-encrypt with whatever specifications your web service requires.
Finally, if you and your security team have determined that your data only needs to be kept sensitive for a limited amount of time, it’s perfectly valid to disable any DHE ciphers, thus not utilising PFS at all. Simply remove these ciphers from your list of ciphers your web server accepts, and call it a day. Most web services today support at least one cipher for compatibility with legacy clients (Such as Windows XP, or Java 6) that does not take advantage of PFS.

So, to recap, Ephemeral Diffie-Hellman is an algorithm used to exchange of a fixed size (in this case a symmetric key used by both parties to encrypt and decrypt a message of an arbitrary size). We use this technique inside of pre-established session which can also be used for authentication (This is why a publically signed SSL Certificate is so critical. The best place to purchase one of course, including a certificate with Extended Validation is right here. What this accomplishes is insuring that our private communication remains private, even if a malicious party captures our traffic and bides their time. If implemented correctly (using large, non-default parameters) this technique is wildly effective at securing data. Collectively, this is referred to as “Perfect Forward Secrecy”, and is one of the most important tools we have in our arsenal to combat cyber-attack for data that needs to be secured in perpetuity.