5.7 — TLS: What the Padlock Actually Means

Everything in Part 5 so far is readable by anyone on the path. A packet crosses fifteen machines (Chapter 5.3.2), and at every one of them the HTTP request is plain text — the URL, the headers, the cookie holding your session, the password in the form body.

On a café's Wi-Fi that means anyone with a laptop. At an ISP it means the operator. In a country with intercepting infrastructure it means the state.

TLS (transport layer security) is the layer that fixes this, and the padlock in the address bar asserts three things — precisely three, and knowing which three matters, because people routinely believe it asserts a fourth.

1. What the padlock claims, and what it does not

Confidentiality. Anyone on the path sees ciphertext. They still learn the destination IP, the rough timing and the size of the traffic, and — unless encrypted client hello is in use — the hostname you asked for, because of the SNI field in section 5.

Integrity. If a single bit is altered in transit, the receiver detects it and the connection fails. This matters more than people expect: without it, an ISP could inject advertising into pages, and some did, in the era before HTTPS was universal.

Authentication of the server. You are talking to the machine that holds the private key for example.com, and not to an impostor.

What it does not claim, and this is the common misunderstanding:

• Not that the site is honest. paypal-security-alert.com can hold a perfectly valid certificate. The padlock says the connection is to the site named in the address bar; it says nothing about whether that site deserves your money.
• Not that the server is secure. The certificate says nothing about the code running behind it.
• Not that the client is authenticated, unless mutual TLS is configured (section 7), which is rare on the public web.

Browsers removed the word "Secure" from the address bar for exactly this reason. Users read it as "this site is safe" when it means "this connection is private". The padlock is now barely visible, and an insecure connection is what gets a warning — the default was inverted, which is the right way round.

2. The three problems that need three different mechanisms

Encryption alone solves none of this on its own. There are three separate problems and three separate tools.

Problem one: how do two strangers agree on a secret key over a channel everyone can read? This is key exchange, and it is solved by asymmetric cryptography — Diffie-Hellman.

Problem two: how do you encrypt megabytes efficiently once you have a key? Asymmetric cryptography is far too slow for bulk data. This is solved by symmetric encryption — AES, ChaCha20.

Problem three: how do you know the key you agreed on belongs to the right party and not to an attacker sitting in the middle? This is authentication, and it is solved by certificates and the trust hierarchy in section 4.

All three are needed, and dropping any one breaks everything. Key exchange without authentication gives you a perfectly encrypted conversation with an attacker. Authentication without encryption tells you who you are talking to while everyone reads along. Chapter 8.2 develops the cryptography properly; this page is how TLS composes the three.

3. Diffie-Hellman: agreeing on a secret in public

This is the idea that makes the whole thing possible, and the paint analogy captures it exactly.

You and I each pick a secret colour and keep it hidden. We publicly agree on a common colour — everyone sees it. Each of us mixes our secret into the common colour and sends the mixture across; anyone watching sees both mixtures. Each of us then mixes our own secret into the mixture we received.

We both end up with the same three-colour blend. An eavesdropper has the common colour and both two-colour mixtures, and cannot produce the three-colour blend, because unmixing paint is hard.

The mathematics is modular exponentiation, which has the same one-way property. Both sides agree on a large prime p and a generator g, publicly. Alice picks a secret a and sends g^a \bmod p; Bob picks b and sends g^b \bmod p. Alice computes (g^b)^a, Bob computes (g^a)^b, and both equal g^{ab} \bmod p.

An eavesdropper has g, p, g^a and g^b, and to get g^{ab} must recover a or b — the discrete logarithm problem, with no known efficient classical algorithm. Modern TLS uses the elliptic-curve variant (ECDHE), which achieves the same security with much smaller numbers and less computation.

The E at the end matters more than the rest of the acronym. ECDHE is ephemeral: a fresh key pair for every single connection, discarded afterwards. That gives forward secrecy — if the server's long-term private key is stolen tomorrow, an attacker who recorded today's traffic still cannot decrypt it, because the key that encrypted it was thrown away and was never derivable from the long-term key.

Before forward secrecy, the model was catastrophic: the client encrypted a random secret with the server's public key, so anyone recording traffic for years and later obtaining that one private key could decrypt all of it retroactively. TLS 1.3 removed the non-forward-secret options entirely. "Record now, decrypt later" is a real adversary model for state actors, and forward secrecy is the direct answer to it.

