Chapter 2 · Cryptography· Beginner· ~12 min

TLS & PKI

The protocol that makes "https://" trustworthy, and the global trust system that backs it.

You will learn

  • What TLS actually protects, and what it doesn't
  • What happens in a TLS handshake, in plain terms
  • Why certificates exist and how the browser decides to trust one
  • What goes wrong when TLS is misconfigured or impersonated

What TLS is for

TLS (Transport Layer Security) wraps another protocol, usually HTTP, and gives it three properties:

  • Confidentiality: a network observer can't read the traffic.
  • Integrity: an observer can't modify the traffic undetected.
  • Server authenticity: your client cryptographically verifies it's talking to example.com and not an impostor.

Note what's not on the list: TLS does not prove that the server is honest, that the site is well-built, or that the data inside is safe. It just protects the channel.

The handshake, in plain terms

When you visit https://example.com, your browser and the server perform a quick negotiation before any HTTP bytes are exchanged. In TLS 1.3, the steps look roughly like this:

  1. Your browser sends a ClientHello with a fresh random number, a list of supported algorithms, and a Diffie-Hellman key share (its ephemeral public key).
  2. The server responds with a ServerHello that picks the algorithms and includes its own Diffie-Hellman key share. Both sides can now derive the shared session key.
  3. Under that fresh session key, the server sends its certificate and a signature proving it controls the matching private key.
  4. From here, all application traffic is symmetrically encrypted with AES-GCM or ChaCha20-Poly1305.

The whole exchange takes one round-trip in TLS 1.3, about as fast as setting up an unencrypted connection used to be.

What a certificate is

A certificate is a small file that ties three things together:

  • A public key.
  • A name (or list of names) the key is valid for, e.g. example.com.
  • A signature from a Certificate Authority vouching for the pair.

Your browser ships with a list of root CAs it trusts. When a server presents its certificate, your browser follows the chain of signatures up until it reaches a root it already trusts. If the chain checks out, the name matches the URL, the certificate hasn't expired, and isn't revoked, the connection proceeds.

Free certificates changed the web

Until about 2015, certificates cost money. Let's Encrypt made them free and automated, which is why almost every site is now HTTPS by default. The change is more consequential than it sounds.

How TLS breaks

TLS itself, used correctly, is hard to attack head-on. Most failures live around it:

  • Expired or invalid certificates, which users learn to click through.
  • Mixed content: a page loaded over HTTPS pulling in scripts or images over HTTP.
  • Mis-issued certificates from a compromised or coerced CA. Certificate Transparency logs make these visible quickly.
  • Trusted but malicious roots, often installed by corporate inspection proxies or by malware.
  • Downgrade attacks against very old client/server combinations that still support insecure protocols.

The padlock means "encrypted", not "safe"

A phishing site can serve a perfectly valid certificate for its domain. The padlock confirms you have a secure channel to whoever owns that name, it does not say whether the owner is trustworthy.

Where it lives

Beyond HTTPS, TLS underpins email transport (SMTP STARTTLS), most modern messaging, a lot of database client connections, and VPN protocols like OpenVPN. The same primitives also power QUIC, which is what most of the new internet runs on.

Take the quiz