PingfloatVisit Website →
← Back to blog

TLS Versions Explained: 1.0, 1.1, 1.2 and 1.3 Compared

October 18, 2026
TLS Versions Explained: 1.0, 1.1, 1.2 and 1.3 Compared

TLS 1.0 and 1.1 are deprecated and should be switched off. TLS 1.2 is still acceptable when it is configured well. TLS 1.3 is the version to prefer, and the one your servers should negotiate whenever the client supports it. The rest of this guide explains why, what changed between versions, and how to check what your own server offers.

Pingfloat
pingfloat.com
Check Your Site’s SSL Health
Pingfloat’s SSL certificate checks help you review certificate status as you assess your server’s TLS configuration.
Check SSL certificates

TL;DR

  • TLS 1.0 and 1.1 were formally deprecated by the IETF in RFC 8996 and moved to Historic status. Disable them.
  • TLS 1.2 remains widely used and is considered secure with a modern configuration, but it gets no new features.
  • TLS 1.3 has a faster handshake, a cleaner design and built-in downgrade protection. Prefer it wherever you can.
  • Running 1.2 and 1.3 side by side is normal and supported. Clients and servers pick the highest version both understand.
  • The version is only half the story. Cipher suites and certificate hygiene matter just as much.

Table of Contents

What TLS is and how its versions relate

Transport Layer Security is the protocol that encrypts traffic between a client and a server, for example a browser and a website. It replaced SSL, and the first TLS version was published in 1999. People still say "SSL certificate" out of habit, but what protects a connection today is TLS.

The versions you will meet in practice are:

  • SSL 2.0 and 3.0: the predecessors. Not acceptable anywhere.
  • TLS 1.0: the direct successor to SSL 3.0, specified in RFC 2246.
  • TLS 1.1: a small revision of 1.0, specified in RFC 4346.
  • TLS 1.2: the long-serving workhorse.
  • TLS 1.3: specified in RFC 8446 in 2018 and the current version.

Note the numbering: certificates and protocol versions are separate things. A certificate proves who the server is. The TLS version and cipher suite decide how the session is encrypted. You can have a perfectly valid certificate on a server that still offers a weak protocol.

Deprecated TLS versions: 1.0 and 1.1

In March 2021, RFC 8996 formally deprecated TLS 1.0 and 1.1. Both specifications were moved to Historic status. The reason given is that these versions lack support for current and recommended cryptographic algorithms.

In practical terms that means:

  • No modern ciphers. You cannot build a strong configuration on top of them, no matter how carefully you tune the server.
  • Compliance trouble. Industry standards such as PCI DSS prohibit them, so a payment-handling site that still offers them risks failing an audit.
  • Little upside. Very few legitimate clients still depend on them. The ones that do are usually old embedded devices, ancient Java runtimes or abandoned appliances.

If you are asking whether TLS 1.0 and 1.1 are outdated, the answer is yes, and not just by convention: the standards body that wrote them has retired them.

A short note on why site owners keep them anyway. It is almost always inertia: a default config copied years ago, a load balancer nobody revisited, or a fear that an old customer device will break. Fear is worth testing rather than guessing. Look at your access logs or your load balancer's protocol metrics, count how many connections actually use 1.0 or 1.1, and decide with data. For a small-business angle on why "free SSL" does not mean "finished", this piece on keeping SSL maintained on small business websites is a useful read.

TLS 1.2: still fine, with conditions

TLS 1.2 is the version most of the internet ran on for years, and it is still everywhere. Is it still secure? Yes, when configured with a modern cryptographic profile. Cloudflare's overview describes it as widely used and secure in that case, but lacking the performance gains and architectural security changes of 1.3.

The condition matters. TLS 1.2 lets you configure terrible things: weak ciphers, static key exchange without forward secrecy, outdated hash functions. The version number does not stop you. A server speaking TLS 1.2 with a careful cipher list is fine. The same server with a default legacy list is not.

