TLS Through the Ages: SSL → TLS 1.0 → 1.1 → 1.2 → 1.3 Explained in Simple Language

Hey everyone, Alex here. Every time you see a padlock in your browser, something called TLS is quietly protecting your data. But TLS has gone through several major versions over the years — and the differences matter a lot for security. Today we break it all down, in plain language, with visual guides. Let's go.

🔒 What is TLS (and what happened to SSL)?

TLS stands for Transport Layer Security. Its job is to create an encrypted tunnel between your browser and a web server — so that hackers sitting on the same network can't read your passwords, messages, or credit card numbers.

You've probably heard the term SSL too. SSL (Secure Sockets Layer) was TLS's predecessor. Technically, SSL is dead — but the nickname stuck, which is why you still see "SSL certificate" everywhere even though actual SSL hasn't been used in decades.

Here's the full version history at a glance:

███ TLS / SSL VERSION TIMELINE ███ 💀 SSL 2.0 (1995) ► Born with major flaws, quickly abandoned 💀 SSL 3.0 (1996) ► Killed by the POODLE attack in 2014 🚫 TLS 1.0 (1999) ► Deprecated 2021 — no longer acceptable 🚫 TLS 1.1 (2006) ► Deprecated 2021 — only minor fixes over 1.0 ✅ TLS 1.2 (2008) ► Still widely used and supported 🏆 TLS 1.3 (2018) ► The gold standard — fastest and most secure

🐂 SSL 2.0 & SSL 3.0 — The Dinosaurs (1995–1996)

💀 DEAD — DO NOT USE

SSL 2.0 (1995)

The first public attempt at securing web traffic, created by Netscape. It had serious structural problems: it was possible for attackers to strip away the protection entirely (a "downgrade attack"), and it reused the same key for authentication and encryption — a big no-no in security design.

It was replaced almost immediately by SSL 3.0 and is now completely banned by RFC 6176.

SSL 3.0 (1996)

A complete redesign from scratch. Much better than SSL 2.0, and it dominated the internet for nearly 20 years. But in 2014, Google researchers discovered the POODLE attack (Padding Oracle On Downgraded Legacy Encryption) which could decrypt supposedly-secure cookies.

⚠ The POODLE Attack (2014): By forcing the browser to fall back to SSL 3.0 and then exploiting a flaw in how it handles data padding, an attacker on the same network could decrypt your session cookies — and hijack your accounts. SSL 3.0 was officially killed.

The handshake looked like this:

