TLS 1.2 vs 1.3: What to Enable, What to Kill
The version matrix in plain terms: why 1.0 and 1.1 must die, whether 1.2 is still fine, what 1.3 buys you, and how to check what your server offers.
Short answer
Kill SSL, TLS 1.0, and TLS 1.1. Keep TLS 1.2. Prefer TLS 1.3. Verify from the public internet after you change the config.
The 2026 matrix
1.0 and 1.1 are deprecated and blocked by modern browsers for good reason. 1.2 remains acceptable. 1.3 is faster and cleaner.
Enable 1.3 everywhere your stack allows, and stop advertising dead versions to opportunistic scanners.
Readers skimming tls versions enable kill often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Where to set it
Load balancers, reverse proxies, and CDNs often override app servers.
Change the layer that terminates TLS for real users, not only a local nginx on a box nobody hits.
Common failure mode for tls versions enable kill: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
Prove it
After deploy, scan from outside. Internal dashboards lie when a CDN still offers weak versions at the edge.
If two layers disagree, the weaker public offer wins for attackers - align them.
If this section on tls versions enable kill becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- Identify the TLS terminator users actually reach.
- Disable 1.0 and 1.1 (and SSL) there.
- Enable 1.3; keep 1.2 if required.
- External scan + curl --tlsv1.0 should fail against production.
Old protocol versions are not nostalgia. They are attack surface.
Update log (1)
2026-05-19Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
