TL;DR: TLS 1.0 and 1.1 are dead. The IETF deprecated them in 2020, PCI-DSS banned them in 2018, and every mainstream browser refuses them. But “no browser uses them” isn’t the same as “nobody can use them” — if your server still accepts those versions, scanners and old API clients can negotiate down into a protocol with known, unfixable attacks. The fix is one config line. Do it today.

What is it?

TLS — Transport Layer Security — is the protocol behind the padlock in the address bar. It has gone through five public versions:

VersionPublishedStatus
TLS 1.01999Deprecated (RFC 8996, March 2021)
TLS 1.12006Deprecated (same RFC)
TLS 1.22008Supported floor
TLS 1.32018Modern bar (RFC 8446)

Older still are SSL 2.0 (1995) and SSL 3.0 (1996) — the predecessors TLS replaced. Both were broken so thoroughly that they’re now disabled by default in every web server, every TLS library, and every browser. They show up here only as a reminder that TLS itself is the third generation of the protocol, and “newer is better” is not a fashion take — each version closed real attack classes the prior one couldn’t.

When we say a server “supports” a version, we mean: if a client opens the connection asking for that version, the server will agree and proceed with the handshake. A server that supports TLS 1.0 through TLS 1.3 will happily speak whichever the client picks. A server that only supports TLS 1.2 and 1.3 will refuse the connection if the client asks for anything older — which is what you want.

This factor grades on the floor, not the ceiling. Supporting TLS 1.3 doesn’t help you if you also still accept TLS 1.0 — an attacker or a poorly-written client will just pick the floor.

Why does it matter?

Three reasons, in roughly the order they’ll bite you.

Known, unfixable attacks. TLS 1.0 and 1.1 have protocol-level weaknesses that the cipher suites can’t paper over. BEAST (2011) exploited TLS 1.0’s CBC IV chaining. POODLE (2014) used the same record-padding ambiguity. Lucky 13 (2013) was a timing attack on the MAC-then-encrypt construction. TLS 1.2 introduced AEAD ciphers (GCM, ChaCha20-Poly1305) that structurally prevent these. TLS 1.3 went further and removed the broken constructions entirely. You cannot patch TLS 1.0 — the protocol is the weakness.

PCI-DSS noncompliance. If your site touches credit-card data — even just by embedding a payment iframe from a processor — PCI-DSS 4.0 has prohibited TLS 1.0 and TLS 1.1 since June 30, 2018. Auditors flag this. Some QSAs (Qualified Security Assessors) will fail your attestation outright. The remediation is one config line, and there’s no compliance reason to wait.

Browser deprecation already happened. Safari 13 (Sept 2020), Chrome 84 (July 2020), Firefox 78 (June 2020), and Edge 84 (July 2020) all dropped support for TLS 1.0 and 1.1. So in practice, no human visiting your site in a real browser is negotiating those versions — they couldn’t even if you let them. Which raises the question: if nobody legitimate can use it, who’s still able to?

The answer is the surface area you don’t see. Old corporate proxies locked at TLS 1.0. Embedded devices and IoT clients on firmware that hasn’t been updated since 2015. Headless scrapers, monitoring agents, and partner integrations whose HTTP libraries default to whatever the server allows. Vulnerability scanners hunting for the easiest path in. None of those will warn you. They’ll just connect over the weakest version you accept and never tell you they did.

Real-world analogy

Picture your front door. You have three locks installed: a modern smart-lock (TLS 1.3), a regular deadbolt (TLS 1.2), and a 1970s skeleton-key lock that came with the house (TLS 1.0/1.1). You haven’t used the skeleton-key lock in years — you don’t even keep the key on your ring anymore. But it’s still there, still bolted to the door, still functional.

A burglar walks up. They try the smart-lock — too modern, no off-the-shelf attack. They try the deadbolt — solid hardware, would take real work. Then they notice the skeleton-key lock. Five seconds with a tension wrench and a bent paperclip and they’re in.

It doesn’t matter that you never use the old lock. It only matters that it’s there. Disabling TLS 1.0/1.1 is unscrewing the skeleton-key lock from the door.

