tls_advanced.protocols Reviewed July 2026

Quick fix

Inventory legitimate clients and identify any dependency on TLS 1.0 or TLS 1.1.

What this finding means

SecuTest performs ordinary SNI-enabled handshakes for specific protocol versions. A protocol is reported as accepted only when the public endpoint negotiates it. The result identifies protocol support; it does not prove that a specific downgrade or cryptographic attack is currently exploitable.

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 exploitation of legacy TLS weaknesses

How the attack or failure scenario works

During a downgrade attack, an active network attacker interferes with negotiation so that client and server use an older protocol or weaker capabilities than they otherwise would. Legacy TLS versions also permit obsolete cipher constructions and lack modern security guarantees. Exploitation requires a compatible client, network position or protocol-specific weakness, but retaining the protocol expands the attack surface.

Conditions and limitations

  • The public TLS termination point accepts TLS 1.0 or TLS 1.1.
  • A client is willing or forced to negotiate that version.
  • A practical confidentiality or integrity attack usually requires additional network positioning, weak cipher support, or a vulnerable client implementation.

Why it matters

Security and business impact Support for TLS 1.0 or TLS 1.1 exposes clients to obsolete protocol behavior, weak cryptographic combinations, downgrade opportunities, and compliance failures.

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. Inventory legitimate clients and identify any dependency on TLS 1.0 or TLS 1.1.
  2. Disable legacy protocols at every public termination layer: CDN, load balancer, ingress controller, reverse proxy, and origin where directly reachable.
  3. Keep TLS 1.2 and TLS 1.3 enabled with modern cipher suites and certificate configuration.
  4. Stage the change, monitor failed handshakes and business transactions, and provide a time-bounded exception only for validated legacy dependencies.
  5. Remove direct-origin exposure if the managed edge enforces a stronger policy than the origin.

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.

Test TLS 1.0
openssl s_client -connect example.com:443 -servername example.com -tls1 </dev/null

Test TLS 1.1
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

Nginx example
ssl_protocols TLSv1.2 TLSv1.3;

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

Verify the fix

  1. Run `openssl s_client` with `-tls1` and `-tls1_1`; negotiation should fail.
  2. Confirm TLS 1.2 and TLS 1.3 still negotiate successfully.
  3. Test critical browsers, APIs, agents, payment integrations, and monitoring probes.
  4. Run a fresh SecuTest scan against every externally reachable hostname.
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

  • Changing only the origin while the CDN or load balancer still accepts legacy TLS.
  • Assuming a local OpenSSL policy error proves that the remote server rejected the protocol.
  • Disabling TLS 1.2 and requiring TLS 1.3 before all supported clients are compatible.
  • Leaving a direct origin address reachable with a weaker TLS policy.

Authoritative references