1Client Hello — Browser says "Hello! I support these cipher suites."
2Server Hello — Server picks a cipher suite and sends its certificate.
3Key Exchange — Browser and server agree on a shared secret using RSA (browser encrypts a random value with server's public key).
4Finished — Both sides confirm they can communicate. Data starts flowing.

The problem? Step 3 used RSA key exchange exclusively — meaning if someone recorded your traffic and later got the server's private key, they could decrypt everything retroactively. This is called lacking Forward Secrecy.

⛔ TLS 1.0 — The First "Modern" Attempt (1999)

🚫 DEPRECATED 2021

TLS 1.0 was essentially SSL 3.0 with fixes. It moved the design into a proper IETF standard (RFC 2246), which was a big step for interoperability. But its fundamental architecture still had weaknesses that would come to haunt it.

What was new:

  • Standardized under the IETF (making it a proper open internet standard, not just Netscape's protocol)
  • Cleaner MAC (Message Authentication Code) design
  • Better separation between authentication and encryption

What was still broken:

  • Still supported weak ciphers like RC4 and export-grade encryption
  • Still vulnerable to BEAST attack (Browser Exploit Against SSL/TLS), discovered in 2011
  • Used CBC (Cipher Block Chaining) mode without proper initialization vectors
⚠ The BEAST Attack (2011): Researchers Duong and Rizzo showed that an attacker who could inject JavaScript into the browser could exploit the way TLS 1.0 handled CBC encryption to decrypt HTTPS cookies. The attack required the attacker to be in a privileged network position, but it was real enough to force the industry to move on.

🔵 TLS 1.1 — A Patch Job (2006)

🚫 DEPRECATED 2021

TLS 1.1 was basically a security patch for TLS 1.0. It addressed the BEAST vulnerability by adding explicit Initialization Vectors (IVs) to CBC cipher blocks — but it didn't do much else. It's widely regarded as a transitional version that was quickly overshadowed by TLS 1.2.

What changed from TLS 1.0:

  • Explicit IVs for CBC: Each encrypted record now includes its own initialization vector, preventing the BEAST-style attack
  • Better alert handling: Cleaner error codes for padding failures, reducing information leakage
  • Protection against POODLE-style downgrade: Added mechanisms to prevent falling back to SSL 3.0
💡 Why TLS 1.1 barely matters: Most servers skipped from TLS 1.0 directly to TLS 1.2. TLS 1.1 was in the standard but adoption was thin — it was deprecated at the same time as TLS 1.0, in 2021 (RFC 8996).

✅ TLS 1.2 — The Workhorse (2008)

✅ STILL SUPPORTED

TLS 1.2 was a major overhaul. It dropped the old, broken parts and added modern cryptographic flexibility. For most of the 2010s, TLS 1.2 was the gold standard — and it's still widely deployed today.

Key improvements:

  • SHA-256 by default: Replaced the outdated MD5/SHA-1 combo with SHA-256 for integrity checking
  • AEAD ciphers supported: Added support for AES-GCM (Galois/Counter Mode) — a modern authenticated encryption scheme that prevents tampering
  • Configurable PRF: The Pseudo-Random Function used to derive session keys became configurable (using SHA-256 by default)
  • Removed weak legacy ciphers from the mandatory list
  • Cipher suite agility: Server and client can negotiate the best available algorithm from a large menu

The TLS 1.2 Handshake (simplified):

1Client Hello — "I support these cipher suites and TLS versions. Here's a random number."
2Server Hello — "I pick AES-256-GCM-SHA384. Here's my certificate and another random number."
3Key Exchange — Client verifies the certificate. Both parties run a key exchange (RSA or Diffie-Hellman) to agree on a master secret.
4Change Cipher Spec — Both parties signal they're switching to encrypted mode.
5Finished — Both sides send a hash of the entire handshake to confirm nothing was tampered with. Encrypted data starts flowing.

This handshake takes 2 round-trips before data can flow — meaning there's a latency cost each time a new connection is opened.

💡 The FREAK, LOGJAM, and DROWN problems: Even TLS 1.2 wasn't immune to misconfiguration attacks. If servers were configured to still support old "export-grade" ciphers (a relic of 1990s US encryption export laws), attackers could force a downgrade. The lesson: a good protocol can be weakened by bad configuration.

🏆 TLS 1.3 — The Modern Gold Standard (2018)

🏆 RECOMMENDED

TLS 1.3 (RFC 8446) was a ground-up redesign. The IETF took ten years of painful lessons and built something cleaner, faster, and far more secure. It's not just an incremental improvement — it's a fundamentally different approach.

What TLS 1.3 removed entirely:

  • RSA key exchange (goodbye to the "decrypt later" problem)
  • All CBC-mode cipher suites
  • RC4, DES, 3DES, MD5, SHA-1
  • Export-grade ciphers
  • Compression (which was exploited by the CRIME attack)
  • Renegotiation (a feature that was repeatedly exploited)

What TLS 1.3 requires:

  • Only 5 cipher suites are allowed, all modern AEAD ciphers
  • Only ephemeral Diffie-Hellman key exchange (ensures Perfect Forward Secrecy by default)
  • Only three key exchange groups: X25519, P-256, P-384

The TLS 1.3 Handshake (simplified):

1Client Hello — "I support TLS 1.3. Here's my DH key share and supported groups."
2Server Hello + Encrypted Extensions + Certificate + Finished — Server responds with its DH key share, certificate (now encrypted!), and a Finished message — all in one shot.
3Client Finished — Client sends its Finished message. Encrypted data can flow immediately.

That's just 1 round-trip instead of 2! For a web page with many connections, this noticeably reduces latency.

0-RTT (Zero Round-Trip) Mode: For returning visitors, TLS 1.3 supports resuming a previous session with zero round-trips — data is sent in the very first message. This is blazing fast but comes with a caveat: it's susceptible to replay attacks, so it should only be used for non-sensitive, idempotent requests.

🔒 Why Perfect Forward Secrecy (PFS) matters: In older TLS versions using RSA key exchange, a passive attacker could record all your encrypted traffic and wait years. If they later obtained the server's private key (through hacking, legal pressure, or a key breach), they could decrypt everything retroactively. TLS 1.3 uses ephemeral Diffie-Hellman, which generates a fresh key pair for every session — those keys are never stored, so past sessions can never be decrypted even if the server is completely compromised.

📊 Side-by-Side Comparison

Feature SSL 3.0 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Year 1996 1999 2006 2008 2018
Status 💀 Dead 🚫 Deprecated 🚫 Deprecated ✅ OK 🏆 Best
Handshake RTTs 2 2 2 2 1 (or 0)
Forward Secrecy ❌ No ❌ Optional ❌ Optional ✔ Optional ✔ Mandatory
RC4 Support ✔ Yes ✔ Yes ✔ Yes ✔ Allowed ❌ Removed
SHA-256 PRF ❌ No ❌ No ❌ No ✔ Yes ✔ Yes (HKDF)
AEAD Ciphers ❌ No ❌ No ❌ No ✔ Supported ✔ Mandatory
Encrypted Cert ❌ No ❌ No ❌ No ❌ No ✔ Yes
Known Attacks POODLE, more BEAST, POODLE POODLE (via downgrade) FREAK, LOGJAM (config) None known

🔒 The Handshake Speed Comparison

HANDSHAKE LATENCY COMPARISON (simplified) TLS 1.2 (full) [Client]---Hello--->[Server] <---Hello + Cert--- ---Key Exchange---> <---Finished------ = 2 round trips before first byte of data TLS 1.3 (full) [Client]---Hello + Key Share--->[Server] <---Hello + Cert (encrypted!) + Finished--- = 1 round trip before first byte of data (2x faster!) TLS 1.3 (0-RTT) [Client]---Hello + Early Data--->[Server] = Data sent immediately (for returning sessions)

🎯 What Does This Mean for You?

If you run a website or server:
  • Disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 immediately if you haven't already
  • Ensure TLS 1.2 is configured with strong cipher suites only (AES-GCM, CHACHA20, no RC4)
  • Enable TLS 1.3 — all modern web servers (Nginx, Apache, IIS) support it
  • Use a tool like SSL Labs (ssllabs.com/ssltest) to audit your server
If you're a developer or engineer:
  • Never hardcode TLS versions in your HTTP clients — use the system defaults which will track OS/library updates
  • If you must specify a version, use TLS 1.2 as minimum
  • Prefer libraries that support TLS 1.3 (OpenSSL 1.1.1+, Go's crypto/tls, Node.js v12+)
If you're just a regular internet user:
  • Keep your browser updated — Chrome, Firefox, Safari, and Edge all enable TLS 1.3 by default
  • Avoid using very old browsers or operating systems (Windows XP, IE8) on sensitive websites
  • The padlock icon means TLS is active — but it doesn't tell you which version. Modern browsers will warn you if a site uses TLS 1.0 or 1.1

💡 The Big Picture: What Changed Over 30 Years

SSL 3.0
Broken design, no forward secrecy, weak ciphers
💀 DEAD
TLS 1.0
First standard, BEAST vulnerability, CBC issues
🚫 DEPRECATED
TLS 1.1
BEAST fix, but little else changed
🚫 DEPRECATED
TLS 1.2
Modern ciphers, SHA-256, optional PFS
✅ SUPPORTED
TLS 1.3
1-RTT, mandatory PFS, encrypted certs, no weak ciphers
🏆 BEST

📄 TL;DR

SSL was the original internet encryption protocol, riddled with flaws. TLS 1.0 and 1.1 tried to patch the holes but couldn't escape the fundamental architectural debt. TLS 1.2 was a genuine overhaul that served us well for a decade. TLS 1.3 is the clean-room redesign that strips everything broken and keeps only what works — it's faster, simpler, and dramatically more secure.

If you're building anything that touches the internet: require TLS 1.2 at minimum, prefer TLS 1.3, and never look back.

If you found this useful, share it with a teammate who's still running TLS 1.0 in production. You know who they are. 😄

— Alex R. | Coding with Alex | sysseder.com

Comments

Popular posts from this blog

בדיחות רופאים, עורכי דין ואנשי טכ

קריקטורה: טראמפ ואיראן - עסקה או לא?

בדיחות שבת משפחתיות