The UK's National Cyber Security Centre makes two points in its guidance on using TLS: TLS 1.2 gives strong protection when correctly configured, but it will not receive new features and is not quantum-safe. The direction of travel is a planned migration to 1.3.

In the US, NIST Special Publication 800-52 Rev. 2 sets TLS 1.2 with approved cipher suites as a baseline and requires government TLS servers and clients to support TLS 1.3. If you sell to federal agencies, or build for those who do, plan for 1.3 support, not just 1.2. Vendors are being held to the same bar; this look at video conferencing security controls drawn from NCSC and CISA guidance shows how those expectations reach everyday business tools.

TLS 1.3: what actually changed

TLS 1.3 is not a point release. According to IETF drafts, it is a re-architecture of the handshake, message flow, key derivation and cipher suites. That is why some legacy systems cannot simply bump a version number and need real code changes.

Faster handshakes

TLS 1.3 needs one round trip to set up a connection, compared to two in TLS 1.2, and it supports zero round trips on resumed sessions. On a mobile connection or a long-distance link, that shaves visible latency off the first request.

TLS handshake round trips compared by version

A smaller, safer menu

The design removes much of the optionality that made 1.2 easy to misconfigure. Fewer choices means fewer ways to end up with a weak setup.

Downgrade protection

If an attacker tries to push a connection to an older version, TLS 1.3 has a defense. A server that supports 1.3 but is forced to negotiate 1.2 or lower embeds a signature in its random value. A 1.3-capable client checks for it and aborts the connection if it sees one.

Client detects downgrade signature and aborts connection

The 0-RTT caveat

Zero round trip resumption sends data in the first flight, which is quick, but it is vulnerable to replay attacks. Only allow it for requests that are safe to repeat, such as simple GETs. Do not use it for payments, account changes or anything that is not idempotent, unless the application adds its own replay protection.

Side-by-side comparison

TLS 1.0TLS 1.1TLS 1.2TLS 1.3
StatusDeprecated (RFC 8996)Deprecated (RFC 8996)Acceptable if well configuredRecommended
Modern cipher supportNoNoYes, if you choose themBuilt in, legacy options removed
Handshake round tripsNot applicable, do not useNot applicable, do not useTwoOne (zero on resumption)
Downgrade protectionNoNoLimitedYes, built in
Use in new deploymentsNeverNeverOnly alongside 1.3Default

Are TLS 1.2 and 1.3 compatible?

Yes. They are designed to coexist. RFC 9325, the IETF's current recommendations for secure TLS use, still requires TLS 1.2 implementations and says implementations must prefer 1.3 over earlier versions when it is available. A 1.3 client talking to a 1.2-only server falls back to 1.2 through the normal negotiation, and a 1.2 client talking to a 1.3-capable server simply gets 1.2.

So the safe rollout for most teams is:

  1. Keep 1.2 enabled.
  2. Add 1.3.
  3. Remove 1.0 and 1.1 if they are still on.
  4. Watch your error rates for a week.
  5. Revisit whether you still need 1.2 once your client analytics say so.

Watch the middleboxes

The awkward part is rarely the server. Firewalls, proxies and traffic inspectors that are not TLS-aware have broken connections when new versions appeared. During 1.3 development, Mozilla measured higher failure rates for TLS 1.3 than for TLS 1.2 on such networks, and the final protocol was changed so the handshake looks like a resumed 1.2 session to older appliances. The practical lesson: if a corporate customer reports failures after you enable 1.3, suspect their inspection gear first, and keep 1.2 available as the fallback.

Our perspective

We build monitoring and diagnostic tools, and most of the TLS problems we see have little to do with exotic cryptography. They are boring: an old version left on in one load balancer pool, a certificate that expired over a weekend, a CDN edge serving a different chain than the origin, a staging host nobody remembered.

