Skip to content

LOGJAM Common Prime Vulnerability

LOGJAM Common Prime Vulnerability

Description

This vulnerability indicates that the server uses widely-shared Diffie-Hellman prime numbers that enable efficient precomputed attacks, allowing nation-state adversaries to passively decrypt large amounts of internet traffic.

LOGJAM-common_primes occurs when servers use the same standard DH parameters (prime numbers) that are shared across millions of installations. While using shared primes was considered safe, the number field sieve algorithm allows attackers to precompute expensive cryptographic tables once per prime, then quickly break any connection using that prime.

How It Works:

  1. Attacker identifies widely-used DH primes (e.g., default Apache/OpenSSL parameters)
  2. Performs expensive precomputation (weeks of compute time) for target prime
  3. Passively captures DH key exchanges from any server using that prime
  4. Uses precomputed tables to break individual connections in minutes
  5. Scales attack across millions of servers sharing the same prime

Requirements:

  • Server uses common/default DH prime numbers (1024-bit or smaller)
  • Significant computational resources for initial precomputation (~$100M for 1024-bit)
  • Ability to capture network traffic from target connections
  • No man-in-the-middle capability needed - purely passive attack

Example Scenario: A major cloud provider uses default 1024-bit DH parameters across thousands of servers. A nation-state actor spends months precomputing cryptographic tables for this specific prime. Once complete, they can passively monitor internet traffic and decrypt any TLS connection to these servers in real-time, affecting millions of users without any active interference or detection.

Breaking the single most common 1024-bit prime would allow passive eavesdropping on 18% of top HTTPS domains, while breaking the two most common primes would compromise 66% of VPN servers and 26% of SSH servers globally.

Recommendation

To mitigate LOGJAM common prime attacks:

Primary Defense - Generate Unique DH Parameters:

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

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

# Nginx: specify unique parameters  
ssl_dhparam /path/to/unique-dhparams.pem;

Avoid Default/Common Primes:

Never use these widely-compromised primes: - Default Apache 512-bit prime (used by millions of servers) - Default OpenSSL 512-bit prime (in SSLeay since 1995) - RFC 5114 standard primes (potentially NSA-influenced)

Migrate to ECDHE:

Best solution - eliminate DH vulnerability entirely: 

# Apache: prioritize ECDHE over DHE
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE

# Nginx: use only ECDHE ciphers
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!DHE;

Use Minimum 2048-bit Parameters:

If DHE is required: 

# Ensure minimum key size
ssl_dhparam_size 2048;  # Nginx

Testing for Common Primes:

# Extract DH parameters from server
openssl s_client -connect example.com:443 -cipher DHE 2>&1 | \
  openssl dhparam -inform PEM -text -noout

# Compare against known vulnerable primes
# Check if prime matches Apache default or other common values

Additional Protections:

  • Use TLS 1.3 which eliminates finite-field DH entirely
  • Implement certificate pinning to detect MITM attempts
  • Monitor for unusual connection patterns indicating bulk traffic analysis
  • Consider Perfect Forward Secrecy implications when choosing cipher suites

Critical Insight: Even strong 1024-bit DH parameters become vulnerable when shared across many servers, as the precomputation cost can be amortized. Uniqueness matters as much as size.

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