Still serving TLS 1.0 or 1.1? What deprecated protocols cost you

Transport Layer Security is the protocol behind the padlock — it encrypts and authenticates the connection between a browser and your server. But "TLS" is not one thing; it is a family of versions stretching back decades, and the oldest members are still switched on far more often than their owners realise. If your server still answers on TLS 1.0 or 1.1, you are carrying a liability that browsers, auditors, and attackers all noticed years ago. This article explains where the version line sits today and how to retire the old protocols without breaking real users.

The protocol version landscape

The lineage runs from SSL through TLS, and only the newest part of it is still fit for purpose:

SSL 2.0 and 3.0 have been considered unusable for a long time and should never appear on a modern host. TLS 1.0 and 1.1 are the interesting case, because they still work and so they linger. They were formally deprecated by the IETF in RFC 8996 in 2021, and the major browsers — Chrome, Firefox, Safari, and Edge — coordinated to remove support for them in 2020. In practice the entire modern web already moved on: TLS 1.2 and 1.3 are the baseline, and everything below is legacy surface you are keeping alive for no one.

What the old versions actually cost you

Weak cryptographic constructions

The problem with TLS 1.0 and 1.1 is not a single bug you can patch; it is the age of the machinery they are built from. Both predate AEAD cipher suites — the authenticated-encryption modes (AES-GCM, ChaCha20-Poly1305) that TLS 1.2 introduced and TLS 1.3 made mandatory. That leaves the old versions relying on CBC-mode ciphers and legacy stream ciphers like RC4, whose constructions have been picked apart repeatedly. BEAST and POODLE trace back to weaknesses in the older CBC record design, while CRIME abused TLS-level compression — all of them addressed in the newer versions. RC4, meanwhile, has known biases that make it unsafe to use at all. You do not need to follow any single attack in detail to draw the conclusion: a protocol version that cannot offer a modern AEAD cipher is one you should not be negotiating.

TLS 1.3 went further and deleted the dangerous options outright — it removed CBC-mode ciphers, RC4, static RSA key exchange, renegotiation, and compression, and it requires forward secrecy on every handshake. Much of the value of moving off 1.0/1.1 is simply that the newer versions no longer offer the weak choices as a fallback an attacker can try to force.

Compliance failures

If you take card payments, this is not optional. PCI DSS required merchants to migrate off SSL and "early TLS" (TLS 1.0) by mid-2018, and TLS 1.1 is permitted only with justification and is effectively discouraged — TLS 1.2 or higher is the expectation. An assessor scanning your endpoint will flag a server that still accepts these versions, and it can hold up an audit regardless of how strong the rest of your configuration is. Other frameworks and security questionnaires increasingly treat the same way.

Browser warnings and lost trust

Because browsers dropped these versions, a client that can only speak TLS 1.0/1.1 can no longer reach you. More commonly the damage is reputational: security scanners, vendor risk assessments, and "test your SSL" tools all downgrade a site that still advertises deprecated protocols — and that downgrade shows up in the exact places a prospective customer or partner looks before trusting you.

How to check what your server negotiates

The only thing that matters is what your endpoint will actually agree to, so check it from the outside rather than reading your config and hoping. An external scan — Cyber Report, a testssl.sh-class tool, or any reputable public SSL tester — attempts a handshake at each protocol version in turn and records which ones succeed. If a handshake completes on TLS 1.0 or 1.1, that version is live, whatever your intended settings say. Do this per hostname and per port; it is common to tighten the main site and forget an API subdomain, a mail host, or a load balancer that terminates TLS with its own, older defaults.

How to retire 1.0 and 1.1 safely

"Safely" is the operative word — the reason old versions survive is fear of cutting off a real user. Work through it in order:

1. Confirm your real client base can do TLS 1.2+. Every current browser and operating system has handled TLS 1.2 for many years, and reasonably up-to-date API clients, mobile apps, and libraries do too. If you have server-side handshake logs, look at the negotiated-version breakdown before you change anything — for most sites the traffic on 1.0/1.1 is negligible or entirely automated.
2. Disable TLS 1.0 and 1.1 server-side, and enable TLS 1.3. On nginx this is a one-line change:

   ssl_protocols TLSv1.2 TLSv1.3;

   Apache uses SSLProtocol -all +TLSv1.2 +TLSv1.3, and load balancers and CDNs expose the same setting as a "minimum TLS version" policy. Set it everywhere that terminates TLS, not just the origin.
3. Prefer strong TLS 1.2 ciphers. With 1.0/1.1 gone, pin the remaining 1.2 suites to forward-secret AEAD ciphers (ECDHE with AES-GCM or ChaCha20-Poly1305). Rather than hand-copy a cipher string that will go stale, generate one from Mozilla's SSL Configuration Generator using its "Intermediate" profile, which is the sensible default for a public site.
4. Re-scan to confirm. After the change, run the external check again and verify that 1.0/1.1 now fail to negotiate and that 1.2/1.3 succeed.

HSTS: the complementary control

Retiring old protocol versions hardens the HTTPS you serve — but it does nothing if a visitor never reaches HTTPS in the first place. HTTP Strict Transport Security (HSTS) is the complement: a response header that tells browsers to only ever connect to you over HTTPS, closing the plaintext-first window an attacker could use to downgrade or intercept a connection. A typical policy looks like:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Add the preload directive and submit your domain to the browser preload list, and browsers ship the HTTPS-only rule for your site out of the box, before the first request. HSTS sits with the rest of your response headers, so it is worth reading how those fit together in HTTP security headers explained. One caveat: a hardened front door helps only if there is no side door — if your origin IP is exposed and directly reachable, an attacker may connect to it with whatever weaker TLS it happens to allow, bypassing the CDN entirely.

How Cyber Report checks this

Cyber Report runs an external, non-intrusive TLS audit: it negotiates with your endpoint to enumerate which protocol versions and cipher classes it will actually accept. It flags support for a deprecated protocol (TLS 1.0/1.1) as a high-severity finding and the absence of TLS 1.3 as a low, and a companion cipher-class check flags insecure or anonymous cipher suites — alongside certificate validity and HSTS, so you see the whole transport-security picture in one report rather than a single number from an isolated tool.

See what we scan, or run a scan on your own domain to see where you stand.