4. Certificates: why you believe a stranger's key

Diffie-Hellman gives you a shared secret with somebody. Nothing so far says who.

Without authentication, an attacker in the middle simply runs two exchanges — one with you, one with the real server — decrypting and re-encrypting between them. Both ends see a padlock. This is why a certificate exists.

A certificate is a public key plus identity information, signed by someone the browser already trusts.

Subject:      CN=example.com, SAN: example.com, www.example.com
Issuer:       CN=R11, O=Let's Encrypt
Validity:     2026-06-01 to 2026-08-30
Public Key:   (the server's, 256-bit ECDSA)
Signature:    (the issuer's signature over everything above)

Read the signature line as the whole point. A certificate authority has cryptographically asserted: "I checked that this key belongs to whoever controls example.com." Your browser trusts the CA, so it accepts the assertion.

The chain, and why it exists. Browsers do not trust example.com's certificate directly. They ship a root store of a few hundred root CA certificates, baked into the operating system or browser. Those roots sign intermediate certificates, which sign leaf certificates like the one above.

Root CA (in your browser's trust store, offline, valid ~20 years)
   └── signs → Intermediate CA (online, valid ~5 years)
                  └── signs → example.com (valid ~90 days)

Why not sign leaves with the root directly? Because the root's private key is the crown jewels — if it leaks, every certificate it ever signed becomes suspect and there is no way to revoke a root that is already burned into a billion devices. So roots are kept offline in physical hardware security modules, brought out ceremonially a few times a year, and used only to sign intermediates. An intermediate that is compromised can be revoked; a root cannot.

Validation is a chain walk. The server sends its leaf plus the intermediates. The browser verifies each signature up the chain until it reaches a certificate in its trust store, then checks the leaf: is the hostname in the Subject Alternative Name list, is it within its validity dates, is it revoked?

A very common production failure is a missing intermediate. The server sends only its leaf. The browser has the root but not the intermediate, so the chain is broken. It frequently appears to work in a browser — because some browsers fetch the missing intermediate or cache it from another site — and fails in curl, in mobile apps and in server-to-server calls. "It works in Chrome but our API client rejects it" is almost always this, and openssl s_client -connect host:443 -showcerts shows the chain the server actually sent.

Three validation levels, and the honest verdict:

• DV (domain validated) — proves control of the domain. Automated, free, issued in seconds.
• OV (organisation validated) — some checking of the company.
• EV (extended validation) — heavy vetting, and it used to display the company name in green in the address bar.

Browsers removed the EV indicator, because research showed users did not notice it and it could be gamed by registering a similarly named company. DV via Let's Encrypt is now the right default for essentially everything, and the argument that EV provides meaningful additional user protection did not survive contact with evidence.

Revocation is the weak part of the whole system, and it is worth being honest about. CRLs (large downloaded lists) do not scale. OCSP (asking the CA in real time) leaks browsing behaviour to the CA and adds latency, so browsers made it soft-fail — a failed check is ignored — which means an attacker who can block OCSP defeats it entirely. OCSP stapling improves this by having the server attach a recent signed status, which is the right configuration to enable. The pragmatic answer the industry converged on is short certificate lifetimes: 90-day certificates, moving toward 47 days, so a compromised certificate expires on its own rather than needing revocation to work.

5. The handshake, and what changed in TLS 1.3

TLS 1.2 needed two round trips before any application data: client hello, server hello with the certificate, client key exchange, both sides confirm, then data.

TLS 1.3 (RFC 8446, 2018) reduced it to one, and the trick is that the client guesses. It sends its Diffie-Hellman key share in the very first message, betting on which algorithm the server will pick. Usually right, so the server can complete the exchange and reply already encrypted.

TLS 1.3 in one round trip. Note that the certificate arrives encrypted — from step 2 onward everything is protected, so an observer cannot even see which certificate was presented.

Step 1 — ClientHello. Supported versions, cipher suites, a random value, a Diffie-Hellman key share, and SNI.

SNI (server name indication) deserves its own paragraph, because it is the chicken-and-egg from Chapter 5.6.1. The Host header is inside the encrypted request, but the server must choose which certificate to present before encryption exists. SNI puts the hostname in the ClientHello in plain text, so the server can pick. That means the hostname you are visiting is visible to anyone on the path even over HTTPS — it is how corporate filters and national firewalls block individual sites without decrypting anything. Encrypted Client Hello is the fix, encrypting the ClientHello itself using a key published in DNS, and it is deploying now.

Step 2 — ServerHello. The server's key share, then — already encrypted — its certificate chain, a signature proving it holds the matching private key, and a Finished message.

The signature is what stops replay. A certificate is public; anyone can copy it. The signature is over the handshake transcript including the client's random value, so it proves possession of the private key for this specific connection.

Step 3 — client verifies and sends data. Chain validation, hostname check, dates, then application data.

What else TLS 1.3 removed, and why the removals are the real story:

• RSA key exchange — no forward secrecy.
• Static Diffie-Hellman — same reason.
• CBC mode ciphers — a decade of padding-oracle attacks (BEAST, Lucky13, POODLE).
• RC4 — broken.
• Compression — the CRIME attack, the same size-side-channel idea as BREACH in Chapter 5.6.2.
• Renegotiation — repeatedly exploitable.
• MD5 and SHA-1 signatures — collidable.

TLS 1.3 is defined more by what it deleted than what it added. Every removal closed an attack that had shipped. The remaining cipher suites number five instead of dozens, which means far fewer ways to configure it insecurely — a design lesson that generalises: reducing the configuration surface eliminates whole classes of misconfiguration.

Session resumption and 0-RTT. A returning client can present a ticket from a previous session and skip the key exchange entirely, sending application data in its first flight — zero round trips. The caveat from Chapter 5.4.3 applies: 0-RTT data is replayable, so it must carry only idempotent requests.

6. What is encrypted and what leaks

Worth being exact, because people over-claim in both directions.

Encrypted: the URL path and query string, all headers including cookies and authorisation, the request and response bodies, and — from TLS 1.3 step 2 onward — the server's certificate.

Visible to an observer:

• The destination IP address. Unavoidable; routing needs it.
• The hostname via SNI, unless Encrypted Client Hello is in use.
• The DNS lookup, unless DoH or DoT is in use (Chapter 5.5).
• Traffic timing and volume. Enough for traffic analysis — research has repeatedly shown that the sizes and timings of encrypted requests can identify which page on a known site was visited.

The practical rule for engineers: do not put secrets in a URL. The path is encrypted in transit, and it is also written to your access logs, the proxy's logs, the CDN's logs, the browser's history, and the Referer header sent to any third-party resource on the page. TLS protects the wire and nothing else. A token in a query string is a token in a dozen log files.

7. Mutual TLS, and where it belongs

Normally only the server presents a certificate. mTLS has the client present one too, and the server verifies it against its own trust store.

This is not for the public web — you cannot issue certificates to arbitrary users. It is for service-to-service authentication inside a system: each service holds a certificate, and every connection proves both identities cryptographically before any application-level authentication happens.

The advantages over API keys or bearer tokens: nothing shared is transmitted (the private key never leaves the machine), identity is bound to the certificate rather than to a copyable string, and revocation and rotation are handled by the same certificate machinery.

The cost is real: you must run a certificate authority, distribute certificates to every service, and rotate them before expiry. An expired internal certificate takes a service down completely, and it is one of the more common self-inflicted outages. Chapter 8.6 compares mTLS against the alternatives, and Chapter 8.3 covers the certificate file formats.

8. Configuration that matters in practice

Enable HTTP/2 and HTTP/3. Both require TLS in every browser implementation, so TLS is now a prerequisite for the performance features rather than a tax on them.

HSTS. Strict-Transport-Security: max-age=31536000; includeSubDomains tells the browser to use HTTPS for this domain for the next year, converting plain-HTTP requests to HTTPS before they leave the machine. This closes the gap where a user types example.com, gets a plain-HTTP request, and an attacker intercepts the redirect — the SSL stripping attack. The HSTS preload list goes further, shipping the rule inside browsers so even the first visit is protected. Note that includeSubDomains plus preload is very hard to undo, so enable it deliberately.

Redirect HTTP to HTTPS, and set HSTS on the HTTPS response — a header on the HTTP response would itself be interceptable.

Automate renewal. With 90-day certificates, manual renewal is a guaranteed future outage. ACME clients handle it; the expired-certificate incident is entirely avoidable and still happens to large companies every year.

Enable OCSP stapling, and set CAA records in DNS (Chapter 5.5) naming which authorities may issue for your domain — a cheap defence against a mis-issued certificate.

Terminate TLS at the edge, and decide what happens behind it. A load balancer usually decrypts so it can route on the path (the layer-7 behaviour from Chapter 5.1). Whether traffic is re-encrypted to the backend is a real decision: inside a trusted private network many people leave it plain, and a zero-trust posture re-encrypts or uses mTLS. Chapter 5.10 covers where this sits in a cloud network.

What the interviewer will push on

"What does the padlock guarantee?" Confidentiality, integrity, and server authentication. Not that the site is trustworthy — a phishing domain can hold a valid certificate. Naming what it does not claim is what the question is really testing.

"Walk me through the handshake." ClientHello with a key share and SNI; ServerHello with its key share, then an encrypted certificate and signature; client validates the chain and sends data. One round trip in TLS 1.3, two in 1.2. The tell is knowing the client guesses the algorithm to save a round trip, and that the certificate arrives encrypted.

"What is forward secrecy and why does it matter?" Ephemeral keys per connection, discarded afterwards, so stealing the server's long-term key does not decrypt recorded past traffic. It matters because "record now, decrypt later" is a real adversary model, and it is why TLS 1.3 removed RSA key exchange entirely.

"Why is there a certificate chain rather than direct signing?" The root's private key cannot be revoked once it is in a billion trust stores, so it stays offline and signs only intermediates, which can be revoked. Then volunteer the missing-intermediate failure — works in Chrome, fails in curl — because it is the one you will actually debug.

"Is the URL encrypted?" Yes on the wire. But the hostname leaks via SNI, the DNS lookup leaks unless DoH is used, and the path is written to logs, browser history and the Referer header. So never put a token in a URL — TLS protects the wire and nothing else.

"What is SNI and what problem did it create?" It puts the hostname in plain text in the ClientHello so a server can pick a certificate before encryption exists. The problem it created is that it makes per-site blocking and monitoring trivial over HTTPS, which is what Encrypted Client Hello addresses.

"When would you use mTLS?" Service-to-service inside a system, where you control both ends and can run a CA. Not for public users. Then name the operational cost honestly: an expired internal certificate is a total outage, so rotation must be automated.

One thing to volunteer: point out that TLS 1.3's main achievement is subtraction — removing RSA key exchange, CBC, RC4, compression and renegotiation, each of which had shipped exploits. Reducing the configuration surface eliminated whole classes of misconfiguration, and that is a design principle worth naming beyond cryptography.

Recall

• The padlock asserts confidentiality, integrity and server authentication — not that the site is honest, not that the server is secure, not that the client is authenticated.
• Three problems, three tools: key exchange (Diffie-Hellman) agrees a secret in public, symmetric encryption does the bulk work, and certificates answer who you agreed it with. Drop authentication and you get a perfectly encrypted channel to an attacker.
• ECDHE is ephemeral, giving forward secrecy: a stolen long-term key cannot decrypt recorded past traffic. TLS 1.3 removed every non-forward-secret option.
• A certificate is a public key plus identity, signed by a trusted certificate authority. The chain exists because a root key cannot be revoked once shipped, so roots stay offline and sign revocable intermediates. A missing intermediate works in Chrome and fails in curl.
• TLS 1.3 is one round trip because the client guesses the algorithm and sends a key share immediately; the certificate arrives already encrypted. Its real achievement is subtraction — RSA key exchange, CBC, RC4, compression and renegotiation all removed.
• SNI carries the hostname in plain text, which is how per-site blocking works over HTTPS; Encrypted Client Hello is the fix.
• Encrypted on the wire, but the path still reaches logs, history and Referer — never put a secret in a URL.
• HSTS stops SSL stripping by converting plain-HTTP requests before they leave the machine; mTLS authenticates both ends and is for service-to-service, at the cost of running a CA and automating rotation.

Self-test: Name one thing the padlock does not guarantee that users assume it does · Why does forward secrecy matter against an adversary recording traffic today? · Why sign leaves with an intermediate rather than the root? · Why does a missing intermediate often work in a browser and fail elsewhere? · What leaks about your browsing even over HTTPS? · Why is TLS 1.3 safer partly because it has fewer options?

Next: 5.8 covers what you build on top of all this — the family of communication patterns, from request/response through server push to webhooks, chosen by the shape of the problem rather than by fashion.