SSL/TLS: Securing the Web

#TL;DR

HTTP sent everything in plaintext. Passwords, credit card numbers, personal messages — all visible to anyone listening on the network. In 1994, Netscape needed to make online commerce possible, so two engineers — Taher Elgamal and Kipp Hickman — designed the Secure Sockets Layer, a protocol that sat between HTTP and TCP and encrypted everything flowing between browser and server. SSL combined RSA’s public-key cryptography for key exchange with fast symmetric encryption for bulk data. The result was transparent: the application thought it was speaking plain TCP, and the network couldn’t read a word. SSL had serious flaws — versions 1.0 through 3.0 were all eventually broken — but its successor, TLS, has been refined through thirty years of attacks and remains the encryption layer for virtually all internet traffic. When you see the padlock in your browser, that’s TLS.

#Plaintext Everywhere

In 1994, the web was completely unencrypted. When you typed a password into a form, it traveled across the internet as readable text. Anyone on the same network — a university sysadmin, an ISP employee, a government wiretap — could read it.

This wasn’t a theoretical risk. Packet sniffing tools like tcpdump had existed since the 1980s. Reading someone’s HTTP traffic was trivially easy:

GET /login?user=alice&password=s3cret HTTP/1.0
Host: shopping.example.com

There it was. Username and password, in the clear, hopping across a dozen routers between the browser and the server. Every router in the path could see it. Every network the packet crossed could copy it.

For sharing physics papers at CERN, this didn’t matter. For buying things with a credit card, it was a dealbreaker. Netscape Communications — the company behind the dominant browser — understood that the web would never become a commercial platform until users could transmit sensitive information safely. No encryption meant no e-commerce. No e-commerce meant no business model for the web.

#Netscape’s Bet

Taher Elgamal, Netscape’s chief scientist, and Kipp Hickman designed SSL in 1994. Elgamal was already a prominent cryptographer — he’d invented the ElGamal encryption scheme in 1985 and had deep expertise in public-key systems. Hickman was a systems engineer who understood the practical constraints of building a protocol that had to work in a shipping product.

Their design goals were specific:

1. Encrypt all traffic between browser and server so eavesdroppers see nothing useful
2. Authenticate the server so users know they’re talking to the real bank, not an impostor
3. Work transparently beneath HTTP — applications shouldn’t need to change
4. Be fast enough for real-time browsing — the encryption overhead can’t make the web feel slow

SSL 1.0 never shipped — it had fundamental flaws found during internal review. SSL 2.0 launched with Netscape Navigator 1.1 in February 1995. It was the first widely deployed encryption on the web.

#The Handshake

SSL’s central mechanism is the handshake — a negotiation at the start of every connection where the client and server agree on how to encrypt their conversation. It solves the classic chicken-and-egg problem: how do two strangers establish a shared secret over an insecure channel?

The answer: use public-key cryptography (slow but secure) to exchange a symmetric key (fast but requires a shared secret), then use that symmetric key for the rest of the conversation.

Client                              Server
  │                                    │
  │──── ClientHello ──────────────────>│  "I support these ciphers and TLS versions"
  │                                    │
  │<─── ServerHello ──────────────────│  "Let's use this cipher"
  │<─── Certificate ──────────────────│  "Here's my public key, signed by a CA"
  │<─── ServerHelloDone ─────────────│  "Your turn"
  │                                    │
  │──── ClientKeyExchange ───────────>│  "Here's a secret, encrypted with your
  │                                    │   public key — only you can read it"
  │──── ChangeCipherSpec ────────────>│  "Switching to encrypted mode"
  │──── Finished (encrypted) ────────>│
  │                                    │
  │<─── ChangeCipherSpec ─────────────│  "Me too"
  │<─── Finished (encrypted) ────────│
  │                                    │
  │═══════ encrypted data ════════════│

After the handshake, both sides hold the same symmetric key — derived from the secret the client sent, encrypted with the server’s public RSA key. From this point on, every byte is encrypted with a fast algorithm like AES. The public-key math happens once. The symmetric encryption handles gigabytes.

This layered approach is why SSL could be practical in 1995 on hardware that was thousands of times slower than today’s. RSA is computationally expensive — you don’t want to encrypt every packet with it. But you only need it once, to exchange a key. Then the fast cipher takes over.

#Certificates: Trust Has to Start Somewhere

Encryption alone doesn’t solve the problem. If you can’t verify who you’re talking to, an attacker could intercept your connection, present their own public key, and decrypt everything — a man-in-the-middle attack.

SSL’s answer was certificates — digital documents that bind a public key to a domain name, signed by a trusted third party called a Certificate Authority (CA):

┌──────────────────────────────────────┐
│            Certificate               │
│                                      │
│  Subject:  shopping.example.com      │
│  Issuer:   DigiCert Global CA        │
│  Valid:    2025-01-01 to 2026-01-01  │
│  Public Key: (RSA 2048-bit)          │
│                                      │
│  Signature: (signed by DigiCert's    │
│              private key)            │
└──────────────────────────────────────┘

The chain of trust works like this:

