Where the versions stand
| Version | Year | Status |
|---|---|---|
| SSL 2.0, SSL 3.0 | 1995, 1996 | Prohibited (RFC 6176, RFC 7568). No modern client will negotiate them. |
| TLS 1.0, TLS 1.1 | 1999, 2006 | Deprecated (RFC 8996, 2021). Removed from Chrome, Firefox, Safari and Edge in 2020. Fail PCI DSS. |
| TLS 1.2 | 2008 | Current, still fine when configured well. Required by some older clients and by most enterprise middleboxes. |
| TLS 1.3 | 2018 | Current, preferred. Faster, simpler, and impossible to configure badly in the ways 1.2 allowed. |
What TLS 1.3 changed
One round trip instead of two
A TLS 1.2 handshake takes two round trips before the client can send its request: hello, server certificate and key exchange, client key exchange and finished, then data. TLS 1.3 folds the key exchange into the first flight, so the client sends its key share with the hello, the server replies with its own share plus the certificate and its finished message, and the client's next packet can already carry the HTTP request. One round trip. On a connection with 50 ms latency that is 50 ms off every new connection, and for resumed connections 1.3 can send data in the very first packet (0-RTT), with some caveats about replay that most servers handle by only allowing it for idempotent requests.
The weak options are gone
TLS 1.2 is a negotiation over a large menu. Cipher suites choose the key exchange (RSA or Diffie-Hellman, static or ephemeral), the certificate signature, the bulk cipher (AES-CBC, AES-GCM, 3DES, RC4, ChaCha20) and the MAC, and many combinations that were once acceptable are now known to be weak: RSA key exchange has no forward secrecy and was the vector for ROBOT and Bleichenbacher attacks; CBC mode suites were the vector for BEAST, Lucky13 and POODLE-style padding oracles; RC4 and 3DES are broken outright. A 1.2 server is only as safe as the suite list its administrator wrote.
TLS 1.3 removes all of that from the menu. Key exchange is always ephemeral Diffie-Hellman (so every connection has forward secrecy), there are five cipher suites in total and all are AEAD (AES-GCM, AES-CCM or ChaCha20-Poly1305), there is no renegotiation, no compression, and no static RSA. You cannot misconfigure a 1.3 server into a weak handshake, which is the practical reason to want it even if you do not care about the round trip.
More of the handshake is encrypted
In 1.2 the server's certificate crosses the wire in the clear. In 1.3 everything after the server's key share is encrypted, including the certificate, so a passive observer sees the SNI hostname in the client hello (that is still plaintext, pending Encrypted Client Hello) but not which certificate came back or what extensions were negotiated.
What still needs TLS 1.2
- Old clients. Android 4.4 and earlier, Java 8 before update 261, Windows 7 with Internet Explorer, .NET Framework before 4.8, older payment terminals and embedded devices. Whether any of these matter depends entirely on who connects to you; your access logs know.
- Enterprise inspection middleboxes. Some corporate proxies and firewalls that intercept TLS did not handle 1.3 when it shipped. Most have been updated; some have not. A server that only offers 1.3 will be unreachable from behind them.
- Mail. SMTP servers talking to each other are a long tail of software, and a mail server that refuses 1.2 will lose inbound mail from senders that cannot do 1.3. Offer both on port 25.
The answer for a public web server in 2026 is to offer 1.3 and 1.2, and to configure 1.2 with a short, modern suite list (ECDHE key exchange only, AEAD ciphers only). That covers every current client at 1.3 speed and every plausible old client safely. Offering 1.3 alone is fine for an API whose clients you control.
What to switch off
TLS 1.0 and 1.1. There is no client still in wide use that needs them and cannot do 1.2, and their presence fails PCI DSS scans and most security questionnaires. They stay on for one reason: the server or load balancer shipped with them on and nobody has looked. Terminating TLS at a CDN or a cloud load balancer usually means picking a named policy; choose the one that starts at 1.2.
Also worth removing from the 1.2 suite list: anything with RSA as the key exchange (as opposed to the signature), anything with CBC, 3DES, RC4 or NULL, and the SHA1 MAC suites. Mozilla's SSL configuration generator produces a sensible list for most servers; "intermediate" is the right profile for a public site.
Checking what a server really does
Advertised support and actual support differ, particularly behind load balancers. The SSL/TLS certificate checker does four extra handshakes against the host, each offering exactly one protocol version, and reports which ones completed. A "yes" under TLS 1.0 means the server finished a 1.0 handshake, not that it mentioned it somewhere. It also shows the version and cipher suite negotiated with a modern client, which should read TLS 1.3 and one of the AEAD suites; a modern client landing on 1.2 means 1.3 is not offered.
curl "kirkdiamond.com/tools/tls?host=example.com" # text report, includes the version grid openssl s_client -connect example.com:443 -tls1_1 < /dev/null # should fail with "no protocols available" or an alert
Run it against every hostname that terminates TLS separately: the CDN edge, the origin if it is reachable directly, the API hostname, the mail server on 25 and 465. They are commonly on different software with different defaults. The domain health checker includes the TLS 1.3 and legacy protocol findings for the apex in its TLS pillar.