TLS Version 1

Tenable plugin 84470 fires when a remote service will still negotiate TLS 1.0. This is a protocol-level finding, not a software-specific CVE: any web server, mail service, load balancer, appliance, or internal application endpoint that accepts TLS 1.0 can match. The affected range is therefore any deployment where the listener's minimum protocol is TLS 1.0 or lower, regardless of product version.

Tenable's HIGH / 8.2 score is too aggressive for most enterprises because the practical attack path usually requires a man-in-the-middle, downgrade opportunity, or legacy client actually using TLS 1.0. That is materially different from unauthenticated RCE. The risk is still meaningful for internet-facing, sensitive, or PCI-scoped systems because TLS 1.0 is deprecated by IETF, disallowed by PCI as a security control except narrow exceptions, and increasingly disabled by platform vendors.

Why this verdict

• Downward adjustment: requires more than raw network reach — the dangerous path usually needs on-path control, downgrade influence, or a legacy client actually using TLS 1.0.
• Downward adjustment: blast radius is session-level — this is about weakening transport confidentiality/integrity for a given service flow, not instant code execution or whole-host takeover.
• Upward adjustment: broad deployment pattern — the finding can exist on load balancers, appliances, web servers, and forgotten internal services, so prevalence inside large enterprises is still meaningful.
• Upward adjustment: compliance and trust impact — PCI explicitly rejects SSL / early TLS as a security control except narrow cases, so payment and partner-facing services carry outsized business risk even when exploitability is moderate.
• Downward adjustment: modern client ecosystem — browser vendors, Microsoft, and standards bodies have spent years killing TLS 1.0/1.1, which reduces successful real-world exploitation paths.

Why not higher?

This is not unauthenticated RCE, auth bypass, or wormable exploitation. The core friction is attacker position: if the adversary cannot get on path or cannot coerce a legacy handshake, mere TLS 1.0 support often remains dormant technical debt rather than an active compromise path.

Why not lower?

It still weakens a security boundary at the protocol layer, and the internet still contains millions of exposed legacy TLS services. For internet-facing auth, payment, or sensitive data flows, the confidentiality impact is real enough that writing it off as backlog hygiene would be irresponsible.

1. Enforce TLS 1.2+ at the edge — Set the minimum protocol to TLS 1.2 or higher on load balancers, reverse proxies, CDN edges, mail gateways, and VPN portals first, because that collapses exposure for many backends at once. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but prioritize PCI-scoped and internet-facing services immediately because audit and customer impact outrun the security score.
2. Inventory legacy clients before change — Pull connection telemetry from web proxies, load balancers, Schannel/OpenSSL logs, or Zeek to identify who still negotiates TLS 1.0 before you disable it. This avoids the classic enterprise trap where the only systems broken are old scanners, Java runtimes, embedded devices, or payment terminals that nobody remembered.
3. Segment unavoidable exceptions — If a business-critical legacy device truly cannot move yet, isolate it behind dedicated VIPs, ACLs, or private network paths and keep it out of shared internet-facing listener pools. For MEDIUM, there is no mitigation SLA, but exception containment should still happen well before the 365-day remediation deadline because it reduces exposure while replacement work is scheduled.
4. Prefer protocol enforcement over host patch chasing — Where possible, fix this once in the TLS termination layer instead of touching every backend host individually. That is the fastest path for large estates and it avoids partial cleanup where the app server is hardened but an old management port or alternate listener still accepts TLS 1.0.

Run this from an auditor workstation or Linux jump host that can reach the target service over the network. Invoke it as bash check_tls10.sh example.com 443; it needs only normal user privileges and outputs VULNERABLE, PATCHED, or UNKNOWN based on whether a TLS 1.0 handshake succeeds.

#!/usr/bin/env bash
# check_tls10.sh
# Purpose: verify whether a remote service still negotiates TLS 1.0
# Usage: bash check_tls10.sh <host> <port>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN/usage

set -u

HOST="${1:-}"
PORT="${2:-}"
TIMEOUT_BIN="$(command -v timeout || true)"
OPENSSL_BIN="$(command -v openssl || true)"

if [[ -z "$HOST" || -z "$PORT" ]]; then
  echo "UNKNOWN - usage: bash check_tls10.sh <host> <port>"
  exit 2
fi

if [[ -z "$OPENSSL_BIN" ]]; then
  echo "UNKNOWN - openssl not found"
  exit 2
fi

run_cmd() {
  if [[ -n "$TIMEOUT_BIN" ]]; then
    "$TIMEOUT_BIN" 12 "$@"
  else
    "$@"
  fi
}

# Force TLS 1.0 negotiation. If handshake succeeds and a certificate/connection is established,
# the service is still vulnerable from a protocol-support perspective.
OUTPUT="$(echo | run_cmd "$OPENSSL_BIN" s_client -connect "${HOST}:${PORT}" -servername "$HOST" -tls1 2>&1)"
RC=$?

if echo "$OUTPUT" | grep -qiE 'CONNECTED\(|Protocol *: *TLSv1|Cipher *: '; then
  if ! echo "$OUTPUT" | grep -qiE 'alert protocol version|unsupported protocol|wrong version number|no protocols available|handshake failure'; then
    echo "VULNERABLE - ${HOST}:${PORT} accepted or negotiated TLS 1.0"
    exit 1
  fi
fi

if echo "$OUTPUT" | grep -qiE 'alert protocol version|unsupported protocol|no protocols available|handshake failure'; then
  echo "PATCHED - ${HOST}:${PORT} rejected TLS 1.0"
  exit 0
fi

if [[ $RC -ne 0 ]]; then
  echo "UNKNOWN - handshake test failed (network issue, non-TLS service, or ambiguous response)"
  exit 2
fi

echo "UNKNOWN - ambiguous response, inspect manually"
exit 2

Sources

1. Tenable Nessus Plugin 84470
2. PCI SSC FAQ: Does PCI DSS define which versions of TLS must be used?
3. PCI SSC blog: PCI Changes Date for Migrating from SSL and Early TLS
4. RFC 8996: Deprecating TLS 1.0 and TLS 1.1
5. NIST SP 800-52 Rev. 2
6. Microsoft Learn: TLS 1.0 and TLS 1.1 deprecation in Windows
7. Censys 2023 State of the Internet Report