Articles

Logjam and DROWN Attacks: Fix Weak DH and SSL2 Exposure (2026)

April 6, 2026 6 min read

This is a critical vulnerability where weak Diffie-Hellman parameters or SSLv2 support on your servers allows attackers to decrypt past and present TLS traffic, exposing sensitive data.

Common Causes and Fixes for Weak DH and SSLv2 Exposure

1. Weak Diffie-Hellman Group Parameters

  • Diagnosis: Run openssl s_client -connect yourserver.com:443 -cipher DHE-RSA-AES256-SHA and look for Server public key is followed by a key size. If it’s 1024 bits or less, it’s vulnerable. Alternatively, use a tool like SSL Labs’ Server Test (ssllabs.com/ssltest/) which will explicitly report weak DH key exchange.
  • Cause: Older TLS configurations or manual overrides often default to weaker, faster, but less secure DH groups, making them susceptible to pre-computation attacks.
  • Fix: You need to regenerate your DH parameters with a stronger group size. For Apache, add or modify SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam-2048.pem" in your virtual host configuration and then restart Apache. For Nginx, add ssl_dhparam /etc/nginx/ssl/dhparam-2048.pem; to your server block and restart Nginx.
    • Regenerating DH Parameters (example for 2048-bit):
      openssl dhparam -out /etc/ssl/certs/dhparam-2048.pem 2048
      (Or /etc/nginx/ssl/dhparam-2048.pem for Nginx).
  • Why it works: This command generates a new, cryptographically stronger set of prime numbers for the Diffie-Hellman key exchange. A 2048-bit or 4096-bit group is computationally infeasible for attackers to break in a reasonable timeframe, preventing them from deriving the session key.

2. SSLv2 Enabled

  • Diagnosis: Use openssl s_client -connect yourserver.com:443 -ssl2 (note the -ssl2 flag). If the connection succeeds and you get a certificate, SSLv2 is enabled and vulnerable.
  • Cause: Many server software versions, especially older ones, have SSLv2 enabled by default or through configuration for backward compatibility, even though it’s long deprecated and insecure.
  • Fix (Apache): In your ssl.conf or virtual host configuration, ensure SSLProtocol -all +TLSv1.2 +TLSv1.3 is set. This explicitly disables all protocols except TLS 1.2 and TLS 1.3. Restart Apache.
  • Fix (Nginx): In your nginx.conf or server block, set ssl_protocols TLSv1.2 TLSv1.3;. Restart Nginx.
  • Why it works: SSLv2 has fundamental cryptographic flaws, including a weak master secret calculation and a lack of integrity protection. Disabling it entirely forces clients to use the much more secure TLS 1.2 or TLS 1.3 protocols.

3. Outdated OpenSSL Library

  • Diagnosis: Check your OpenSSL version with openssl version. Versions prior to 1.0.2 (for TLS 1.3 support) or versions with known CVEs related to DH or SSLv2 are problematic.
  • Cause: The operating system’s package manager might not have updated OpenSSL to the latest secure version, or the application might be statically linked against an older version.
  • Fix: Update your OpenSSL library via your system’s package manager. For Debian/Ubuntu: sudo apt update && sudo apt upgrade openssl libssl-dev. For RHEL/CentOS/Fedora: sudo yum update openssl openssl-devel. After updating, restart any services that use OpenSSL (web servers, etc.).
  • Why it works: Newer OpenSSL versions include fixes for known vulnerabilities and support for stronger cryptographic algorithms and protocols, ensuring the underlying TLS implementation is robust.

