SSL/TLS Diffie-Hellman Modulus <= 1024 Bits

Tenable plugin 83875 is flagging a configuration weakness, not a host-takeover bug. Any TLS service on TLS 1.2 or earlier that will negotiate finite-field DHE with a Diffie-Hellman modulus of 1024 bits or less can fall into scope, and the highest-risk case is reuse of common 1024-bit groups or support for legacy DHE_EXPORT paths. There is no neat product-version boundary here: the affected range is essentially whatever service configuration still offers weak DHE.

Tenable calling this LOW is basically right. Logjam sounds dramatic because the research was important, but in enterprise patch triage this is not commodity unauthenticated RCE; it requires an active man-in-the-middle position, depends on the target still offering weak DHE, and usually ends in session decryption/tampering, not system compromise. The severity only climbs if the finding sits on high-value edge systems like legacy VPN, mail, or admin portals where an on-path attacker is plausible.

Why this verdict

• On-path MITM is mandatory: this is not internet spray-and-pray. The attacker already needs network vantage such as rogue Wi-Fi, LAN spoofing, proxy control, or upstream path influence.
• The exposed population is narrower every year: only pre-TLS 1.3 services still offering finite-field DHE at <=1024 bits are in scope, while many modern stacks default to ECDHE or reject weak groups outright.
• Impact is session compromise, not host compromise: even when exploitation works, the usual result is decrypted or modified traffic for intercepted sessions, not unauthenticated RCE, persistence, or lateral movement by itself.

Why not higher?

There is no reviewed-source evidence here of KEV listing or broad current commodity exploitation, and the attack chain has stacked prerequisites: weak server config, compatible client behavior, and an active MITM position. That is too much friction for HIGH, let alone CRITICAL, in a 10,000-host patch queue.

Why not lower?

This is still a real cryptographic weakness, not scanner trivia. If the endpoint is internet-facing and carries credentials, admin traffic, or sensitive mail/API sessions, a capable on-path attacker can turn the weakness into confidentiality and integrity loss, so IGNORE would be too casual.

1. Disable finite-field DHE where you can — Prefer ECDHE and TLS 1.3 on external services so the weak-DH path simply does not exist. For a LOW verdict there is no formal mitigation SLA; do this in your normal crypto-hardening cycle, but prioritize any internet-facing admin, VPN, mail, or identity endpoints first.
2. Regenerate DH parameters at 2048 bits or higher — If a legacy service must keep finite-field DHE, generate unique 2048-bit+ DH params instead of shipping vendor defaults or common groups. Again, there is no noisgate mitigation deadline for LOW; fold it into the next service config maintenance window.
3. Fence legacy weak-DHE services behind managed paths — Put the unavoidable exceptions behind VPN, reverse proxy, NAC, or internal-only access to make the MITM prerequisite much harder to satisfy. For LOW, this is backlog hygiene rather than emergency action, but it is worth doing for high-value administrative systems.

Run this from an auditor workstation or jump box that can reach the target service over the network. Invoke it as ./check_logjam.sh host.example.com 443; no elevated privileges are needed, but you need outbound connectivity to the target and openssl installed.

#!/usr/bin/env bash
# check_logjam.sh
# Purpose: check whether a TLS service negotiates finite-field DHE with a modulus <= 1024 bits.
# Usage: ./check_logjam.sh <host> <port>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE/DEPENDENCY ERROR

set -u

HOST="${1:-}"
PORT="${2:-}"

if [[ -z "$HOST" || -z "$PORT" ]]; then
  echo "Usage: $0 <host> <port>"
  exit 3
fi

if ! command -v openssl >/dev/null 2>&1; then
  echo "UNKNOWN - openssl not found"
  exit 3
fi

# Try to force a DHE handshake while lowering local security level enough
# to observe weak DH parameters if the server still offers them.
OUTPUT="$(printf '' | openssl s_client -connect "${HOST}:${PORT}" -servername "$HOST" -tls1_2 -cipher 'EDH:@SECLEVEL=0' 2>&1)"

# If the server negotiated finite-field DH, OpenSSL 1.0.2+ usually prints:
#   Server Temp Key: DH, 1024 bits
TEMP_KEY_LINE="$(printf '%s\n' "$OUTPUT" | grep -E 'Server Temp Key: DH, [0-9]+ bits' | head -n1 || true)"

if [[ -n "$TEMP_KEY_LINE" ]]; then
  BITS="$(printf '%s\n' "$TEMP_KEY_LINE" | sed -E 's/.*DH, ([0-9]+) bits.*/\1/')"
  if [[ "$BITS" =~ ^[0-9]+$ ]]; then
    if (( BITS <= 1024 )); then
      echo "VULNERABLE - negotiated finite-field DH with ${BITS}-bit modulus"
      exit 1
    else
      echo "PATCHED - negotiated finite-field DH with ${BITS}-bit modulus"
      exit 0
    fi
  fi
fi

# If the DHE handshake failed because the server does not offer DHE at all,
# that is PATCHED for this specific Logjam-style weak-DH check.
if printf '%s\n' "$OUTPUT" | grep -Eqi 'handshake failure|no shared cipher|no cipher match|sslv3 alert handshake failure'; then
  echo "PATCHED - server did not negotiate DHE for this probe"
  exit 0
fi

# If we reached a certificate and session but saw no finite-field DH line,
# the server may be using ECDHE/RSA-only ciphers or the local OpenSSL is too old
# to expose the temporary key details.
if printf '%s\n' "$OUTPUT" | grep -Eqi 'BEGIN CERTIFICATE|Certificate chain|SSL-Session:'; then
  echo "UNKNOWN - handshake succeeded but DH size was not exposed; verify with nmap --script ssl-dh-params or a newer openssl"
  exit 2
fi

echo "UNKNOWN - could not determine DH parameter strength"
exit 2

Sources

1. Tenable Nessus Plugin 83875
2. NVD CVE-2015-4000
3. Tenable CVE page with EPSS
4. Weak Diffie-Hellman and the Logjam Attack
5. Logjam attack proof-of-concept demos
6. WeakDH deployment guide
7. OpenSSL guidance on Logjam
8. CISA 2015 vulnerability bulletin