Skip to content

LOGJAM Attack on Diffie-Hellman

LOGJAM Attack on Diffie-Hellman

Description

This vulnerability indicates that the server is susceptible to LOGJAM attacks, which exploit weak Diffie-Hellman parameters to downgrade TLS connections to breakable export-grade cryptography.

LOGJAM occurs when TLS servers support DHE_EXPORT cipher suites or use weak 512-bit Diffie-Hellman parameters. Man-in-the-middle attackers can force clients to downgrade from strong DHE key exchange to weak export-grade DH, making the encryption vulnerable to offline cryptanalysis.

How It Works:

  1. Attacker intercepts TLS handshake between client and server
  2. Forces downgrade from strong DHE ciphers to weak DHE_EXPORT (512-bit)
  3. Captures the downgraded connection with weak DH parameters
  4. Uses precomputed discrete logarithm tables to break 512-bit DH offline
  5. Recovers session keys and decrypts all captured traffic

Requirements:

  • Server supports DHE_EXPORT cipher suites or weak DH parameters
  • Man-in-the-middle network position to force downgrade
  • Precomputed number field sieve tables for common DH primes
  • Client vulnerable to protocol downgrade attacks

Example Scenario: A corporate VPN server supports legacy DHE_EXPORT ciphers for compatibility. An attacker on the network intercepts employee connections and forces downgrade to 512-bit DH parameters. Using precomputed cryptographic tables (costing ~$18,000 to generate), the attacker breaks the weak DH exchange in hours and decrypts all VPN traffic, exposing corporate credentials and sensitive data.

The attack exploits the same 1990s export restrictions as FREAK, demonstrating how government-mandated crypto weakening created lasting vulnerabilities in the Diffie-Hellman key exchange protocol used by millions of servers worldwide.

Recommendation

To mitigate LOGJAM attacks:

Primary Defense - Disable Export DH Ciphers:

# Apache - disable export DH ciphers
SSLCipherSuite HIGH:!aNULL:!MD5:!EXP:!DHE

# Better: use ECDHE instead of DHE
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE

# Nginx - disable weak DH ciphers
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE:!EXPORT:!DES:!RC4:!MD5;

Use Strong DH Parameters:

If DHE is required, generate custom 2048-bit+ parameters: 

# Generate strong DH parameters
openssl dhparam -out dhparams.pem 2048

# Apache: use custom DH parameters
SSLOpenSSLConfCmd DHParameters /path/to/dhparams.pem

# Nginx: specify custom DH parameters
ssl_dhparam /path/to/dhparams.pem;

Prefer ECDHE Over DHE:

ECDHE provides better performance and security: 

# Prioritize ECDHE cipher suites
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305

Client-Side Protection:

// Java - disable weak DH
System.setProperty("jdk.tls.disabledAlgorithms", "DH keySize < 1024");

Testing for LOGJAM:

# Test for DHE_EXPORT support
nmap --script ssl-enum-ciphers -p 443 example.com | grep DHE_EXPORT

# Should show no DHE_EXPORT ciphers available
openssl s_client -connect example.com:443 -cipher DHE-EXPORT

Additional Mitigations:

  • Use TLS 1.3 which removes support for weak DH parameters
  • Implement perfect forward secrecy with ECDHE key exchange
  • Monitor for unusual cipher negotiation patterns
  • Regularly audit TLS configurations for weak parameters

The fundamental fix is moving away from DHE to ECDHE, which provides equivalent security with better performance and no export-grade vulnerabilities.

Standards

  • SOC2_CONTROLS:
    • CC_6_7
    • CC_7_1
  • CCPA:
    • CCPA_1798_150
  • GDPR:
    • ART_32
  • PCI_STANDARDS:
    • REQ_4_1
    • REQ_6_2
    • REQ_11_3