Three habits catch most of it:

  • Check what the public sees, not what your config file says. Test from outside your network, against the real hostname, including every region and subdomain.
  • Treat TLS as a recurring check, not a launch task. Versions, ciphers and certificates drift. Monitoring catches the drift before a customer does.
  • Debug in layers. When a handshake fails, decide first whether it is a version mismatch, a cipher mismatch or a certificate chain issue. Our walkthrough of command line checks for SSL handshake failures follows that order, and the single OpenSSL command for checking a chain covers the most common culprit.

Our view on versions is simple: offer 1.3 and 1.2, turn off everything older, and spend your real effort on cipher choice and renewal automation. The version number is the easy part to fix. The forgotten host is the hard part to find.

— Andreas

How to check which TLS versions your server offers

You do not need special software. OpenSSL, installed on most Linux and macOS machines, can probe each version directly. Replace example.com with your host.

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

A successful handshake prints the negotiated protocol and cipher. A failure on -tls1_1 is what you want to see. Some modern OpenSSL builds refuse to even try the old versions locally, so if the command errors out before connecting, that is your client, not your server. Use a build or a scanner that still supports the legacy probes.

Then go through this list:

  1. Test every public hostname, not just the main domain. APIs, mail gateways and admin panels often run different configs.
  2. Test behind each load balancer and CDN layer separately, if you control them.
  3. Check the certificate itself, including expiry and chain. Our SSL Checker does this in a browser with no install or account.
  4. Inspect response headers such as HSTS, which tells browsers to insist on HTTPS, with the Response Headers Inspector.
  5. Set up ongoing monitoring so a regression does not wait for your next audit.

Putting it into practice with Pingfloat

Pingfloat is a free suite of web tools for developers and IT teams. For TLS work, the SSL Checker is the quickest way to confirm a certificate is valid and its chain is sound, and the Website Uptime Monitor tells you when a site stops answering, which is often the first symptom of an expired certificate or a bad protocol change. If a connection fails somewhere between you and the server, the Traceroute tool helps you see where. Core tools work without installing anything or creating an account. You can browse the rest from the Pingfloat home page.

A migration checklist for deprecated versions

If you have found TLS 1.0 or 1.1 still enabled, here is a low-drama way to remove them.

  1. Measure first. Pull a week or two of protocol statistics from your load balancer, CDN or web server logs. Identify who is still connecting on old versions.
  2. Fix the known cases. Old payment terminals, scripts and partner integrations are the usual suspects. Contact owners with a date.
  3. Disable in staging. Switch off 1.0 and 1.1 and run your integration tests.
  4. Disable in production, one tier at a time. Start with the least critical hostname. Keep a rollback in your change ticket.
  5. Tighten ciphers. Removing old versions is a good moment to remove weak cipher suites from your 1.2 list too. NIST's guidance is explicit that the combination of version and approved cipher suites is what counts.
  6. Document and monitor. Record the decision, and add a recurring check so it stays done.

One warning about legacy protocols beyond the web: EAP-TLS and similar systems built on TLS may need real refactoring, not a config change, to support 1.3, as the IETF draft cited above notes. Budget engineering time for those rather than assuming a toggle.

FAQ

Is TLS 1.0 and 1.1 outdated?

Yes. The IETF deprecated both in RFC 8996 in March 2021 and moved their specifications to Historic status. They lack support for modern cryptographic algorithms, and standards such as PCI DSS prohibit them. Disable them on every public endpoint.

Is TLS 1.2 or 1.3 better?

TLS 1.3 is better. It completes the handshake in one round trip instead of two, removes much of the risky configuration choice and includes downgrade protection. TLS 1.2 remains acceptable when configured with modern ciphers, so there is no emergency, but new deployments should enable 1.3.

Is TLS 1.2 still considered secure?

Yes, with a careful configuration. The UK NCSC says it gives strong protection when set up correctly, though it gets no new features and is not quantum-safe. NIST still lists it as a baseline for US government use, alongside a requirement to support 1.3.

Are TLS 1.2 and 1.3 compatible?

Yes. Servers can enable both, and each connection uses the highest version both sides support. RFC 9325 says implementations must prefer 1.3 when it is available. Clients that only know 1.2 keep working.

Sources