How HTTPS works: what the padlock actually proves

The padlock is the most-looked-at security indicator ever shipped and the most misread. The video draws the mechanism: a shared secret neither side sent, a certificate, and a chain that climbs to something your browser already had. Ninety seconds has room for that. What follows is everything it had to leave out — starting with what the padlock actually claims, and where that claim quietly stops.

What the padlock actually claims

TLS 1.3 is specified in RFC 9846 (Standards Track, July 2026), obsoleting RFC 8446. Its §1 lists three properties and only three:

Property	What §1 says
Authentication	“The server side of the channel is always authenticated; the client side is optionally authenticated.”
Confidentiality	“Data sent over the channel after establishment is only visible to the endpoints.”
Integrity	“Data sent over the channel after establishment cannot be modified by attackers without detection.”

Authenticated means the far end holds the private key for a certificate that something in your trust store vouched for, and that certificate lists the name you typed — RFC 5280 §6.1 states path validation’s own objective as verifying the binding between a subject name and a public key. Nothing more. The server proves this with two messages: Certificate (the key-to-name binding, public, copyable by anyone) and CertificateVerify (a signature over the handshake made with the matching private key, proving whoever answered actually holds it right now). And because the key pair used for that exchange is generated fresh per connection and thrown away, recording today’s handshake and stealing the server’s long-term key in two years still doesn’t decrypt it — TLS 1.3 makes this forward secrecy unconditional (§1.3).

Revocation: assume it’s best-effort

The video ends the certificate story at the chain verifies and the dates are in range. The implication is that a stolen key is a problem until notAfter, and not one minute longer. It isn’t quite — revocation exists to kill a certificate early — but the honest version is that revocation barely works in practice.

CRLs (RFC 5280 §3.3) are a signed list of revoked serials a client fetches and caches for hours — with, by the spec’s own admission, “the time granularity of revocation… limited to the CRL issue period.” OCSP (RFC 6960) replaced the download with a per-certificate question, but it’s a second network round trip to a third party, it leaks which site you’re visiting, and browsers soft-fail it — if the responder is slow or down, the connection proceeds anyway, because hard-failing would let one CA outage take down a chunk of the web. Chromium’s own documentation is blunt: “Online (i.e. OCSP and CRL) checks are not generally performed by Chrome.” Instead Chrome ships a curated blocklist (CRLSets); Firefox downloads a compressed encoding of every revoked certificate and checks it locally (CRLite). Neither is a live check against the CA.

If you can’t reliably revoke, you shorten the window instead. The CA/Browser Forum’s Baseline Requirements now cap public certificate validity on a schedule that falls to 100 days in 2027 and 47 days in 2029. Design as though a leaked key is exploitable until the certificate expires — rotate rather than rely on revocation, and automate renewal now, because a manual renewal you do twice a year becomes one you do eight times a year.

SNI: the name goes out before anything is encrypted

The video draws the certificate as the server’s answer to who are you. But one IP address serves hundreds of sites, so before the server can pick a certificate it has to know which name you asked for — the server_name extension, Server Name Indication (RFC 6066 §3), sent in the ClientHello.

Line that up against RFC 9846 §1.3: “all handshake messages after the ServerHello are now encrypted.” The ClientHello is the first message. There are no keys yet. So in an ordinary TLS 1.3 handshake, the hostname you’re visiting goes out in plaintext, and anyone on the path reads it without breaking anything — TLS 1.3 encrypts the certificate, but not this. Encrypted Client Hello (RFC 9849, March 2026) fixes it by wrapping the real ClientHello inside a decoy one, encrypted under a key the domain publishes in DNS — but it depends on that DNS lookup being unencrypted too, and it only hides you inside however many other sites share your edge server.

Certificate Transparency: you can’t prevent mis-issuance, only catch it

The honest answer to “so a phishing site just buys a certificate?” is yes. The question that matters is what happens when a CA issues one for a name that isn’t the applicant’s — by mistake, compromise, or duress.

Certificate Transparency is append-only public logging: a CA submits a precertificate to public logs before issuing, gets back Signed Certificate Timestamps, and embeds them in the real certificate. Chrome’s CT policy requires at least two SCTs from distinct log operators for most certificates, and one that doesn’t comply “will simply fail to validate in CT-enforcing versions of Chrome.” What this buys you isn’t prevention — it’s that every certificate for your domain is public and searchable, so you find out about the one you didn’t ask for.

HSTS: the request before the first request

Someone types owltheengineer.com. The browser has no scheme, so it tries HTTP first, and your server 301s to HTTPS. That first request was plaintext, and an attacker on the path can answer it instead of you and never let you reach the redirect.

RFC 6797 fixes it with one response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

For max-age seconds, the browser rewrites http:// to https:// itself before any packet leaves, and refuses to let the user click through a certificate error. includeSubDomains extends that to everything under the name — closing the gap where an attacker plants anything.owltheengineer.com over plain HTTP. The remaining gap is the first connection to a host you’ve never visited, where there’s no policy yet to enforce — which is what browser-vendor preload lists are for: a name shipped inside the browser itself, HTTPS-only from the very first request.

The padlock is not a trust badge

The padlock is a claim about the connection: private, unmodified, and terminating at something holding the private key for a certificate naming the host you asked for. “Honest,” “legitimate,” and “safe to give your card to” appear nowhere in RFC 9846 §1, and nothing in TLS or RFC 5280 could evaluate them.

A phishing site with a valid certificate is phishing over a properly encrypted connection, and the browser is telling the truth — it’s confirming that nobody is intercepting your credentials on the way to the criminal. Getting a certificate for a domain you control takes about thirty seconds and costs nothing, and it’s supposed to: the alternative, where a CA decides who deserves encryption, is a worse internet than this one. What actually helps is elsewhere — the name in the address bar, which is the only part of the padlock’s claim a human can check, and Certificate Transparency and short lifetimes limiting how long a mistake stays exploitable.