What is Logjam and how do I prevent it?

TL;DR

SSL/TLS client and server agree to use some weak crypto. Well, turns out that weak crypto is weak.

In Detail

When an SSL/TLS protocol is performed, the client sends a list of supported cipher suites, and the server chooses one. At the end of the initial handshake, some Finished messages are exchanged, and encrypted/protected with the newly negotiated crypto algorithms, and the contents of these messages is a hash of all the preceding messages.

The idea is that an active attacker(a MitM attack) could try to manipulate the list of cipher suites sent by the client to remove all "strong" crypto suites, keeping only the weakest that both client and server support. However, this would break the Finished messages. Thus, these messages are meant(among other roles) to detect such downgrade attacks.

In theory, it's fine; unless the client and server both support a cipher suite that is so weak that the MitM attacker can break it right away, unravel the whole crypto layer, and fix a Finished message in real-time. Which is what happens here.

In Even More Detail

When using the "DHE" cipher suites(as in "Diffie-Hellman Ephemeral"), the server sends the "DH parameters"(modulus and generator) with which client and server will perform a Diffie-Hellman key exchange. Furthermore, the server signs that message with its private key(usually an RSA key, since everybody uses RSA in practice). The client verifies that signature(the public key is the one in the server certificate), then proceeds to use the DH parameter to complete the key exchange.

It so happens that in the previous century, there were some rather strict U.S. export regulations on crypto, and this prompted "export cipher suites", i.e. weak crypto that was compatible with these regulations. Many SSL servers still support these "export cipher suites". In particular, some cipher suites that use DHE and mandate a DH modulus of no more than 512-bits. Moreover, most SSLs in the servers use the same modulus, because using the one provided with the SSL library is easier than generating your own. Reusing the same modulus as everybody else is not a big issue; DH tolerates that just fine. However, it means that if an attacker invests a lot of computations in breaking one DH instance that uses a given modulus p, the same attacker can reuse almost all of the work for breaking other instances that use the same modulus p.

So the attack runs like this:

  • Attacker is in the MitM position; where he can modify data flows in real-time,
  • Attacker alters the list of cipher suites sent by the client to specify the use of an export DHE cipher suite,
  • The server complies and sends a 512-bit modulus p,
  • The client is still persuaded that it is doing a non-export DHE, but a DH modulus is a DH modulus, so the client accepts the weak/export modulus from the server just fine,
  • Attacker uses his pre-computations on that value p to break the DH in real-time and fix the Finished messages.

The Logjam article authors call this a "protocol flaw" because the ServerKeyExchange message that contains the export DH parameters is not tagged as "for export", and thus is indistinguishable(save for the modulus length) from a ServerKeyExchange message that contains non-export DH parameters. However, I would say that the real flaw is not there; the real problem is that the client and server accept to use a 512-bit DH modulus even though they both know that it is weak.

What should you do ?

Well, the same thing as always: install patches from your software vendors. As a matter of fact, this should go without saying.

On the client side, Microsoft has already patched Internet Explorer to refuse to use a too small modulus. A fix for Firefox in the form of a plugin by Mozilla is available here now. It is expected that other browser vendors(Opera, Chrome...) will soon follow.

On the server side, you can explicitly disable support for "export" cipher suites, and generate your own DH parameters. See that page for details. Note that IIS is kind of immune to all of this because apparently it never supported DHE cipher suites with anything else than a DSS server certificate, and nobody uses DSS server certificates.

Note that ECDHE cipher suites, in which "EC" meaning "elliptic curve", are not at risk here, because:

  • There are no "export" ECDHE cipher suites (ECDHE cipher suites were defined after the US export regulations were considerably lifted).
  • Clients in general support only a few specific curves (usually only two of them, P-256 and P-384) and neither is weak enough to be broken (not now, not in the foreseeable future either).

And what about the NSA ?

The Logjam researchers include some talk about how some "attackers with nation-state resources" could break through 1024-bit DH. This is quite a stretch. In my experience, nation-states indeed have a lot of resources and are good at spending it, but that's not the same thing as succeeding at breaking hard crypto.

Nevertheless, if you fear that 1024-bit DH is "too weak",go for 2048-bit(this is the recommended one anyway), or ECDHE.

Or simply accept that people with overwhelming resources really have overwhelming resources and won't be defeated by a simple modulus size. Those who can spend billions of dollars for cracking machines can also bribe your kids with a few hundreds of dollars to go through your computer files and your wallet.


Logjam shouldn't really be called a "new" vulnerability - it's a rehash of FREAK which targets export-grade DH rather than export-grade RSA.

Practical exploitation relies on the following flaws:

  • The TLS protocol is vulnerable to having its key exchange protocol downgraded by an attacker.
  • Servers are still supporting export-grade Diffie-Hellman (e.g. 512-bit keys)
  • For performance reasons, many implementations hard-code a common prime. This nuance can be abused in order to precompute part of an attack ahead of time for any server which uses that prime.

The attack essentially allows an attacker to precompute a set of data for a target prime known to be in use by a TLS service in its DH implementation. For 512-bit DH this is known to take about a week. Once this has been done, the attacker can break the DH key exchanges with that service in about 1-2 minutes per exchange. Once the exchange is broken, the attacker gains access to the session keys, allowing them to decrypt all traffic.

This issue can be fixed in the following ways:

  • Disable export-grade ciphers.
  • Use elliptic curve DH (ECDHE) rather than finite field DH. This makes the attack much harder in practice due to the lesser advantage of precomputation.
  • Generate a unique DH group for a large prime size such as 2048-bit, and use that instead of a default widely-shared group.

As a side note, one of the interesting factors in this bug is that it matches the NSA's reported capabilities in the field of TLS and IKE (VPN) traffic decryption. In the case of mass traffic capture and decryption, the precomputation attack becomes particularly efficient and effective, due to the vast quantity of data available which is likely to be associated with a known shared prime.

More details available:

  • Full paper
  • Logjam PFS Deployment Guide

Logjam is a cipher downgrade attack where a man in the middle can trick the end points into using a weak cipher. A weak cipher would allow the man in the middle to easily decrypt intercepted traffic.

As with all other cipher downgrade attacks the best way to prevent it is to disable weak ciphers in the first place. If weak ciphers are not available even a successful cipher downgrade will result in strong encryption.

Tags:

Diffie Hellman

Tls

Recent Posts