1. Your browser ships with a set of root CA certificates — about 150 organizations that your OS and browser vendor have vetted
2. When a server presents its certificate, the browser checks: is this certificate signed by a CA I trust? Is the domain correct? Has it expired?
3. If every check passes, the padlock appears. If any check fails, you get the warning screen.

This system has real problems. CAs have been hacked (DigiNotar, 2011), coerced by governments, and caught issuing fraudulent certificates. A compromised CA can sign a fake certificate for any domain in the world. The web’s trust model is only as strong as its weakest CA.

Certificate Transparency (2013) and short-lived certificates (Let’s Encrypt issues for 90 days) are patches on this design. But the fundamental architecture — trust rooted in a small set of authorities — hasn’t changed since SSL 2.0.

#The Parade of Broken Versions

SSL’s history is a timeline of vulnerabilities, each one revealing a deeper flaw:

SSL 2.0 (1995) — launched with Netscape Navigator. Broken almost immediately. It allowed cipher downgrade attacks, had weak MAC construction, and used the same keys for authentication and encryption. Deprecated.

SSL 3.0 (1996) — a ground-up redesign by Elgamal and Paul Kocher (who would later discover speculative execution attacks). Much stronger, but eventually broken by the POODLE attack in 2014, which exploited padding in the CBC cipher mode. Deprecated.

TLS 1.0 (1999) — the IETF took over from Netscape and renamed the protocol Transport Layer Security. Functionally similar to SSL 3.0 with incremental fixes. Vulnerable to BEAST (2011). Deprecated.

TLS 1.1 (2006) — fixed BEAST’s specific attack vector but added little else. Deprecated.

TLS 1.2 (2008) — the first version to support modern authenticated encryption (AEAD ciphers like AES-GCM). Removed weak hash algorithms. Still widely deployed and considered secure with proper configuration.

TLS 1.3 (2018) — a major simplification. Removed all legacy algorithms, reduced the handshake from two round-trips to one, made forward secrecy mandatory. The handshake is faster, the protocol is simpler, and there are far fewer configuration choices to get wrong.

TLS 1.2 handshake: 2 round-trips before data flows
TLS 1.3 handshake: 1 round-trip  before data flows
TLS 1.3 resumption: 0 round-trips (0-RTT, with caveats)

Each broken version taught the same lesson: cryptographic protocols fail not because the math is wrong, but because the engineering around the math creates gaps. Padding oracles, downgrade attacks, implementation bugs — the cipher itself might be unbreakable, but the protocol around it is where attackers find cracks.

#HTTPS: HTTP Over TLS

SSL/TLS sits between HTTP and TCP. The application speaks HTTP exactly as before. The transport layer encrypts everything transparently.

Without TLS:
  Browser ←→ HTTP ←→ TCP ←→ Internet ←→ TCP ←→ HTTP ←→ Server
                      ↑
              everything readable

With TLS:
  Browser ←→ HTTP ←→ TLS ←→ TCP ←→ Internet ←→ TCP ←→ TLS ←→ HTTP ←→ Server
                      ↑                                  ↑
              encrypted here                    decrypted here

The https:// URL scheme tells the browser to perform a TLS handshake before sending any HTTP data. Port 443 instead of port 80. That’s the only visible difference. The HTTP request is identical — but an eavesdropper sees only encrypted bytes.

For years, HTTPS was considered optional — used only for login pages and payment forms. The rest of the web ran on plain HTTP. That changed when Edward Snowden’s 2013 revelations showed that intelligence agencies were conducting mass surveillance of unencrypted internet traffic. The “HTTPS everywhere” movement followed: Google started boosting HTTPS sites in search rankings, browsers began marking HTTP pages as “Not Secure,” and Let’s Encrypt (2015) made certificates free and automated.

Today, over 95% of web traffic is encrypted. HTTPS is the default, not the exception.

#What SSL/TLS Got Right

SSL was broken, patched, renamed, broken again, and rewritten. It’s arguably the most-attacked protocol in computing history. And it won anyway:

• Layered design — by sitting between HTTP and TCP, TLS secured the web without changing either protocol. The same approach now protects email (SMTPS), file transfer (FTPS), database connections, and virtually any TCP-based protocol.
• The hybrid encryption model — using public-key cryptography for key exchange and symmetric encryption for data was the right tradeoff between security and performance. Every secure communication system since, from Signal to WireGuard, uses some variant of this pattern.
• Graceful evolution — the protocol was designed to negotiate versions and cipher suites, so clients and servers could upgrade independently. TLS 1.3 deployments coexist with TLS 1.2 servers. The web upgraded its encryption without a flag day.
• Making security invisible — the padlock icon, the https:// prefix, and the browser warning screen are among the most successful security UX patterns ever designed. Users don’t need to understand Diffie-Hellman or AES-GCM. They look for the padlock.

The biggest lesson from SSL’s history isn’t about cryptography — it’s about engineering humility. Every version shipped with confidence and was broken by researchers who found edge cases the designers missed. TLS 1.3 is the product of thirty years of those lessons: simpler, with fewer options, and less room for misconfiguration. Security doesn’t come from clever design. It comes from surviving attacks.