TLS 1.0 and 1.1 are dead: why your old protocols are a liability
A quiet leftover that still matters
Most site owners assume HTTPS is a solved, binary thing: the padlock is there, so it is fine. But HTTPS has versions, and some of them are retired. TLS 1.0 and TLS 1.1 — the protocols that encrypt the connection between browser and server — were deprecated years ago and formally removed from major browsers. The trouble is that a server can still be configured to accept them, and many quietly are.
Why old TLS is a liability
The issue is not that TLS 1.0 and 1.1 are slightly older. It is that they carry structural weaknesses that simply cannot be repaired within those versions — the fixes only exist in TLS 1.2 and 1.3. Keeping the old ones enabled means:
- A weaker negotiated connection is possible. If a client and an attacker can push the handshake toward an old protocol, you have lost ground you did not need to give up.
- Compliance findings. Standards like PCI DSS require these protocols to be disabled, so leaving them on can fail an audit independent of any actual attack.
- Mixed signals about hygiene. An outdated TLS configuration is the kind of thing a careful buyer or partner notices.
And crucially, there is no cost to turning them off, because nothing modern needs them.
Nobody current is left behind
The usual worry — will I break old visitors? — does not really apply anymore. Every current browser and operating system negotiates TLS 1.2 or 1.3 by default. The clients that can only do TLS 1.0 or 1.1 are so old they are already excluded from much of the web. Disabling the old protocols affects effectively no real users.
What to support instead
The target configuration is short:
- Enable TLS 1.2 and TLS 1.3. These are the current, secure versions; 1.3 is faster and cleaner, 1.2 covers everything else.
- Disable TLS 1.0 and 1.1 explicitly on the server, and disable the long-dead SSL versions too if they are somehow still present.
- Use strong cipher suites and prefer forward-secrecy key exchanges, so a future key compromise cannot decrypt past traffic.
- Pair it with HSTS. The
Strict-Transport-Securityheader tells browsers to always connect over HTTPS, which complements a clean protocol set.
Most hosting platforms and reverse proxies expose this as a couple of config lines, and many managed providers have already done it for you — but not all, which is why it is worth verifying rather than assuming.
Check what your server actually accepts
You cannot tell from the padlock which protocol versions your server still accepts — that is decided in the handshake, out of sight. An automated scan negotiates with your server and reports which TLS versions and ciphers are enabled, including any deprecated ones still hanging around. Scan your site and confirm the old protocols are off.