Perfect Forward Secrecy (PFS) support now available

Version imprimable, PDF et e-mail

In medieval times, interception of a messenger or pigeon was a key spying strategy. In WWII, decrypting the ENIGMA gave significant leverage to the Allies, which some consider “decisive” to the allied victory.

A modern version of this is attacking SSL sessions. There is a bunch of different flavors to such attacks – targeting weak ciphers, playing man-in-the-middle (MITM), compromising data at the endpoints right after decryption (Heartbleed?), side channel attacks (padding oracle). But as you can guess from the post's title, this post is about future decryption of data that is captured today.

In a post-Snowden world, this is becoming increasingly relevant.

What is the problem with the “usual SSL”?

Julius Caeser used a Cipher, in which each letter was substituted by another letter 4 places to the left of it in the alphabet. For example, A would become D and B would become E. All that the recipient needs to know is “4” and he or she can work backwards to get the original text. Thus the master secret here is “4”. There has to be some other secure mechanism to communicate this master secret. One could assume that Caesar did this as a in-person communication with a confidante.

SSL works somewhat similarly. A new master secret is set up to encrypt and decrypt the data for every SSL communication. However, in non-PFS SSL, this master secret is always derived using the private key with the premise that this key will never fall into the wrong hands. However, if it does, and if that party was also eavesdropping and recording your encrypted data for long periods, they can re-generate the master secrets and decrypt all the data.

This is how common packet capture tools like wireshark, allow you to import private keys to decrypt SSL data read from the wire, for testing and debugging purposes.

The key weakness in this scheme: the private key is a “single point of failure” for all your current, future and past SSL communications. Someone recording your data today, and obtaining or breaking your key 5, 10 or 20 years from now can decrypt all that data then.

How does PFS help?

As you would expect, PFS decouples the relation between the master secret and a static key. Temporary keys are now generated for every session and discarded after use. This is accomplished by an algorithm called Ephemeral Diffie-Hellman, the implementation details of which are out of scope here. This algorithm is abbreviated as DHE.

The key point here is that since there is a unique key for every session, the attacker can only decrypt that specific session, were she to get her hands on the “temporary” key. All other sessions are immune to being decrypted from that key. In the context of Heartbleed, if you were using PFS, then you might not have been forced to change your keys immediately due to this “ephemeral” nature of PFS.

From a performance viewpoint DHE involves complex mathematical operations that make it slow. Fortunately, the latter has been overcome using something called elliptical curve cryptography. The resulting algorithm is abbreviated as ECDHE.

Configuring PFS in the Barracuda Web Application Firewall

From version onwards, the Barracuda Web Application Firewall offers full support for PFS. To configure PFS, navigate to the BASIC::Services page and edit any HTTPS service.

In the SSL section, for Ciphers, choose Custom, this will show all the available ciphers. Move the ECDHE-* ciphers from the Available to Selected Ciphers. To prioritize them over other ciphers, make sure you move them to the top of the list. To do this, remove all the other ciphers and add them again. They will move to the bottom.

Note that the Barracuda Web Application Firewall retains control over the cipher selection, when the client browser and server (e.g. WAF) have a common set of ciphers. The WAF always selects the common cipher highest in it's list. Also note that you can continue to use your common RSA certificates with ECDHE ciphers (as indicated by the “RSA” after “ECDHE” in the cipher names). However, in this case, RSA is only used to prove the identity of the server but not to keep the communication secret.

In a future release, we will make PFS a single click operation, in true Barracuda style.

PFS Operational Impact – not much

Most modern web browsers today support ECDHE, however their older versions may not. So, to be “backwards compatible”, you need to have those other ciphers available in the Selected Ciphers box above. In case the user is using an older browser without PFS ciphers, the negotiation will happen on a common non-PFS cipher and nothing will break.

The elliptic curve size we have used in the ciphers above is P-256, which in theory is as strong as 3248-bit RSA keys. Current NIST recommendation for RSA keys is 2048, so P-256 represents a stronger key to break by comparison (by brute force computational methods, etc).

Performance wise, ECDHE handshakes have been benchmarked to be roughly ~20% slower than RSA 2048 handshakes. This cost is only incurred in a full handshake. If the session is resumed, then there is no overhead, since  ephemeral keys are not re-generated. Given that many sessions are resumed, the overall performance hit may be less than 20%. However, having long session timeouts can break forward secrecy. Thus, we limit the session resumption timeout to 30 minutes after which the ephemeral keys are discarded.

Couple of caveats to using PFS – debugging of HTTPS sessions becomes harder since the private key is not enough and monitoring your own user realm (e.g. for compliance, policies, leak prevention, etc) may be more difficult as well.

Reverse Proxies facilitate PFS

Passive security devices like IPS/IDS or even some span port and layer 2 (bridge mode) WAFs face a challenge with PFS, since in order to work with SSL, they require that they be configured with the server's private key. However, as noted above, the private key is not really used for encryption in PFS, so such devices are left in the lurch. There is little they can do to protect HTTPS traffic.

A reverse proxy like the Barracuda Web Application Firewall, offloads all the SSL communications from the protected servers. This is useful in a couple of ways. One, since the PFS ciphersuites are actually handled by the WAF itself, the problem above does not arise. It can safely decrypt and inspect all the HTTPS data. Second, it prevents you from having to enable PFS on all your protected server farms in your secured zone, which could be intrusive or not even possible on some systems at this time.

More information on the Barracuda Web Application Firewall is available on our website.

Connect with us on Facebook, LinkedIn, Twitter or Google +. Check out our videos on YouTube

S'abonner au blog

Remonter en haut de page