← Back to Feed CACHED · 2026-06-25 03:32:03 · CACHE_KEY tenable:159543
tenable:159543 · CWE-326 · Disclosed 2022-04-06

SSL/TLS Recommended Cipher Suites (PCI DSS)

Tenable 159543 — SSL/TLS server offers non-recommended cipher suites (PCI DSS compliance check)

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

A PCI checkbox dressed up as a finding

Tenable plugin 159543 fires when a TLS endpoint advertises any cipher suite outside Mozilla's recommended modern list — meaning anything other than TLS 1.3 AEAD suites or TLS 1.2 ECDHE+AES-GCM/CHACHA20. The plugin does NOT test for a known-broken algorithm (3DES, RC4, EXPORT — those are separate plugins 65821, 26928, 42873). It fires on suites that are merely *not preferred*: CBC-mode ECDHE, plain RSA key exchange, SHA-1 MACs in TLS 1.2, anything Mozilla's intermediate profile demoted. Applies to anything terminating TLS — web servers, load balancers, mail, RDP gateways, IoT, embedded mgmt interfaces.

Vendor severity is MEDIUM (CVSS 4.8, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N) and that is generous. The CVSS vector itself admits AC:H (high attack complexity) and only Low confidentiality/integrity impact. In practice this is a configuration hygiene / compliance finding, not an exploitable vulnerability — there is no published attack that downgrades a modern client to a *non-preferred but still authenticated* cipher and decrypts traffic at scale. Treat as LOW for risk; treat as a hard requirement only if PCI DSS scope applies.

"Compliance noise, not a vulnerability. Real risk is near zero in 2026 — but PCI auditors don't care, and neither does your QSA."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Attacker achieves on-path position

An attacker must sit between client and server — same LAN, compromised upstream router, hostile Wi-Fi, BGP hijack, or ISP-level intercept. This is the gating condition for any TLS cipher-quality concern. Without on-path, cipher choice is irrelevant.
Conditions required:
  • Network adjacency or routing control
  • Ability to modify packets in flight
Where this breaks in practice:
  • Most enterprise traffic is east-west inside switched VLANs or over IPSec/WireGuard transport
  • Modern clients pin via HSTS / HPKP successors / certificate transparency
Detection/coverage: NDR / NetFlow anomaly — not specifically detected by Nessus
STEP 02

Force negotiation onto a non-preferred suite

Attacker manipulates the ClientHello to remove preferred suites (a cipher suite stripping downgrade) so the server falls back to a CBC-mode or RSA-keyex suite from the discouraged list. Tools: mitmproxy, bettercap, custom OpenSSL with restricted suite list. Note: TLS 1.3 explicitly prevents this with the downgrade-sentinel in ServerHello.random (RFC 8446 §4.1.3).
Conditions required:
  • Server still offers a non-preferred suite
  • Client willing to negotiate it
  • No TLS 1.3-only enforcement
Where this breaks in practice:
  • Browsers since 2020 reject RSA key exchange in TLS 1.3 contexts
  • Chrome/Firefox/Edge prefer ECDHE-AEAD; downgrade triggers visible warnings
  • Most clients now hard-fail on CBC for new connections
Detection/coverage: Not detected by 159543 — this plugin is config-state only, not exploit detection
STEP 03

Exploit cipher weakness for decryption or tampering

This is where the story collapses. For the suites this plugin actually flags (ECDHE-RSA-AES-CBC-SHA, RSA-AES-GCM, etc.), there is no practical decryption attack in 2026. BEAST (CBC IV reuse) was patched in TLS 1.1+ via record-splitting. Lucky13 timing was mitigated in OpenSSL 1.0.1g. ROBOT (Bleichenbacher) requires RSA key exchange AND a vulnerable padding oracle — separately fingerprinted by plugin 109031.
Conditions required:
  • Specific implementation flaw beyond cipher choice
  • Massive volume of captured/repeated sessions for timing attacks
