LogJam (CVE-2015-4000)
Imagine a combination lock with only three digits. It does its job in the sense that there is a locking mechanism. It clicks shut. The dial turns. From a distance, it's a lock. Up close, a determined thief can simply try all 1,000 combinations in a few minutes. The lock isn't broken. It's just small enough that brute force is practical.
That's roughly the situation with weak Diffie-Hellman groups in TLS, and the attack that exploited them is called LogJam.
Quick summary
- What: An attack against TLS that allowed a man-in-the-middle attacker to downgrade connections to weak (512-bit) Diffie-Hellman key exchange, then break the resulting encryption. CVE: CVE-2015-4000 Disclosed: May 2015 Discovered by: A team of researchers including J. Alex Halderman, Nadia Heninger, and others. Affected: Any TLS server that supported "export-grade" Diffie-Hellman cipher suites, and any client willing to negotiate them. Severity at the time: Significant. Researchers estimated that a state-level attacker could break 1024-bit DH groups too, with offline precomputation. Status in 2026: Mostly patched, but old systems and old configurations still occasionally found.
What it is in plain English
LogJam attacks a piece of TLS where the client and server agree on a shared secret using Diffie-Hellman key exchange. The security of DH depends on the size of the "prime number" (the DH group) being used. Bigger primes = harder math = stronger security.
In the 1990s, US export controls limited cryptography in software sold abroad. The result was "export-grade" cipher suites with deliberately-weak DH groups - only 512 bits long. Export controls were relaxed in 2000. The weak cipher suites should have died then. They didn't. Many servers kept supporting them for backwards compatibility, even though essentially no legitimate client needed them by 2015.
The LogJam researchers discovered two things.
One: Many servers still accepted weak (512-bit) DH groups when a client requested them. A 512-bit DH group can be broken in minutes with modest computing resources.
Two: A man-in-the-middle attacker could trick a server and client into negotiating these weak ciphers even when both could have used stronger ones. The client said "let's use a strong cipher." The attacker, intercepting, said "no, use the weak one." Both sides accepted the downgrade.
The combination meant an attacker on the network could force a downgrade, then break the resulting encryption. The TLS handshake looked normal to both parties; the connection was no longer actually secure.
The researchers also noted a more concerning theoretical attack: 1024-bit DH groups are widely used and are not export-grade, but for a small number of widely-reused groups, a state-level attacker with enough resources could pre-compute the math needed to break any session using those groups. This wasn't yet practical for everyone, but it was practical for nation-states with significant compute budgets.
How the attack worked
A practical LogJam attack:
- Attacker positions themselves as a man-in-the-middle on the network between the victim and the target server. Victim's browser connects to the target server over TLS. The browser proposes a list of cipher suites, including strong ones. The attacker modifies the ClientHello on the way to the server, removing the strong options and leaving only the export-grade ones. The server, supporting export-grade ciphers, agrees to use one. The TLS handshake completes with a 512-bit DH group. The attacker, observing the handshake, computes the shared secret in roughly real-time (or near-real-time with precomputation). The attacker can now decrypt the entire session.
The attack required a network position the attacker could often obtain (open Wi-Fi, on-path ISP, state-level access). It required no software vulnerabilities. The "attack" was using cipher choices that the server willingly negotiated.
What the impact was
LogJam reshaped how the industry thinks about cipher choice.
The export-grade purge. Within months of LogJam, browser vendors and server administrators removed support for export-grade DH cipher suites. Mozilla, Chrome, and Apple all stopped accepting weak DH groups by default. The "we keep them for compatibility" defence collapsed when researchers showed how few real clients needed them.
The 1024-bit DH conversation. The theoretical attack on 1024-bit DH groups prompted a broader conversation about DH group sizes. The cryptography community started recommending 2048-bit minimum, and 1024-bit DH gradually phased out of recommended configurations.
The downgrade-attack pattern. LogJam was a clear example of a downgrade attack - an attacker forcing weaker security than both sides could have negotiated. This influenced the design of TLS 1.3, which has explicit anti-downgrade mechanisms baked into the protocol.
The Diffie-Hellman migration. Many sites moved from DHE (Diffie-Hellman Ephemeral) cipher suites to ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) cipher suites, which use different math less susceptible to precomputation attacks. ECDHE is now the dominant key exchange method for new TLS connections.
How to know if you're vulnerable today
In 2026, LogJam-vulnerable systems are uncommon but not unheard of. Look for it in:
- Servers still permitting export-grade cipher suites. Any configuration including
EXPORTciphers should be fixed immediately. Servers using 1024-bit DH groups for DHE cipher suites. Recommendation is 2048-bit minimum. Old appliances and IoT devices with unmaintained cipher configurations. Internal-facing tools with default cipher lists from 2014 or earlier.
Detection tools:
- Online: Qualys SSL Labs flags weak DH groups and export-grade suite support. Command-line:
testssl.shandsslyzeboth surface DH group sizes and export-grade ciphers. Continuous: modern TLS scanners (including TLS Radar) include LogJam-relevant checks.
How to fix and mitigate
Two cleanup actions.
Disable export-grade cipher suites entirely. No legitimate use case in 2026. Remove from server configurations.
Use 2048-bit DH groups minimum, or move to ECDHE. Most modern servers default to ECDHE, which avoids the DH group sizing question entirely. If you still use DHE, generate new 2048-bit (or larger) DH parameters rather than relying on shipped defaults.
The Mozilla SSL Configuration Generator's "Modern" and "Intermediate" profiles handle this correctly by default.
Why it still matters in 2026
LogJam is eleven years old. Why include it?
Three reasons.
The export-grade tail. Old appliances, IoT, and internal tools occasionally still permit export-grade suites. They're easy to fix once found; finding them is the harder part.
The 1024-bit DH conversation continues. Even where export-grade is gone, some servers still use 1024-bit DHE. The theoretical concerns from 2015 have only become more practical as compute resources increase.
The downgrade-attack lesson. LogJam established the importance of preventing protocol downgrade. TLS 1.3's built-in protections are a response to LogJam and related attacks. Understanding LogJam helps understand why TLS 1.3 is structured the way it is.
One small ask
LogJam is one of the failure modes that pure expiry monitoring misses. The cert is valid; the cipher list contains export-grade suites; the connection is downgradable. Continuous cipher scanning catches it. TLS Radar's 30-day free trial covers three domains and runs the full cipher suite check every week. Worth an afternoon to confirm nothing in your environment is still negotiating export-grade DH.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.