SSL/TLS — Core Concepts

Two Protocols, One Name

You’ll hear SSL and TLS used interchangeably. They’re not the same thing. SSL (Secure Sockets Layer) was developed by Netscape in 1994 and had serious security flaws. TLS (Transport Layer Security) replaced it in 1999. SSL 3.0 was officially deprecated in 2015 after a vulnerability called POODLE made it clear it couldn’t be patched.

When your browser shows that padlock, it’s using TLS. Usually TLS 1.2 or 1.3. Nobody should be using SSL anymore, but the name stuck — which creates endless confusion in documentation, job postings, and conversations with clients.

What the Handshake Is Doing

Before any encrypted data flows between your browser and a server, they negotiate. This is the TLS handshake — a setup phase that establishes shared secrets, verifies identity, and decides which encryption to use. The sequence matters.

In TLS 1.2, a full handshake looks roughly like this:

1. ClientHello — your browser says “I support these TLS versions, these cipher suites, here’s a random number”
2. ServerHello — server picks a cipher suite, sends its certificate, says “here’s my random number”
3. Key Exchange — typically using RSA or Diffie-Hellman; both sides compute a shared secret
4. Finished — both sides confirm they have the same keys by sending encrypted verification messages

This costs 2 round trips before any data moves. On a connection with 80ms latency, that’s 160ms of setup overhead before the first byte of your webpage arrives.

TLS 1.3 (finalized in 2018) cut this to 1 round trip by removing old, insecure cipher suites and streamlining the negotiation. It also added “0-RTT resumption” for returning connections — letting a client send data on the very first packet when reconnecting to a server it’s visited before. This is a meaningful performance win, especially on mobile.

Symmetric vs. Asymmetric Encryption — Why Both?

Asymmetric encryption (like RSA) uses a public key anyone can have and a private key only the server holds. It’s powerful but slow — roughly 1,000 times slower than symmetric encryption on the same hardware.

The handshake uses asymmetric cryptography to solve one specific problem: establishing a shared secret between strangers. Once that shared secret is established, the connection switches to symmetric encryption (typically AES) for all actual data. Symmetric is fast. You get the best of both: the key-exchange security of asymmetric, the throughput of symmetric.

This is why SSL/TLS isn’t just “encrypt everything with the public key.” Encrypting a 4MB image with RSA would be catastrophically slow.

What a Certificate Actually Proves

A TLS certificate contains:

• The server’s public key
• The domain name(s) it’s valid for
• An expiry date
• A digital signature from a Certificate Authority (CA)

That last part is the important one. The CA’s signature is what your browser actually checks. It’s saying: “I, a trusted authority, verified that the entity holding the private key for this certificate controls the domain it claims.”

Your browser ships with a built-in list of ~170 trusted root CAs. If a certificate chains back to one of those roots — either directly or through intermediate CAs — it’s trusted. If not, you get the red warning.

Where This Goes Wrong

Certificate Authorities have been compromised before. In 2011, a Dutch CA called DigiNotar was hacked. The attackers issued fraudulent certificates for Google, Mozilla, and dozens of other sites — meaning they could intercept traffic from anyone whose browser trusted DigiNotar. The CA was removed from all browser trust stores within weeks. DigiNotar went bankrupt shortly after.

This is why Certificate Transparency (CT) logs exist now. Every publicly-trusted certificate must be logged in an append-only public ledger. Your browser can check that a certificate was legitimately issued — and researchers can scan for suspicious or unauthorized certs. It caught a misissuance by Symantec in 2017 that eventually got Symantec’s CA business stripped from them.

Common Misconception: HTTPS Means the Site Is Safe

The padlock means the connection is encrypted and the certificate is valid. It doesn’t mean the site is legitimate or trustworthy.

Phishing sites run on HTTPS. Malware distribution sites run on HTTPS. Let’s Encrypt (which is excellent and important) made getting a certificate free and automatic — which is great for security overall, but it means “has a certificate” no longer signals anything about intent. Don’t confuse transport security with site trustworthiness.

Cipher Suites

A cipher suite is a bundle of algorithms: one for key exchange, one for authentication, one for bulk encryption, one for message integrity. A typical TLS 1.2 cipher suite name looks like:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Breaking this down:

• ECDHE — key exchange using Elliptic Curve Diffie-Hellman Ephemeral
• RSA — server authentication using RSA certificate
• AES_256_GCM — symmetric encryption, 256-bit AES in Galois/Counter Mode
• SHA384 — message integrity using SHA-384

The “Ephemeral” in ECDHE is critical. It means a fresh key pair is generated for each connection. Even if the server’s private key is stolen later, past recorded traffic can’t be decrypted. This property is called forward secrecy, and it’s now considered mandatory for any serious deployment.

One Thing to Remember

The handshake is the hard part. It solves an ancient problem — how do strangers agree on a secret in public? Once that’s done, the rest is just fast symmetric encryption. The certificate is the internet’s way of asking “but can I trust this stranger?” — and the CA is the notary who stamps the answer.

Related topics: Encryption, DNS, APIs