Where this breaks in practice:
  • No known 2026-relevant attack against the merely-non-preferred suites this plugin flags
  • Real attacks (BEAST, Lucky13, ROBOT, SWEET32) are flagged by dedicated plugins, not this one
Detection/coverage: Out of scope for 159543
03 · Compensating Control

1
Centralize TLS config via a managed reverse proxy / ingress — Put all TLS termination behind nginx, HAProxy, Envoy, AWS ALB, or your CDN with a single Mozilla intermediate (or modern if clients allow) cipher list. Single config change closes the finding across hundreds of backends. This is the only path that scales — no mitigation SLA applies at LOW; treat as part of the 365-day remediation window.
2
Disable non-preferred suites on identified endpoints — Use testssl.sh -t tls12 --severity HIGH <host> to enumerate the offered list, then restrict via OpenSSL config (ssl_ciphers/SSLCipherSuite/tlsCipherSuites). Reference ssl-config.mozilla.org for vendor-specific snippets. Roll out behind a canary; some legacy clients (old Java, embedded printers, POS terminals) will break.
3
Enforce TLS 1.3 where client population allows — TLS 1.3 has no CBC, no RSA-keyex, mandatory AEAD, and a downgrade sentinel. Setting TLSv1.3 minimum on internal services closes this finding by definition. Inventory clients first — legacy .NET Framework <4.8 and old curl/openssl 1.0.x won't connect.
4
Suppress / accept on out-of-scope assets — If the host is genuinely outside PCI scope and serves only internal traffic to modern clients, document a risk acceptance in your GRC tool with 12-month review. Don't pretend to remediate every appliance mgmt UI on the planet.
What doesn't work
  • WAF rules — TLS negotiation happens before the WAF sees the request; the WAF cannot influence cipher selection
  • Certificate rotation / longer keys — irrelevant; the finding is about symmetric cipher and key-exchange algorithm, not cert strength
  • HSTS — forces HTTPS but does not constrain which TLS ciphers are negotiated within the HTTPS session
  • Network segmentation alone — reduces blast radius of any TLS issue but doesn't close the PCI finding, since PCI scope itself is the trigger
04 · Intelligence Metadata

The supporting signals.

Finding typeCompliance / configuration hygiene — not a CVE, not a software flaw
Plugin IDTenable Nessus 159543 (pci_ssl_recommended_ciphers.nasl)
Published / last updated2022-04-06 / 2024-02-21 (plugin v1.6)
CVSS v34.8 — AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N (note AC:H and Low/Low/None impact)
In-the-wild exploitationNone. No malware family or APT report keys off 'non-preferred cipher offered'. Not in CISA KEV. EPSS N/A — this is not a CVE.
Public PoCmitmproxy, bettercap, testssl.sh, sslyze can demonstrate negotiation onto flagged suites; none yields decryption against modern endpoints
Discouraged suites flaggedAnything outside Mozilla modern/intermediate: CBC-mode ECDHE, RSA key exchange, SHA-1 MAC in TLS 1.2, DHE without GCM. Does NOT flag known-broken (3DES/RC4/EXPORT — separate plugins)
Recommended suites (passing)TLS 1.3: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. TLS 1.2: ECDHE-(ECDSA|RSA)-AES(128|256)-GCM-SHA(256|384), ECDHE-*-CHACHA20-POLY1305, DHE-RSA-CHACHA20-POLY1305
Exposure populationVery high prevalence at finding-level — typical enterprise fleet scan returns this on 60–90% of TLS endpoints (load balancers, embedded mgmt, legacy app servers)
Authoritative guidanceMozilla SSL Config Generator, PCI DSS v4.0 Req 4.2.1, NIST SP 800-52r2

Sources.

  1. Tenable plugin 159543 — SSL/TLS Recommended Cipher Suites (PCI DSS)
  2. Tenable plugin 159543 changelog v1.6
  3. Mozilla SSL Configuration Generator
  4. Mozilla Server Side TLS wiki
  5. NIST SP 800-52r2 — Guidelines for the Selection, Configuration, and Use of TLS Implementations
  6. PCI DSS v4.0 (Requirement 4.2.1 — strong cryptography)
  7. RFC 8446 — TLS 1.3 (downgrade protection §4.1.3)
  8. 51Security — Remediation for SSL/TLS Recommended Cipher Suites (PCI DSS) finding