How WQI measures this

We grade TLS minimum version as WEBQ-27 in the Security category. We measure it directly: our TLS reader opens handshakes against your server on port 443 and records which versions your server agrees to. We grade on the lowest version it will accept.

ResultWhat it means
Pass (100)Only TLS 1.2 and 1.3 accepted, and TLS 1.3 is supported.
Warn (60)TLS 1.2 only (no 1.3 advertised), OR HTTPS reachable but our handshake was blocked.
Fail (0)TLS 1.0 or 1.1 still accepted, OR no HTTPS at all.

The warn tier exists because TLS 1.2-only is a real configuration choice — some compliance regimes still standardize on 1.2 as the only allowed version. It’s not wrong, but it’s behind the modern bar, so we mark it down without failing it.

What good looks like

Pass on WEBQ-27, every audit, every domain. Concretely: TLS 1.2 and TLS 1.3 supported, TLS 1.0 and 1.1 refused, SSL 2/3 long-since gone. There’s no compatibility reason in 2026 to leave the old versions on — every device that can’t speak TLS 1.2 was end-of-life years ago.

How to fix it

Nginx — in the server block (or http block to apply globally):

ssl_protocols TLSv1.2 TLSv1.3;

That’s it. Reload Nginx (nginx -s reload) and the change is live.

Apache — in your VirtualHost or main config:

SSLProtocol -all +TLSv1.2 +TLSv1.3

The -all first explicitly disables every version, then +TLSv1.2 and +TLSv1.3 re-enable the two you want. Belt-and-suspenders, but that’s the canonical syntax.

Cloudflare — Dashboard → SSL/TLS → Edge Certificates → Minimum TLS Version → set to 1.2. (1.3 is also offered, but 1.2 is the safe choice; setting min to 1.3 will refuse legitimate clients that haven’t updated yet.)

AWS ALB / CloudFront — pick a security policy of ELBSecurityPolicy-TLS13-1-2-2021-06 or newer. Anything ending in TLS-1-0-2015-04 or TLS-1-1-2017-01 still accepts the old versions and needs to be replaced.

IIS — disable the SCHANNEL keys for TLS 1.0 and 1.1 under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Microsoft has a PowerShell script for the change; don’t edit the registry by hand if you can avoid it.

Verify by trying to connect with the old versions explicitly. The handshake should fail:

openssl s_client -tls1   -connect yourdomain.com:443 </dev/null
openssl s_client -tls1_1 -connect yourdomain.com:443 </dev/null

You should see ssl handshake failure or protocol version for both. And confirm 1.2 + 1.3 still work:

openssl s_client -tls1_2 -connect yourdomain.com:443 </dev/null
openssl s_client -tls1_3 -connect yourdomain.com:443 </dev/null

Both should complete and print a certificate chain.

Common pitfalls

  • Old load balancer firmware. F5, Citrix NetScaler, A10, and other appliances stuck on firmware from 2017 or earlier sometimes default to TLS 1.0/1.1 and require a firmware bump or manual policy change to drop them. The web server behind them looks fine; the LB in front betrays you. Test against the public hostname, not the origin.
  • Embedded devices and IoT. Routers, printers, IP cameras, and industrial gear with admin web UIs are notorious for shipping with ancient TLS stacks. If those are on the public internet, fix the device or hide it behind a modern reverse proxy.
  • Partner integrations that haven’t updated. Sometimes you’ll get a complaint from a B2B partner when you disable the old versions: “our client can’t connect anymore.” That client is running on a legacy HTTP library that hard-codes TLS 1.0. The fix is on their side, not yours. Hold the line — accommodating them by re-enabling weak protocols is how the long tail of broken servers stays broken.
  • CDN configured separately from origin. If you sit behind a CDN, the CDN edge is what visitors hit — and that’s where the policy matters. But your origin still needs TLS 1.2+ for the CDN-to-origin hop. Don’t fix one and forget the other.
  • Per-port configuration. TLS isn’t only on 443. If you expose 443, 8443, mail submission (587/465), or anything else over TLS, audit the version policy on each port independently.

Further reading