TLS 1.2 vs 1.3: what to enable and what to disable

Published October 2, 2026 · about a 6-minute read

A scan tells you the server "supports TLS 1.0" or "TLS 1.3 not enabled," and now you're trying to work out which versions to actually keep. Let me give you the answer first, then the reasoning: enable TLS 1.3, keep a hardened TLS 1.2, and turn off 1.0 and 1.1. That's the right config for essentially every website in 2026. Here's why.

What TLS 1.3 actually changed

TLS 1.3 isn't a small bump over 1.2 — it's a cleanup. The headline differences:

• Faster. The handshake dropped from two round trips to one, which roughly halves connection-setup latency. On a fresh visit, that's a real speed win, especially on mobile.
• Forward secrecy is mandatory. Every 1.3 session uses ephemeral keys (ECDHE), so stealing your private key later can't decrypt traffic captured today. In 1.2 that protection was optional.
• More of the handshake is encrypted, including the server certificate — less metadata leaks to anyone watching.
• Five cipher suites, not hundreds. TLS 1.3 removed every legacy and weak option from the protocol. There's no insecure way to configure it, because the insecure choices no longer exist.

Is TLS 1.2 still safe? Yes — with an asterisk

Don't rush to rip out 1.2. It's not deprecated, there's no break against the protocol itself, and you need it for the long tail of clients that don't speak 1.3 yet. Turning it off can lock out real users.

The asterisk is configuration. TLS 1.2's weakness is its flexibility: it still allows CBC-mode ciphers, SHA-1, and plain RSA key exchange with no forward secrecy. None of those should be on. Restrict 1.2 to ECDHE key exchange with AEAD ciphers (the GCM/ChaCha20 family) and it's genuinely secure. Leave the old options enabled and your "TLS 1.2 supported" is hiding a soft underbelly.

TLS 1.3 is safe because the bad options were removed. TLS 1.2 is safe only because you removed them. Same destination, but 1.2 needs you to do the work.

TLS 1.0 and 1.1: just turn them off

There's no debate here. TLS 1.0 and 1.1 were formally deprecated in 2021. They lean on MD5 and SHA-1 — both cryptographically broken — are vulnerable to padding-oracle attacks, and are flat-out prohibited for cardholder data under PCI DSS. Every major browser dropped them years ago, so you're not keeping a real audience by leaving them on; you're only keeping an attack surface. Disable them and move on.

The config to actually run

For nginx, that's essentially one line plus a cipher list:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

TLS 1.3 brings its own cipher suites automatically, so that cipher line only governs 1.2 — and it only allows ECDHE + AEAD. Apache and most load balancers have the equivalent two settings. If you're on a managed host or CDN, this is usually a dropdown: set the minimum TLS version to 1.2.

The part that silently regresses

Here's what bites teams months later: TLS config drifts. A server gets rebuilt from an older image, a platform changes its defaults, a new load balancer ships with 1.0 enabled "for compatibility," and suddenly a scan you passed in spring is failing in autumn — with nobody having touched it on purpose. Protocol configuration is exactly the kind of thing that's correct the day you set it and quietly wrong later. It's the same silent-drift pattern behind a lapsed certificate or a dropped security header.

So check it, and keep checking it. Our free site checker reports your TLS protocol versions and cipher strength alongside your certificate, headers and DNS — a quick way to confirm 1.3 is on, 1.0/1.1 are off, and 1.2 is hardened.