The Logjam Attack – ANOTHER Critical TLS Weakness

Your website & network are Hackable

So it seems SSL/TLS has not been having a good time lately, alongside Heartbleed and POODLE we now have the Logjam attack.

It’s somewhat similar to the FREAK attack earlier this year, but that attacked the RSA key exchange and was due to an implementation vulnerability rather than Logjam which attacks the Diffie-Hellman key exchange as is due to a flaw in the TLS protocol.

The Logjam Attack - ANOTHER Critical TLS Weakness

The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers. 8.4% of the Top 1 Million domains were initially vulnerable.

Source –

The full technical report is here: Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice [PDF]

Who is affected?

Websites, mail servers, and other TLS-dependent services that support DHE_EXPORT ciphers are at risk for the Logjam attack. Websites that use one of a few commonly shared 1024-bit Diffie-Hellman groups may be susceptible to passive eavesdropping from an attacker with nation-state resources.

Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. Practitioners believed this was safe as long as new key exchange messages were generated for every connection. However, the first step in the number field sieve—the most efficient algorithm for breaking a Diffie-Hellman connection—is dependent only on this prime. After this first step, an attacker can quickly break individual connections.

The researchers estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime. Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break.

Are you at risk?

If you update as soon as patches are available on a regular basis, probably not. Microsoft patched it on May 12 with security bulletin MS15-055, Google fixed the issue with the Chrome 42 update, which debuted on April 15 and the Firefox patch is on the way.

If you run servers or are a Sys Admin, there’s full details here on what you can do and a test tool:

Guide to Deploying Diffie-Hellman for TLS

The researchers have 3 recommendations for deploying Diffie-Hellman:

  • Disable Export Cipher Suites. Even though modern browsers no longer support export suites, the FREAK and Logjam attacks allow a man-in-the-middle attacker to trick browsers into using export-grade cryptography, after which the TLS connection can be decrypted. Export ciphers are a remnant of 1990s-era policy that prevented strong cryptographic protocols from being exported from United States. No modern clients rely on export suites and there is little downside in disabling them.
  • Deploy (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE). Elliptic-Curve Diffie-Hellman (ECDH) key exchange avoids all known feasible cryptanalytic attacks, and modern web browsers now prefer ECDHE over the original, finite field, Diffie-Hellman. The discrete log algorithms we used to attack standard Diffie-Hellman groups do not gain as strong of an advantage from precomputation, and individual servers do not need to generate unique elliptic curves.
  • Generate a Strong, Unique Diffie Hellman Group. A few fixed groups are used by millions of servers, which makes them an optimal target for precomputation, and potential eavesdropping. Administrators should generate unique, 2048-bit or stronger Diffie-Hellman groups using “safe” primes for each website or server.

This whole thing does raise some issues with trust, trust in cryptography, in the algorithms, the implementation and the fact that cryptography brings along with it certain promises that should avoid nation state eavesdropping.

I guess we’ll have to wait a little longer to see how dangerous this is in the practical world.

Posted in: Cryptography, Exploits/Vulnerabilities

, , , , , , , , ,

Recent in Cryptography:
- Up1 – Client Side Encrypted Image Host
- PEiD – Detect PE Packers, Cryptors & Compilers
- DROWN Attack on TLS – Everything You Need To Know

Related Posts:

Most Read in Cryptography:
- The World’s Fastest MD5 Cracker – BarsWF - 47,850 views
- Hackers Crack London Tube Oyster Card - 45,322 views
- WPA2 Vulnerability Discovered – “Hole 196” – A Flaw In GTK (Group Temporal Key) - 33,308 views

7 Responses to The Logjam Attack – ANOTHER Critical TLS Weakness

  1. Chris May 25, 2015 at 2:38 pm #

    Once I’ve created a new 2048 bit DH group using OpenSSL, how do I change it when using IIS on the 2012R2 server?

    • Darknet May 26, 2015 at 2:42 pm #

      1. Open the Group Policy Object Editor (i.e. run gpedit.msc in the command prompt).
      2. Expand Computer Configuration, Administrative Templates, Network, and then click SSL Configuration Settings.
      3. Under SSL Configuration Settings, open the SSL Cipher Suite Order setting.
      4. Set up a strong cipher suite order. See this list of Microsoft’s supported ciphers and Mozilla’s TLS configuration instructions.

      • Chris May 27, 2015 at 8:05 am #

        Yeah I’ve followed those instructions and have a cipher set of :
        And SSLLAbs testing still tops out at a B Grade due to
        “This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. ”

        Checking the info from SSLLabs it comes up with
        “Uses common DH prime Yes Replace with custom DH parameters if possible (more info)”
        However none of the information I have found on Google, including the website says anything more than your 4 steps above.

        Thanks for you help.

  2. Patrick May 27, 2015 at 10:59 pm #

    Is there a way to do a feature check via webcode so that a visitor could be informed that they are vulnerable?
    Im thinking about adding this to my website.

    • Darknet May 28, 2015 at 1:08 am #

      They do it on so yah definitely, basically they do it by loading in an iframe, if it can load you are vulnerable. Not sure how reliable a test it is though, as I can load it on all my browsers which are updated with the supposed fixed versions.