4. Weak Cipher Suites for DHE

  • Diagnosis: Use openssl s_client -connect yourserver.com:443 -cipher DHE-RSA-DES-CBC3-SHA and observe the output. If it connects, you’re offering weak DHE cipher suites. SSL Labs also lists specific weak cipher suites.
  • Cause: Servers often include a broad range of cipher suites for compatibility, inadvertently including older, weaker ones that can be associated with DHE.
  • Fix (Apache): In your ssl.conf or virtual host, set SSLCipherSuite HIGH:!aNULL:!MD5:!RC4:!DHE-RSA-DES-CBC3-SHA:!DSS-DES-CBC3-SHA:!ECDHE-RSA-DES-CBC3-SHA:!ECDHE-ECDSA-DES-CBC3-SHA:!DHE-RSA-AES256-SHA256:!DHE-DSS-AES256-SHA256:!ECDHE-RSA-AES256-SHA384:!ECDHE-ECDSA-AES256-SHA384. This prioritizes strong ciphers and explicitly excludes known weak ones. Restart Apache.
  • Fix (Nginx): In your nginx.conf or server block, set ssl_ciphers HIGH:!aNULL:!MD5:!RC4:!DHE-RSA-DES-CBC3-SHA:!DSS-DES-CBC3-SHA:!ECDHE-RSA-DES-CBC3-SHA:!ECDHE-ECDSA-DES-CBC3-SHA:!DHE-RSA-AES256-SHA256:!DHE-DSS-AES256-SHA256:!ECDHE-RSA-AES256-SHA384:!ECDHE-ECDSA-AES256-SHA384;. Restart Nginx.
  • Why it works: By explicitly listing and prioritizing strong cipher suites and excluding known weak ones (like those using DES or older SHA-1 hashes), you ensure that even when DHE is negotiated, it’s done with robust encryption and hashing algorithms.

5. Insecure TLS Renegotiation

  • Diagnosis: This is harder to diagnose directly without specialized tools. However, if you’ve followed best practices for disabling SSLv2 and updating OpenSSL, it’s less likely to be the primary issue. The vulnerability here is that an attacker could inject commands into a secure session.
  • Cause: TLS renegotiation, when not properly secured, allows a client to initiate a renegotiation of the session parameters. An attacker could exploit this to inject malicious content into an otherwise legitimate TLS session.
  • Fix (Apache): Add SSLInsecureRenegotiation off to your ssl.conf or virtual host. Restart Apache.
  • Fix (Nginx): This is handled by OpenSSL versions. Ensure you are on a recent OpenSSL (>= 1.0.1) and that it’s compiled with no-ssl3 and no-ssl2. Nginx itself doesn’t have a direct config for this, relying on the library.
  • Why it works: Disabling insecure renegotiation prevents unauthenticated clients from initiating a renegotiation, thereby closing the attack vector where malicious data could be injected into an established secure channel.

6. Weaknesses in older TLS versions (TLSv1.0, TLSv1.1)

  • Diagnosis: Use SSL Labs or openssl s_client -connect yourserver.com:443 -tls1 or openssl s_client -connect yourserver.com:443 -tls1_1. If these connect successfully, you are still offering these older, vulnerable protocols.
  • Cause: For maximum compatibility, especially with very old clients, servers may be configured to support TLSv1.0 and TLSv1.1. Both have known cryptographic weaknesses (e.g., POODLE for SSLv3, BEAST for TLSv1.0, and general structural weaknesses).
  • Fix (Apache): Ensure SSLProtocol -all +TLSv1.2 +TLSv1.3 is configured as mentioned in the SSLv2 fix.
  • Fix (Nginx): Ensure ssl_protocols TLSv1.2 TLSv1.3; is configured as mentioned in the SSLv2 fix.
  • Why it works: TLS 1.2 and TLS 1.3 are significantly more secure, featuring improved cipher suite negotiation, stronger cryptographic primitives, and better resistance to known attacks. Disabling older versions forces clients to use these modern, secure protocols.

After ensuring all these configurations are hardened, you might encounter a new, but less severe, error related to HTTP/2 stream resets if your HTTP/2 implementation is also not fully up-to-date, or perhaps a client complaining about the lack of support for a very old cipher suite that was previously offered.

More Deep Dives in Tls Ssl

Want structured learning?

Take the full Tls-ssl course →