Encryption finding · Edge

Weak Diffie-Hellman Parameters (Logjam): Fix It or Document It

Your scanner flagged weak Diffie-Hellman or Logjam. What it means, how to move to 2048-bit or elliptic-curve exchange, and how to document what can't change.

What the scanner said

SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam)Weak Diffie-Hellman parametersLogjam

Your server offers Diffie-Hellman key exchange with a group of 1024 bits or fewer. Nessus reports this as SSL/TLS Diffie-Hellman Modulus <= 1024 Bits (Logjam). The Logjam research (CVE-2015-4000) showed an attacker in the network path downgrading connections to 512-bit export-grade groups and breaking them, and estimated that a well-resourced attacker could precompute against a widely shared 1024-bit group and then recover session keys negotiated with it.

Why it matters

The precomputation is done once per group, so it is reused against every server that shares that group. NVD scores CVE-2015-4000 at 4.3 (CVSS v2) and 3.7 (v3). Scanners flag groups of 1024 bits or fewer, and NIST SP 800-131A Rev. 2 and PCI DSS strong cryptography expect at least 2048. A NIST 800-53 assessment, a NERC CIP audit, or a customer security review will ask about it.

A PCI ASV scan also fails on it, because an ASV fails any score of 4.0 or higher.

The fix

There are two routes, and the first is usually simpler. Drop the DHE and export suites and rely on elliptic-curve key exchange (ECDHE). If you must keep DHE for older clients, use a 2048-bit group.

Route 1: ECDHE only.

# nginx
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

# Apache (mod_ssl)
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

# Other OpenSSL-based services: exclude DHE and export suites, then restart
CipherString = DEFAULT:!DHE:!EXPORT

Route 2: keep DHE with a 2048-bit group. Use the predefined ffdhe2048 group from RFC 7919, which Mozilla publishes as a ready-made file. FIPS-mode systems accept only approved named groups and can reject a group you generate yourself.

# fetch the RFC 7919 ffdhe2048 group
curl -o /etc/ssl/dhparam.pem https://ssl-config.mozilla.org/ffdhe2048.txt

# nginx (1.11.0 and later turn DHE off when ssl_dhparam is unset; older versions fall back to 1024 bits)
ssl_dhparam /etc/ssl/dhparam.pem;

# Apache 2.4.8 or later with OpenSSL 1.0.2 or later
SSLOpenSSLConfCmd DHParameters /etc/ssl/dhparam.pem

# Java servers
-Djdk.tls.ephemeralDHKeySize=2048

Windows Server (IIS, RDP, SQL Server). Server 2016 and later default to a 2048-bit server minimum. Server 2012 R2 defaults to 1024 and needs the update from Microsoft security advisory 3174644 before these settings apply. Reboot afterwards. If the scanner still flags the host, remove the TLS_DHE suites from the SSL Cipher Suite Order group policy.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman" /v ServerMinKeyBitLength /t REG_DWORD /d 0x800 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman" /v ClientMinKeyBitLength /t REG_DWORD /d 0x800 /f

On a managed load balancer or CDN, choose a security policy that offers ECDHE suites and no DHE suites. The same weak groups also turn up outside TLS, as IKE group 2 on VPN gateways and diffie-hellman-group1-sha1 in SSH, so check those listeners too.

Verify. Run the check below against each listener.

nmap -sT -Pn --script ssl-dh-params -p 443 <host>

A vulnerable host prints VULNERABLE with a Modulus Length of 1024 or 512 bits. A fixed host prints no result from this script. Rerun your scanner too, and keep the before and after output as the evidence that the finding is closed.

When you can't fix it

Some systems cannot take a larger group: appliances with a fixed 1024-bit value, and legacy servers on old Java. Your named owner chooses one treatment.

Remediate by upgrading the software or replacing the appliance, with a dated plan.
Mitigate by terminating TLS in front of the asset with a proxy that negotiates ECDHE with clients. Keep the asset off the internet, restrict it to an allowlist of client addresses, and monitor it.
Accept with documented compensating controls: the asset, why it can't change, the controls above, the owner, a review date, and a replacement date. For a PCI ASV scan, give the ASV that record through its dispute process. The ASV reviews the evidence and decides.

The post Compensating Controls for Legacy Systems covers which controls carry weight and how to write the record an assessor accepts.

Where it lands in the Risk Register

Finding	Treatment	Owner	Evidence
Diffie-Hellman group under 2048 bits on a named listener	Remediate, mitigate, or accept (the owner decides)	Named by you	Before and after scan output. Maps to PCI DSS 4.2.1 and NIST 800-53 SC-8, SC-12, and SC-13.

Common questions

Is a 2048-bit group enough?

Yes, for now. NIST treats 2048-bit finite-field Diffie-Hellman as about 112 bits of security, and its draft transition plan (NIST IR 8547) deprecates 112-bit strength after 2030 and quantum-vulnerable key exchange after 2035. Moving to elliptic-curve key exchange (ECDHE) closes this finding today, and the post-quantum migration is the next step after that.

Does Logjam affect elliptic-curve key exchange?

No. Logjam concerns finite-field Diffie-Hellman groups. Suites that start with ECDHE are not affected, which is why dropping DHE suites is often the simplest fix.

Will a larger group break older clients?

It can. Java 7 and earlier cap Diffie-Hellman at 1024 bits and fail the handshake with a larger group. If you have such clients, keep ECDHE suites available so they can negotiate those instead.

Can I pass a PCI scan with a 1024-bit group still offered?

Only through the ASV's dispute process, with a compensating-control record. The finding scores 4.3 under CVSS v2, above the ASV failure threshold of 4.0, so moving to 2048 bits or ECDHE is the reliable route.