tls.protocol_version Reviewed July 2026

Quick fix

Measure the client population and identify any documented legacy dependencies.

What this finding means

SecuTest records the protocol negotiated by a normal verified connection and expects TLS 1.2 or TLS 1.3. This baseline check is distinct from the advanced enumeration check, which tests whether legacy versions are also accepted.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Protocol downgrade and legacy cryptographic attacks

How the attack or failure scenario works

A downgrade attack causes a client and server to use an older protocol than the strongest mutually supported version. Legacy TLS versions contain design limitations and enable weaker cipher choices. Exploitability depends on client support, accepted ciphers, and attacker position.

Conditions and limitations

  • The server negotiates or accepts an obsolete TLS version.
  • A client still supports that version or can be forced onto it.
  • An attacker can influence the network connection or exploit weaknesses in the negotiated protocol and cipher.

Why it matters

Security and business impact Negotiating an obsolete or unknown TLS version exposes clients to deprecated protocol behavior and weakens compliance with modern security baselines.

Step-by-step fix

Where to make the change

  • The public TLS termination point: CDN, load balancer, reverse proxy, ingress controller, or web server.
  • The origin server only when it directly terminates the externally observed TLS connection.

Remediation procedure

  1. Measure the client population and identify any documented legacy dependencies.
  2. Set the minimum public protocol to TLS 1.2 and enable TLS 1.3 where supported.
  3. Apply the setting at the CDN, load balancer, ingress, reverse proxy, and origin as applicable.
  4. Retest legacy business clients and document any time-bounded exception.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Nginx
ssl_protocols TLSv1.2 TLSv1.3;

Apache
SSLProtocol -all +TLSv1.2 +TLSv1.3

OpenSSL tests
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

Verify the fix

  1. Confirm TLS 1.2 and TLS 1.3 handshakes succeed.
  2. Attempt TLS 1.0 and TLS 1.1 and confirm the server rejects them.
  3. Check the effective public edge, not only the origin configuration.
  4. Repeat SecuTest after all termination points are updated.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Disabling TLS 1.2 before every supported client can use TLS 1.3.
  • Changing only the origin while the CDN still accepts legacy protocols.
  • Confusing the local OpenSSL client's policy rejection with server-side rejection.

Authoritative references