HTTPS end to end

You type an address, you hit enter, and before you even see the screen there's already an icon to the left of the address saying: this connection is secure. A conversation happened in between. In those few hundred milliseconds your browser and the server agreed on a secret, exchanged and checked a piece of evidence, and switched over to encryption. This chapter counts down what happens — and there's no new maths involved. Everything you need is already in the previous chapters. Here you see them working together.

The handshake, step by step

1. ClientHello. Your browser goes first, with a message saying: which TLS versions it can do, which cipher suites it knows, which site it wants (that's the SNI) — and right away its half of the key exchange. So it doesn't wait until the server has chosen; it guesses what the server will probably want and sends its public half along already.
2. ServerHello. The server picks a version and a cipher suite, and sends back its own half. At that moment both of them can, each on their own, work out the same number: the shared secret. That's exactly the paint trick from chapter 5, usually on an elliptic curve. There's now a key, and it never went across the line.
3. The certificate and a signature. From here on everything is already encrypted — including what comes next. The server sends its certificate (chapter 7.2) and on top of that a signature over the whole conversation so far. That signature is the point: anyone can copy a certificate, but only whoever holds the matching private key can put one there. That's how you know you're talking to the real server and not to a man-in-the-middle.
4. Your browser checks. Three things, and all three have to be right. Can the signature chain of this certificate be followed all the way up to a root certificate it trusts? Is the name in the certificate the same as what you typed? Are we inside the validity dates? One no and you get no padlock but a warning screen.
5. Symmetric from here. From now on everything — the page, the images, your password, every click — goes symmetrically encrypted with AES-GCM. That's chapter 4, and the fact that the heavy maths is only needed for the start while the rest goes fast is chapter 7.3.

Which chapter sits in which step

One round trip instead of two

The browser sending its half of the key exchange in its very first message sounds like a detail. It's the biggest change in TLS 1.3 compared to its predecessor TLS 1.2. There it went like this: first the browser asked what the server could do, then the server answered, and only after that did the key exchange begin. Two trips back and forth before a single letter of content crossed the line. TLS 1.3 does it in one trip back and forth.

On a connection where one round trip costs 50 milliseconds, that saves 50 milliseconds per new connection — and a page often pulls its images, fonts and scripts from a handful of different domains, each with its own connection. That's how the newer version became both more heavily secured and faster at the same time.

What the padlock does and doesn't mean

That second one isn't a theoretical problem. A certificate costs nothing these days and is arranged in minutes, including for someone building a fake version of a login page. More than nine in ten phishing sites have a valid certificate and therefore a padlock — in 2019 that was still about six in ten. The padlock proves that nobody is reading along on the way — not that the destination can be trusted.

In 2021 Google looked into what people thought the padlock meant. 11 per cent had it right; the rest read it as a seal of approval. That's why the padlock in Chrome has been replaced, since version 117 from September 2023, by a neutral icon with two sliders. Not because anything changed about the security, but because the symbol promised the wrong thing.

Do it yourself, right now. Click the icon to the left of the web address above — in Chrome and Edge the two sliders, in Firefox still a padlock. Find your way to Connection is secure and then to the certificate, and you'll see exactly the things from step 4: which name it's valid for, who issued it, between which two dates it holds, and the chain above it up to the root. This is the certificate of the site you're reading right now.

What an eavesdropper can still see

Encrypted doesn't mean invisible. Someone who can read the traffic on your network — your internet provider, whoever runs the wifi — still knows a few things.

Work is under way on that first leak. Encrypted Client Hello (ECH) wraps the real ClientHello — with the real SNI inside it — encrypted in an innocent-looking outer shell. Your browser gets the key for that from DNS. Chrome has had it on by default since version 117 (September 2023), Firefox since version 119 (October 2023), and since March 2026 it's an official internet standard: RFC 9849.

Half closed, then, not entirely. It only works if the site itself takes part and publishes its key in DNS, and plenty don't. And your DNS question stays visible unless that goes encrypted too (DNS over HTTPS). The IP address your connection runs to they see either way: without an address no packet arrives.

HSTS: never come over http again

There's one moment where it goes wrong. Type site.be without https:// in front of it, and your browser has traditionally tried plain http first — unencrypted. That one first question can be intercepted by a man-in-the-middle and redirected to their own copy, and then the rest of your visit is theirs. That's why a site can send a line along in its answer saying: remember that you may only come to me over https from now on, with an expiry date attached. That's called HSTS, described in RFC 6797 from November 2012. Your browser remembers it, and after that doesn't even try over http — not even if you type it, and not even if you want to click "continue anyway". The only gap left is that very, very first visit, and for that browsers keep a built-in list of domains that have always been https.