Deprecated TLS versions still enabled

SSL 2.0 and 3.0: obsolete, prohibited by RFC 6176 and RFC 7568 respectively. Their presence on a server today indicates configuration nobody has touched in a decade.

TLS 1.0 and 1.1: deprecated by RFC 8996 in 2021. Browsers removed support in 2020. They rely on hash constructions and cipher choices that are no longer considered adequate.

TLS 1.2: current, widely deployed, and fine when configured with modern cipher suites. Most of the internet runs on it.

TLS 1.3: current, specified in RFC 8446, faster because the handshake takes one round trip instead of two, and simpler because the weak options were removed from the specification rather than merely discouraged.

The practical target is 1.2 and 1.3 enabled, everything older disabled.

It is true that a current browser will not negotiate TLS 1.0, so a visitor is not at risk from it directly.

But the server is still answering. Anything that is not a current browser — a script, a scanner, an outdated embedded client, a library with a permissive default — can and will negotiate the oldest version offered.

Offering deprecated versions also fails compliance requirements that many organisations are subject to, including the payment-card standard, and that failure is discovered during an assessment rather than during a review.

And it is a signal. A server offering TLS 1.0 is usually a server whose other transport settings are equally old, which is why this check is worth running even when the direct risk is low.

A version is a negotiation framework; the cipher suite is what actually protects the connection. TLS 1.2 with a weak suite is worse than TLS 1.2 with a strong one.

Suites using RC4, 3DES, or export-grade parameters should not be offered. Neither should anything without forward secrecy, which is what ensures a future key compromise cannot decrypt today's recorded traffic.

TLS 1.3 removed the weak options from the specification, so a 1.3-only configuration cannot negotiate a bad suite. That is one of its main practical benefits.

For TLS 1.2, the suite list needs to be set explicitly — most defaults are broader than they need to be, and the breadth is what a downgrade attempt exploits.

`openssl s_client -connect example.com:443 -tls1_1 < /dev/null` attempts a TLS 1.1 handshake. A successful connection means the version is still offered; a handshake failure is the correct outcome.

Repeat for `-tls1` and, if the client supports it, for SSL 3.0.

Then confirm the current ones work: `-tls1_2` and `-tls1_3` should both succeed.

Check every hostname and every port that terminates TLS, including mail submission and any API endpoint. Web servers are frequently updated while a mail server on the same domain is not.

Test from outside your network, and test the edge rather than the origin if a CDN terminates TLS — the edge is what visitors connect to.

Set the minimum version to TLS 1.2 at whichever layer terminates the connection. On a CDN this is usually one setting; on a server it is one directive.

Check your traffic first if you have clients you do not control. Server logs record the negotiated version, and the share still using 1.0 or 1.1 is almost always a rounding error made up of scanners.

Enable TLS 1.3 at the same time, which is a performance improvement as well as a security one.

Set an explicit cipher suite list for 1.2 rather than accepting the default, preferring suites with forward secrecy and modern authenticated encryption.

Re-test each hostname afterwards, because the setting is per listener and a server with several virtual hosts can be updated in one and not the others.

`transport.tls_versions` attempts handshakes with each protocol version and reports which the server accepts, so a deprecated version appears as an observed fact rather than as a configuration reading.

`transport.cipher_suites` reports the suites offered, which is where a current version with a weak suite shows up.

`transport.certificate_details` and `transport.https` cover the certificate and the connection itself, so the transport picture is reported together.

The checks negotiate normally. They do not attempt exploits, and they do not test whether a vulnerability is exploitable — this is configuration review, not penetration testing.