Updated 10 hours ago
Every TLS version exists because the previous one got attacked.
TLS 1.0 fixed SSL 3.0's vulnerabilities. TLS 1.1 fixed TLS 1.0's. TLS 1.2 added modern cryptography. And TLS 1.3? TLS 1.3 wasn't an upgrade—it was an apology. The IETF looked at two decades of accumulated mistakes and said: we're starting over.
Understanding this history isn't academic. It explains why your server configuration matters, why "just enable everything for compatibility" is dangerous, and why the security community spent a decade begging everyone to upgrade.
The Versions
TLS 1.0 (1999): Born from the ashes of SSL 3.0, deployed everywhere throughout the 2000s. Seemed fine at the time.
TLS 1.1 (2006): Fixed specific attacks against TLS 1.0. Almost nobody adopted it—TLS 1.0 was "good enough."
TLS 1.2 (2008): The big upgrade. Added authenticated encryption, removed weak primitives, introduced critical extensions. This is where TLS became genuinely modern.
TLS 1.3 (2018): A ground-up redesign. Removed everything that wasn't provably safe. Faster, simpler, and ruthlessly secure.
What Went Wrong with TLS 1.0 and 1.1
These versions have vulnerabilities with names like BEAST and CRIME—attacks so effective they got marketing. The details matter less than the pattern: old cryptographic designs, given enough time and scrutiny, break.
TLS 1.0 and 1.1 support algorithms now known to be weak: SHA-1, RC4, small key sizes, vulnerable cipher modes. Even with mitigations, you're defending a position that's already been overrun.
Major browsers removed support in 2020. Payment card industry standards prohibit their use. There's no legitimate reason to enable them—any client that only supports TLS 1.0 is too old to safely use the Internet.
The rule is simple: disable TLS 1.0 and 1.1 entirely.
TLS 1.2: Still Standing
TLS 1.2 is the current baseline. It's secure when configured correctly and will likely remain deployed for years.
The catch: TLS 1.2 supports dozens of cipher suites, and many of them are weak. The protocol gives you enough rope to hang yourself. You must explicitly configure strong suites and enable Perfect Forward Secrecy.
Properly configured TLS 1.2 provides security comparable to TLS 1.3. The difference is that TLS 1.2 requires you to know what you're doing, while TLS 1.3 makes it hard to get wrong.
Key extensions in TLS 1.2:
- Server Name Indication (SNI): Allows multiple HTTPS sites on one IP
- ALPN: Enables HTTP/2 negotiation
- Encrypt-then-MAC: Fixes a class of cryptographic vulnerabilities
TLS 1.3: The Reset Button
TLS 1.3 deleted everything that wasn't necessary for security. The result is a protocol that's simultaneously faster and safer.
Only five cipher suites exist. All use authenticated encryption (AES-GCM or ChaCha20-Poly1305). There's no menu of weak options to accidentally enable.
Perfect Forward Secrecy is mandatory. Every connection uses ephemeral key exchange. RSA key exchange—where compromising the server's private key lets you decrypt all past traffic—was removed entirely. This was controversial. It broke compatibility with some corporate surveillance tools. The IETF did it anyway.
Handshakes are faster. One round trip instead of two. For resumed connections, 0-RTT mode sends data immediately (with specific security trade-offs for replay protection).
More of the handshake is encrypted. Server certificates and other metadata are hidden from network observers. This matters for privacy.
TLS 1.3 should be enabled everywhere. It's the best we have.
How Version Negotiation Works
During the handshake, client and server agree on the highest version both support. The client announces its maximum version; the server picks the highest it supports that doesn't exceed that.
With TLS 1.2 and 1.3 enabled, modern clients get TLS 1.3, older clients fall back to TLS 1.2. Everyone gets the best available option.
Downgrade attacks: An attacker might try forcing a weaker version. TLS includes cryptographic protection—the handshake contains unforgeable evidence of the negotiated version, making tampering detectable.
Server Configuration
Most servers make this simple:
Nginx:
Apache:
That's the modern configuration. Enable 1.2 and 1.3, disable everything else.
Who Supports What
TLS 1.3: Chrome 70+ (2018), Firefox 63+ (2018), Safari 12.1+ (2019), all modern mobile browsers. Essentially universal since 2019.
TLS 1.2: Everything from the last decade. IE 11, Chrome 30+, Firefox 27+, Safari 7+. Universal compatibility.
TLS 1.0/1.1: Only required for IE 10 on Windows 7, Android 4.3, Java 6. Clients that are security risks regardless of TLS version.
Supporting only TLS 1.2 and 1.3 is appropriate for essentially all websites in 2025.
Performance
TLS 1.3 is measurably faster. One-round-trip handshakes instead of two. 0-RTT resumption for returning visitors. The difference is most noticeable on high-latency connections.
TLS 1.2 is still fast—modern implementations are heavily optimized. But if you care about performance, TLS 1.3 is strictly better.
Testing Your Configuration
SSL Labs (ssllabs.com): The standard tool. Tests versions, cipher suites, and configuration. Gives you a grade.
Command line:
Verify that TLS 1.2 and 1.3 succeed, and TLS 1.0/1.1 fail.
Compliance Requirements
Most compliance frameworks now require TLS 1.2 minimum:
- PCI DSS: Explicitly prohibits TLS 1.0, requires 1.2+ for payment processing
- HIPAA: Requires "current" encryption, effectively meaning TLS 1.2+
- NIST: Recommends TLS 1.2 minimum, TLS 1.3 preferred
Disabling old versions isn't just good security—it's often legally required.
What's Next
There's no TLS 1.4 in development. TLS 1.3 was comprehensive enough that improvements come through extensions, not new versions.
The current focus: post-quantum cryptography. When quantum computers arrive, they'll break the public-key algorithms TLS relies on. Extensions are being developed to add quantum-resistant algorithms to TLS 1.3, preparing for that future.
The evolution continues within TLS 1.3, not beyond it.
Frequently Asked Questions About TLS Versions
Was this page helpful?