🕰️ 09-01: TLS History and Versions¶
📌 What TLS/SSL Actually Guarantees¶
TLS (Transport Layer Security) is a protocol that provides a secure channel between two communicating applications — most commonly a browser and a web server, but really any two applications that talk over a network. "Secure channel" isn't a vague marketing phrase; it means three specific, well-defined properties:
- Confidentiality — nobody other than the two ends of the channel can see the actual content of the data being transmitted.
- Integrity — the channel can detect any changes made to the data during transmission; tampering doesn't go unnoticed.
- Authentication — at least one end of the channel (almost always the server) is cryptographically verified, so the other end knows who it's actually talking to.
TLS is designed to run on top of TCP, sitting between the transport layer and the application layer: the application layer hands TLS unprotected (plaintext) data, TLS encrypts it and adds integrity checks, and then hands the protected result down to TCP for delivery. (TLS can also be adapted to run over other transports like UDP — that variant is called DTLS — but the TCP case is by far the most common.)
💡 Every one of the three properties matters independently. Confidentiality without integrity means an attacker can't read your traffic but might still be able to flip bits in it undetected. Integrity without authentication means you'd know if data was tampered with, but you'd have no way to know if you're even talking to the right server in the first place. TLS is designed to give you all three together.
🧬 SSL to TLS: A Brief Lineage¶
TLS didn't appear from nothing — it evolved from an earlier protocol called SSL (Secure Sockets Layer), originally developed by Netscape in the 1990s. The version history looks like this:
| Version | Status Today | Notes |
|---|---|---|
| SSL 2.0 | Deprecated / insecure | The original public release; had serious design flaws |
| SSL 3.0 | Deprecated / insecure | Fixed some SSL 2.0 issues, but later broken by the POODLE attack (see 09-05: Common TLS Attacks); officially deprecated by the IETF in June 2015 |
| TLS 1.0 | Deprecated | Essentially "SSL 3.1" when it was standardized — when SSL was handed to the IETF for standardization, it was renamed TLS. Shares enough of SSL 3.0's structure to inherit some of its weaknesses |
| TLS 1.1 | Deprecated | Incremental hardening over 1.0; still eventually retired industry-wide |
| TLS 1.2 | Still widely used, considered secure when configured well | Major, long-lived version; added stronger hashing and cipher options |
| TLS 1.3 | Current standard, recommended | Significant structural redesign — faster handshake, legacy weak options removed entirely |
💡 A useful way to remember the relationship: TLS is SSL's successor, under a new name. When people casually say "SSL certificate" or "SSL connection" today, they almost always actually mean TLS — the SSL branding just stuck around in common usage long after the protocol itself moved on.
⚠️ Why the Old Versions Were Deprecated¶
Deprecating a widely deployed protocol is disruptive, so it only happens when the alternative — staying on the old version — is worse. Each retirement was driven by discovered weaknesses, at a conceptual level:
- SSL 2.0 had fundamental design flaws: weak integrity protection, no protection against certain handshake manipulation, and cryptographic choices considered weak even by the standards of its time.
- SSL 3.0 remained usable for years but was ultimately broken by POODLE, an attack exploiting how it handled block cipher padding, allowing attackers to gradually decrypt parts of supposedly protected traffic (conceptual details in 09-05: Common TLS Attacks).
- TLS 1.0 / 1.1 inherited some structural weaknesses from the SSL lineage (including exposure to padding-oracle-style issues like BEAST) and only supported older, now-considered-weak cryptographic algorithms. Major browsers and standards bodies formally deprecated both around 2020.
The common thread: as cryptanalysis techniques and computing power improve over decades, algorithms and protocol behaviors that once seemed sound get reevaluated, and weaknesses that were once theoretical become practical. Protocol versions get retired not because they suddenly changed, but because the world's understanding of their weaknesses caught up to them.
💡 This is also why "beginner-friendly" security advice so often boils down to "keep things updated." A protocol version considered fine in 2010 can be actively dangerous in 2026 — not because it changed, but because attackers' tools and knowledge did.
🚀 What Changed Structurally in TLS 1.3¶
TLS 1.3 (finalized in 2018) isn't just "TLS 1.2 with a few patches" — it's a deliberate structural redesign, motivated by lessons learned from years of attacks against earlier versions. The headline changes:
Faster Handshake¶
Earlier versions (TLS 1.2 and before) required multiple round trips between client and server before any application data could be sent, because the handshake negotiated cryptographic parameters step by step (see the full walkthrough in 09-02: The TLS Handshake). TLS 1.3 redesigned the handshake to typically need only one round trip (and introduced an even faster "0-RTT" resumption mode for returning connections), meaning secure connections establish noticeably faster — which matters enormously at Internet scale.
Removed Insecure/Legacy Options¶
TLS 1.3 doesn't just recommend against weak ciphers — it removes support for them entirely, so there's no way to accidentally (or maliciously, via a downgrade attack) negotiate a known-weak option. Gone from TLS 1.3:
- Static RSA key exchange (which didn't provide forward secrecy — if the server's private key was ever compromised, all past recorded traffic could be decrypted retroactively)
- Older, weaker hash algorithms used in the handshake
- RC4 and other weak bulk ciphers
- Compression at the TLS layer (which had enabled certain attacks)
Mandatory Forward Secrecy¶
Every TLS 1.3 handshake now uses a Diffie-Hellman-style key exchange (see 07-05: Diffie-Hellman Key Exchange) to derive session keys, rather than allowing the older approach of encrypting a secret directly with the server's public key. This guarantees forward secrecy on every connection: even if a server's long-term private key is later stolen, previously captured traffic can't be decrypted, because the session keys were never derivable from that long-term key alone.
💡 Think of the TLS 1.3 redesign philosophy as "stop offering the footguns." Instead of trusting administrators to correctly configure away every weak option, the protocol itself no longer supports them.
📌 Key Takeaways¶
- TLS provides three guarantees: confidentiality, integrity, and authentication — all three matter, and none can substitute for the others.
- TLS is the renamed, standardized successor to SSL; "SSL" in casual usage today almost always means TLS.
- Version history: SSL 2.0 → SSL 3.0 → TLS 1.0 → TLS 1.1 → TLS 1.2 → TLS 1.3, with everything before TLS 1.2 now deprecated.
- Old versions were deprecated because of discovered weaknesses (e.g., POODLE against SSL 3.0, BEAST-related issues in TLS 1.0), not because the protocols changed after the fact.
- TLS 1.3's handshake needs far fewer round trips than TLS 1.2, making secure connections noticeably faster to establish.
- TLS 1.3 removes weak/legacy cryptographic options entirely rather than just discouraging them, closing off downgrade-attack surface.
- TLS 1.3 mandates Diffie-Hellman-style key exchange on every connection, guaranteeing forward secrecy by default.
- For the detailed step-by-step handshake mechanics (both TLS 1.2 and 1.3), see 09-02: The TLS Handshake.