How to remediate – SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam)

1. Introduction

The SSL/TLS Diffie-Hellman Modulus <= 1024 Bits vulnerability, also known as Logjam, affects systems using older versions of SSL/TLS that support weak Diffie-Hellman key exchange. This allows a third party to potentially decrypt connections or violate their integrity. Servers and applications offering TLS are usually affected. A successful attack could compromise the confidentiality, integrity, and availability of data transmitted over these connections.

2. Technical Explanation

The Logjam vulnerability occurs when servers accept Diffie-Hellman key exchange with a modulus size of 1024 bits or less. These smaller moduli are susceptible to cryptanalysis, allowing an attacker to calculate the shared secret used for encryption. This requires the attacker to be able to intercept TLS handshakes and perform significant computational work. CVE-2015-4000 describes this issue.

• Root cause: The server allows use of Diffie-Hellman key exchange with a modulus size of 1024 bits or less, which is considered cryptographically weak.
• Exploit mechanism: An attacker intercepts the TLS handshake and uses precomputed tables to find the shared secret. This enables decryption of the session traffic.
• Scope: Servers using OpenSSL versions prior to 1.0.1p are affected if configured to support Diffie-Hellman key exchange with weak moduli. Other TLS implementations may also be vulnerable.

3. Detection and Assessment

You can check for this vulnerability by examining your server’s TLS configuration. A quick check involves using a command line tool to see the supported cipher suites. More thorough assessment requires analysing the full TLS handshake.

• Quick checks: Use openssl s_client -connect example.com:443 and look for cipher suites that use Diffie-Hellman with a modulus size of 1024 bits or less in the output.
• Scanning: Nessus plugin ID 87659 can identify this vulnerability. Other scanners may have similar checks, but results should be verified.
• Logs and evidence: Examine TLS handshake logs for cipher suites using Diffie-Hellman key exchange. Look for specific DH groups supported by the server.

openssl s_client -connect example.com:443 | openssl x509 -cipherlist 

4. Solution / Remediation Steps

To fix this vulnerability, reconfigure your service to use a unique Diffie-Hellman moduli of 2048 bits or greater. This strengthens the key exchange process and makes cryptanalysis significantly more difficult.

4.1 Preparation

• Changes may require a scheduled maintenance window depending on service criticality and impact. Approval from relevant IT teams might be needed.

4.2 Implementation

1. Step 1: Edit your server’s TLS configuration file (e.g., Apache httpd.conf, Nginx nginx.conf).
2. Step 2: Remove or disable any cipher suites that use Diffie-Hellman key exchange with a modulus size of 1024 bits or less.
3. Step 3: Configure the server to prefer stronger key exchange algorithms like Elliptic Curve Diffie-Hellman (ECDHE) and DHE with moduli of 2048 bits or greater.
4. Step 4: Restart the affected service for the changes to take effect.

4.3 Config or Code Example

Before

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ALL

After

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact if exploited, while secure defaults ensure stronger configurations are used by default.

• Practice 1: Use least privilege principles to limit access to sensitive configuration files and keys.
• Practice 2: Implement a regular patch cadence for your TLS libraries and server software.

4.5 Automation (Optional)

# Example Ansible task to update SSLCipherSuite in Apache config
- name: Update SSLCipherSuite
  lineinfile:
    path: /etc/apache2/mods-enabled/ssl.conf
    regexp: '^SSLCipherSuite'
    line: 'SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Run openssl s_client -connect example.com:443 | openssl x509 -cipherlist and confirm that cipher suites using DH with <=1024 bits are not listed.
• Re-test: Re-run the earlier detection method to show the vulnerability is resolved.
• Smoke test: Verify that users can still connect to your website or service over HTTPS.
• Monitoring: Monitor TLS handshake logs for any unexpected cipher suites or key exchange algorithms.

openssl s_client -connect example.com:443 | openssl x509 -cipherlist 

6. Preventive Measures and Monitoring

Update security baselines to enforce stronger TLS configurations, for example using CIS controls. Add checks in your CI/CD pipeline to prevent weak cipher suites from being deployed.

• Baselines: Update your security baseline or policy to require the use of 2048-bit or greater Diffie-Hellman moduli and prefer ECDHE key exchange.
• Pipelines: Add static analysis checks in your CI/CD pipeline to identify any TLS configurations that use weak cipher suites.
• Asset and patch process: Implement a regular review cycle for server configurations and security patches.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Older clients may not support stronger key exchange algorithms, leading to connection errors.
• Risk or side effect 2: Incorrectly configured TLS settings can cause service outages.
• Roll back: Restore the original TLS configuration file and restart the affected service.

8. References and Resources

• Vendor advisory or bulletin: https://weakdh.org