05 · The Call

Final Verdict
↓ DOWNGRADED to LOW (3.1/10)

Why this verdict

  • No exploitable attack chain: The plugin flags suites that are merely outside Mozilla's recommended list (CBC-ECDHE, RSA-keyex, SHA-1 MAC) — not the historically broken ones. Known TLS attacks (BEAST, Lucky13, ROBOT, SWEET32) target specific implementation bugs that are detected by dedicated plugins, not this one.
  • Requires on-path attacker plus downgrade plus implementation flaw: CVSS vector itself reflects this with AC:H and only C:L/I:L. Three compounding prerequisites for a theoretical impact that has no current weaponization.
  • Role multiplier — TLS termination on identity / payment endpoints: Even on a customer-facing payment page or IdP login endpoint, the worst credible outcome is reduced cryptographic margin against future breakthroughs, not 2026 decryption. Blast radius remains per-session, not fleet-wide. Floor stays LOW.
  • Compliance is the actual risk: If the scanned host is in PCI scope, this finding can fail an ASV scan and block your QSA sign-off. That's a business risk, not a security risk — and it justifies treating it as actionable backlog rather than IGNORE.

Why not higher?

MEDIUM would imply meaningful real-world exposure. There isn't any in 2026 — modern clients reject true downgrades, TLS 1.3 has built-in downgrade protection, and the flagged suites lack a published practical decryption attack. Vendor MEDIUM is compliance-driven inflation.

Why not lower?

IGNORE would be wrong because (a) PCI DSS v4.0 Req 4.2.1 makes this audit-blocking for in-scope systems, and (b) leaving CBC and RSA-keyex enabled is a hedge against future attacks and a marker of stale config. Worth fixing, just not at HIGH/CRITICAL urgency.

06 · Verification

Crowdsourced verification payload.

Run from an auditor workstation or CI runner with testssl.sh (or nmap --script ssl-enum-ciphers) installed. Invoke as ./check_159543.sh target.example.com 443 — no privileges required, only outbound TCP to the target port. Exits 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# Verify Tenable plugin 159543 — SSL/TLS Recommended Cipher Suites (PCI DSS)
# Usage: ./check_159543.sh <host> <port>
set -u
HOST="${1:-}"; PORT="${2:-443}"
if [[ -z "$HOST" ]]; then echo "Usage: $0 <host> <port>"; exit 2; fi

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

# Mozilla intermediate / modern recommended list — anything else is a finding
RECOMMENDED='TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-CHACHA20-POLY1305'

OFFERED=$(openssl s_client -connect "$HOST:$PORT" -servername "$HOST" -cipher 'ALL:!aNULL' </dev/null 2>/dev/null \
  | awk -F': ' '/Cipher    :/ {print $2}')

# Enumerate full list via cipher-by-cipher probe
FINDING=0; BAD_LIST=""
for C in $(openssl ciphers 'ALL:!aNULL:!eNULL' | tr ':' ' '); do
  RESULT=$(openssl s_client -connect "$HOST:$PORT" -servername "$HOST" -cipher "$C" </dev/null 2>/dev/null | grep -c 'Cipher    : '"$C"'$')
  if [[ "$RESULT" -gt 0 ]]; then
    if ! echo " $RECOMMENDED " | grep -q " $C "; then
      FINDING=1; BAD_LIST+="$C "
    fi
  fi
done

if [[ "$FINDING" -eq 1 ]]; then
  echo "VULNERABLE: $HOST:$PORT offers non-recommended cipher(s): $BAD_LIST"
  exit 1
else
  echo "PATCHED: $HOST:$PORT offers only Mozilla-recommended suites"
  exit 0
fi