Forward secrecy and TLS: limits of PFS ciphersuites (part I)

Much has been made recently of switching to perfect-forward secrecy in TLS. CNet has lavished praise on Google for being a pioneer in this area in a puff piece (never mind that these suites were included in TLS1.2 spec in 2008 and shipped in Windows client and server circa 2009 for anyone who cared to use it.) Latest update to the SSL/TLS deployment best practices includes the recommendation to prioritize PFS ciphersuites when configuring a web server.

Perfect-forward secrecy

First a bit about what PFS. PFS ciphersuites use a nested key-exchange, adding one more step to the process of deriving session keys used to protect the exchange of information between client and server. In ordinary TLS ciphersuites those session keys are exchanged in one step using the server’s long-lived RSA key, followed by a confirmation steps to verify that both sides ended up with the same value. But that means if server RSA key is ever compromised– even at later date in the future– someone who recorded a transcript of a previous handshake can now go back and decrypt it to obtain those session keys. Session keys in turn allow decrypting all of the subsequent traffic.

PFS introduces a Diffie-Hellman key exchange (either plain vanilla DH or elliptic-curve) that is in turn authenticated by the long-lived RSA or ECDSA private-key. Even if that RSA key is later compromised, it  is too late for the DH exchange that was already protected in the past. Attacker faces the problem of solving that particular Diffie-Hellman problem, which is conjectured to be computationally difficult and related to the problem of discrete logarithms. More importantly each DH exchange is a separate problem; there is no single “key” to break that will magically solve all of the other instances with no additional effort. (Except for the disturbing possibility that most of them are based on a small number of elliptic curves. Some discrete-log algorithms involve a precomputation phase tailored to a specific curve, after which solving individual logarithms in that specific curve becomes more efficient.)

Limits of forward secrecy

PFS can not prevent an attacker from decrypting future communications after coming in possession of the secret keys. But due to the way TLS implements forward secrecy, attacking such communication requires tampering with the traffic in real-time, using an active man-in-the-middle attack. Armed with the server RSA keys, an attacker can impersonate the server to perform a different Diffie-Hellman  exchange, using inputs chosen by the attacker instead of the original website. This allows arriving at the same session keys as the client for encrypting future traffic. To make the exploit truly transparent, the attacker then has to turn around and relay the decrypted traffic to the original website using an independent TLS connection.

Forcing an active MITM already raises the bar in three ways:

  1. Actively modifying traffic is more difficult than simply monitoring and recording it. For example setups that involve “diverting” a copy of each packet to a collection point will not work.
  2. It must be done in real-time. It is not an option to store lots of traffic, in the hopes of going back to decrypt it when keys are later obtained.
  3. It can be discovered– in principle.

#3 is where things get interesting.

Working around Diffie-Hellman exchange

When the adversary is carrying out the second part of the MITM attack– connecting back to the original server to relay the exact same traffic the user sent– she has to initiate another TLS handshake. This handshake can reuse some of the same bits sent by the original user. For example the exact same initial key-exchange message can be recycled. The contents of that  message were only protected using the long-lived RSA key of the server; by assumption our resourceful attacker already has their hands on that key so they can decrypt it.

But she can not use exactly the same DH messages that the original user picked. Those messages were based on a random, hidden value only known to the user, never revealed during the execution of the protocol. (Recall that in DH exchange both sides converge on the same result– which becomes the agreed-upon secret key– by combining their hidden value with the input sent by the other side.) That means the attacker has to improvise: she substitutes a different DH input with the known underlying random value. That leads to a divergence in protocol messages: the bits communicated when the user (mistakenly) believed they were talking to the server are different from the bits the server received when it (mistakenly) believed it was talking to the original user.

Updated: Oct 15, to clarify PFS handshake details.




Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s