Chapter 24· 9 min read · illustrated

TLS & HTTPS

How the padlock works: encryption, integrity, and proving who you are talking to

Every time you see the padlock in your browser, TLS is at work. It turns a readable, tamperable connection into a private, verified one. This chapter explains what TLS guarantees and how its handshake sets up secure communication.

Why TLS?

Plain HTTP travels in the clear: anyone between you and the server — on the same WiFi, at an ISP, at a router — can read and even modify it. TLS (Transport Layer Security) wraps the connection so that traffic is private and tamper-evident.

An attacker reading a plain HTTP wire, then a padlock making it unreadable. — Tap to enlarge

HTTPS = HTTP + TLS

HTTPS is not a different protocol — it is simply HTTP running inside a TLS-encrypted connection. The "S" is for Secure. Everything you know about HTTP still applies; TLS just protects it in transit.

An HTTP box wrapped inside a padlocked TLS box. — Tap to enlarge

Three guarantees

Confidentiality: Encryption — eavesdroppers see only scrambled data.
Integrity: Tampering is detected — data cannot be altered undetected.
Authentication: You are really talking to the server you think you are.

Confidentiality, integrity, authentication. — Tap to enlarge

The TLS handshake

Before any data flows, TLS runs a handshake: the client says hello (offering supported ciphers), the server replies with its choice and its certificate, and the two perform a key exchange to agree on a shared secret. From then on, everything is encrypted with that secret.

Client Hello, Server Hello + Certificate, key exchange, shared key derived. — Tap to enlarge

Asymmetric to set up, symmetric to run

TLS uses two kinds of cryptography. Asymmetric (public/private key) crypto is used during the handshake to securely agree on a key — it is secure but slow. Then the actual data is protected with fast symmetric encryption using that one shared key. Best of both worlds.

Asymmetric keys agree a key; symmetric key does the bulk encryption. — Tap to enlarge

Certificates and the chain of trust

How do you know the certificate is genuine? It is signed by a Certificate Authority (CA) that your browser or OS already trusts. That forms a chain of trust: you trust the CA, the CA vouches for the server. This is what stops an attacker from simply presenting their own certificate for example.com.

In practice: Tools like Let’s Encrypt issue these certificates for free, which is why almost the entire web is now HTTPS.

A certificate for example.com signed by a CA the browser trusts. — Tap to enlarge