TLS Version 1

Tenable plugin 104743 fires when a remote service still negotiates TLS 1.0. This is not a product-specific bug and not a CVE; it applies to any server, appliance, proxy, or embedded service that still accepts TLSv1 handshakes. Tenable scores it Medium / 6.5 and maps it to CWE-327 because TLS 1.0 is deprecated, lacks modern cipher support, and keeps old downgrade and CBC-era baggage alive.

In real enterprise conditions, the vendor severity is too high for generic patch triage. The decisive friction is attacker position: this is usually a man-in-the-middle or legacy-client downgrade problem, not a straight unauthenticated remote compromise. Modern browsers and many platform stacks already killed TLS 1.0 years ago, so the reachable population is narrower than the CVSS suggests. It still matters for compliance, partner integrations, and sensitive data in transit, but it is usually crypto hygiene, not emergency response.

Why this verdict

• Requires attacker-in-the-middle. The practical exploit chain usually starts with shared-network, rogue proxy, or upstream control rather than a clean internet-origin attack.
• Modern clients already suppress the bad path. Major browsers and many OS/runtime defaults stopped accepting TLS 1.0 years ago, which narrows the real exposed population.
• Blast radius is session-level, not host takeover. The likely impact is weaker confidentiality/integrity for a subset of traffic, not immediate RCE or domain compromise.

Why not higher?

There is no strong evidence that TLS 1.0 enabled by itself is a reliable one-packet compromise path. Exploitation typically depends on extra prerequisites: on-path access, legacy client behavior, and sometimes weak cipher negotiation. That stack of prerequisites compounds downward pressure on severity.

Why not lower?

Leaving TLS 1.0 enabled is still not harmless. RFC 8996 formally deprecated it in March 2021, NIST says enabling TLS 1.0 or 1.1 when unnecessary can leave systems and users vulnerable to attacks, and payment environments have had years of pressure to remove it. If the service carries sensitive data or faces partners/customers, this remains security debt worth closing.

1. Inventory legacy clients — Identify which applications, devices, or partner integrations still negotiate TLSv1, then tie each one to a business owner. For a LOW verdict there is no mitigation SLA; do this as backlog hygiene in the next normal review cycle so you can remove unjustified exceptions cleanly.
2. Restrict exposure — If TLS 1.0 must remain temporarily, keep it off internet-facing listeners where possible and confine it to internal or partner-specific entry points behind IP allowlists, VPN, or dedicated reverse proxies. For a LOW verdict there is no mitigation SLA; use the next planned change window rather than emergency maintenance.
3. Log negotiated protocol versions — Turn on TLS version logging at load balancers, proxies, and gateways so you can prove whether TLSv1 is actually used or just accidentally left enabled. For a LOW verdict there is no mitigation SLA; use this to drive cleanup before the remediation window turns into permanent exception debt.
4. Disable weak cipher overlap — Where TLS 1.0 cannot yet be removed, at least prune obviously weak cipher options and review fallback settings to reduce downgrade abuse paths. This is a temporary risk reducer only; for a LOW verdict there is no mitigation SLA, so schedule it with regular crypto hardening work.

Run this from an auditor workstation or any Linux/macOS admin host with OpenSSL that can reach the target service. Invoke it as ./check_tls10.sh example.com 443 or ./check_tls10.sh 10.10.20.15 8443 app.example.com; it needs no elevated privileges unless your environment restricts outbound connections.

#!/usr/bin/env bash
# check_tls10.sh
# Test whether a remote service still negotiates TLS 1.0.
# Exit codes:
#   0 = PATCHED (TLS 1.0 refused)
#   1 = VULNERABLE (TLS 1.0 negotiated)
#   2 = UNKNOWN (tooling/network/error)

set -u

if [ "$#" -lt 2 ] || [ "$#" -gt 3 ]; then
  echo "Usage: $0 <host> <port> [sni]"
  echo "Example: $0 example.com 443"
  echo "Example: $0 10.0.0.5 8443 app.example.com"
  exit 2
fi

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

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

OUT=$(printf '' | openssl s_client -connect "${HOST}:${PORT}" -servername "$SNI" -tls1 2>&1)
RC=$?

# Successful TLS 1.0 negotiation indicators vary a bit by OpenSSL version.
if printf '%s\n' "$OUT" | grep -qiE 'Protocol *: *TLSv1|New, *TLSv1/SSLv3'; then
  echo "VULNERABLE: ${HOST}:${PORT} negotiated TLS 1.0"
  exit 1
fi

# Common refusal signals when TLS 1.0 is disabled.
if printf '%s\n' "$OUT" | grep -qiE 'unsupported protocol|wrong version number|tlsv1 alert protocol version|handshake failure|no protocols available|alert protocol version'; then
  echo "PATCHED: ${HOST}:${PORT} refused TLS 1.0"
  exit 0
fi

# If openssl exited cleanly but we still could not parse the result, keep it conservative.
if [ "$RC" -eq 0 ]; then
  echo "UNKNOWN: connection succeeded but protocol result was not clear"
  exit 2
fi

echo "UNKNOWN: unable to determine TLS 1.0 support for ${HOST}:${PORT}"
printf '%s\n' "$OUT" | tail -n 20
exit 2

Sources

1. Tenable Nessus Plugin 104743
2. RFC 8996 - Deprecating TLS 1.0 and TLS 1.1
3. NIST SP 800-52 Rev. 2 PDF
4. Microsoft Learn - TLS 1.0 and 1.1 deprecation in Windows
5. Mozilla Security Blog - Removing Old Versions of TLS
6. Censys 2023 State of the Internet Report PDF
7. CISA Known Exploited Vulnerabilities Catalog
8. PCI SSC - PCI Changes Date for Migrating from SSL and Early TLS