I heard there is a "new" TLS vulnerability named Logjam, what does it do and how do I prevent it?

  • 26
    The link you've provided is a pretty complete answer to your question, including the "What should I do?" section.
    – gowenfawr
    May 20, 2015 at 15:43
  • 2
    This isn't a "new" vulnerability at all. It's just a bad idea at this point to be so backwards compatible.
    – Mooseman
    May 21, 2015 at 11:42

4 Answers 4



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 US 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" stands for "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.

  • 43
    The last paragraph misses the point and dismisses serious legitimate concerns. Nobody who doesn't have their head covered in tinfoil is worried that the NSA is going to target them specifically with cryptographic attacks rather than using much easier, less-sophisticated attacks. The threat model is dragnet surveillance where your privacy and security are compromised not because you're a target, but because everybody is. May 20, 2015 at 19:39
  • In regards to: "the real problem is that the client and server accept to use a 512-bit DH modulus" ... couldn't the MitM just pad out the short modulus so that the client accepts it as a 'randomly chosen' long modulus that just happens to be a small number? Or are we rejecting moduli with small numerical value rather than small bit length? May 20, 2015 at 21:04
  • 4
    When I talk about modulus size, I really mean the numerical size: modulus p has size k bits if it is greater than 2^(k-1) and lower than 2^k. Of course, any implementation can fail to do things properly. May 20, 2015 at 21:23

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:

  • 6
    In fact, the ability to reuse breaking efforts for other DH instances with the same modulus implies a lot of interesting mathematical work (which was published before this attack); and there is the small point that, contrary to FREAK, that new attack does not require the use an implementation bug. However, the basic concept is the same: when client and server are OK with using very weak crypto, they get what they deserve. May 20, 2015 at 15:54
  • @ThomasPornin I figured there was some crypto wizardry behind the precomputation that I wasn't aware of. Your answer is excellent, by the way. I understand it better than I did before.
    – Polynomial
    May 20, 2015 at 16:09
  • "Generate a unique DH group for a large prime size such as 2048-bit, and use that instead of a default widely-shared group." There's nothing wrong with using a default widely-shared group if it's a secure size, such as 2048 bits. The size is the critical part. Sharing just increases the impact. May 20, 2015 at 21:46

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.


To prevent Logjam you could follow recommendations of the Guide to Deploying Diffie-Hellman for TLS which will help you to configure your server (Apache HTTP Server, nginx, IIS, Lighttpd, Tomcat, Postfix, Sendmail, Dovecot, HAProxy, OpenSSH, Amazon Elastic Beanstalk) :

  • Test if your server is safe
  • Generate a strong and unique Diffie-Hellman group
  • Deploy ECDHE Cipher Suites
  • Disable Export Cipher Suites

Mozilla SSL Configuration Generator is also a good configuration tool.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.