The Logjam attack isn’t about finding a specific vulnerability in a single server, but rather a widespread weakness in how many servers negotiate cryptographic keys, specifically using a weak version of the Diffie-Hellman key exchange.
Let’s see this in action. Imagine two parties, Alice and Bob, want to establish a secure communication channel. They agree to use Diffie-Hellman for this. The core idea is that they can both independently generate secret numbers, combine them with a public "generator" and a public "prime modulus," and exchange the results. By combining their received public value with their own secret, they can both arrive at the same shared secret key without ever sending that secret key over the network.
Here’s a simplified look at the math:
- Publicly agreed upon: A large prime number
pand a generatorg. - Alice’s secret: A private number
a. She calculatesA = g^a mod pand sendsAto Bob. - Bob’s secret: A private number
b. He calculatesB = g^b mod pand sendsBto Alice. - Alice’s shared secret: She receives
Band calculatesS = B^a mod p. - Bob’s shared secret: He receives
Aand calculatesS = A^b mod p.
Crucially, B^a mod p = (g^b)^a mod p = g^(ba) mod p and A^b mod p = (g^a)^b mod p = g^(ab) mod p. They end up with the same S.
The problem Logjam exploits is that many servers and clients, for historical reasons or ease of implementation, still support a very weak Diffie-Hellman group. This group is defined by a specific prime modulus p and generator g. The weakness lies in the size of p. If p is too small, or if it’s a "safe prime" with a specific structure (like a Sophie Germain prime), then an attacker can perform a precomputation attack.
This is the mental model: Diffie-Hellman, in its basic form, relies on the difficulty of the discrete logarithm problem. If you know g, p, and A = g^a mod p, it’s computationally hard to find a. However, if p is small, or has a specific structure, this problem becomes much easier. Logjam targets this by focusing on a specific, widely used group (the one with prime p = 7919 and generator g = 7 is an example, but the most concerning is the 512-bit prime commonly used).
An attacker can precompute a large table of possible values for g^x mod p for a specific weak group. If they intercept a Diffie-Hellman exchange using that weak group, they can look up the public values exchanged by Alice and Bob in their precomputed table. Once they find a match, they can deduce the secret exponents (a and b) and thus derive the shared secret key S.
Even worse, many servers support multiple Diffie-Hellman groups and negotiate with the client which one to use. If a server supports both a strong, modern group (e.g., 2048-bit or larger) and a weak, 512-bit group, and the client also supports both, the server might offer the weak one first. If the client accepts, the attacker can then force the connection to use the weak group, break it, and eavesdrop. This is the "jam" in Logjam – the attacker can force a downgrade to a weak cipher.
The fix is multi-pronged. First, servers must be configured to disable support for weak Diffie-Hellman groups. This means explicitly telling your web server (e.g., Apache, Nginx) or other TLS-enabled software not to use any 512-bit DH parameters. Instead, you should generate and use strong, modern DH parameters. For example, on an Apache server, you’d ensure your ssl.conf or httpd.conf doesn’t have configurations that allow or prioritize weak DH.
To generate strong DH parameters, you’d typically use a command like:
openssl dhparam -out dhparam.pem 2048
(or 4096 for even stronger, though it increases handshake overhead).
Then, you configure your server to use this dhparam.pem file. For Nginx, this might look like:
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
And for Apache:
SSLDHParametersFile /etc/ssl/certs/dhparam.pem
The mechanical reason this works is that by disabling the weak 512-bit groups, you remove the possibility of a downgrade attack. The server and client are then forced to use the stronger, larger prime moduli that are computationally infeasible to break with current technology and precomputation attacks. It’s like removing the faulty lock from the door, forcing you to use the secure one.
The next common issue you’ll encounter after fixing Logjam is that some very old clients (or misconfigured ones) might not support the stronger DH parameters you’ve just enabled, leading to connection failures.