In October 2026, Chrome 154 will turn on “Always Use Secure Connections” by default. Navigate to a plain http:// public site and the browser will stop and warn you before it loads, the same way it does for a bad certificate today. Google announced it in October 2025, with a staged rollout: Enhanced Safe Browsing users get it in April, everyone else six months later.
That’s the finish line. Not a metaphorical one — an actual, dated, shipping event where plain HTTP stops being a normal thing the web does and becomes a thing the browser interrupts you about.
I want to be clear that this is good. I’m not about to argue that encrypting the whole web was a mistake. It’s one of the few genuinely completed security projects in the history of the internet, and the people who spent fifteen years on it — the EFF, Let’s Encrypt, the browser security teams — earned the win. The EFF started shipping its HTTPS Everywhere extension in 2010, when getting a site onto TLS meant paying a CA and wrestling OpenSSL. They quietly wound the extension down in 2022 and told everyone to just use the browser’s built-in HTTPS-only mode, because the browsers had finally made the extension redundant. That is what victory looks like: the tool becomes unnecessary.
So we won. Here’s the part that’s been nagging at me: we won the war we could win.
The tractable problem
Transport encryption was, in retrospect, the tractable problem. It had every property you want in something you’re going to solve.
It was verifiable — you can prove a connection is encrypted, mechanically, from either end. It was automatable — Let’s Encrypt launched in 2015 and turned certificate issuance from a purchase order into a ninety-second script, which is the single reason adoption went vertical. It had a clean success metric — the percentage of page loads over HTTPS, which Google has published on its Transparency Report for years, climbing from around 40% in 2015 to past 95% by 2020. And it had a forcing function: HTTP/2 and HTTP/3 exist, and no browser implements either one over cleartext. If you wanted the faster protocols, you took the encryption with them. There was no opt-out.
An engineering problem with an engineering answer, a number that goes up, and a deadline the browsers eventually set for you. That’s a solvable problem. We solved it.
The trouble is that we’ve spent so long pointing at that number that it’s easy to mistake it for the whole scoreboard.
What the padlock never bought you
HTTPS guarantees exactly one thing: nobody between you and the server can read or tamper with the bytes. It was never a statement about who’s at the other end or whether you should trust them. Everyone who worked on it knew that. The caveat — encrypted is not the same as safe — was always printed in the footnotes.
Now that everyone has HTTPS, the footnote is the whole document. When the overwhelming majority of phishing sites carry a valid certificate — which they do, because certificates are free and automatic, the same reasons legitimate sites have them — the presence of encryption tells you nothing about intent. HTTPS went from a signal to a floor. A floor is worth having. But you don’t congratulate a building for having a floor.
And underneath the encrypted pipe, the parts that actually decide whether you can trust the other end are all still broken in the ways they were broken in 2015.
Start with the trust model itself. Your browser trusts roughly 150 certificate authorities, and any one of them can issue a valid certificate for any domain on earth. Encrypting the connection does nothing about the fact that the guarantee of who you’re talking to rests on the least trustworthy member of a 150-organization set. Certificate Transparency — the public, append-only logs of every cert issued, which Chrome has required for all newly issued certificates since 2018 — is the patch we bolted on because the trust model couldn’t be fixed, only watched. It’s detection, not prevention. We made the failure mode auditable instead of impossible, and then we called it a day.
Then there’s revocation, which is the problem nobody wants to look at directly. A certificate is a claim that’s valid until it expires — unless the key gets stolen, in which case you need to kill the certificate early. Both mechanisms for doing that, OCSP and CRLs, have been quietly failing for a decade. Browsers soft-fail OCSP checks (if the check times out, they shrug and continue, because hard-failing would take down the web every time an OCSP responder hiccuped), which means a determined attacker can just block the check. Let’s Encrypt announced it’s ending OCSP support entirely and falling back to CRLs aggregated by the browsers. Fifteen years of encryption progress, and the answer to “this certificate went bad, stop trusting it” is still “sort of, eventually, if the browser got the update.” Encryption assumes the key is good. It has nothing to say about what happens when it isn’t.
And then, the one I find most quietly damning: HTTPS encrypts what you send, not where you’re going. The Server Name Indication field — the hostname your browser announces at the very start of the TLS handshake so the server knows which certificate to present — goes out in cleartext. Anyone watching the wire sees exactly which site you’re connecting to, encrypted session or not. The fix, Encrypted Client Hello, exists and is real, but deployment is thin — a handful of large providers and partial browser support. And your DNS lookup leaked the same hostname a few milliseconds earlier anyway. We spent fifteen years making sure nobody could read your traffic, and left the address on the outside of the envelope.
The danger of a finished mission
None of these are HTTPS’s fault. Encryption did its job. The problem is what a completed mission does to attention.
“HTTPS Everywhere” worked partly because it had a boundary you could draw a clean line around and declare victory inside. That’s exactly what made it winnable — and it’s exactly what makes the remaining problems different. Trust, identity, revocation, metadata: none of them have a percentage that goes to 100 and stays there. None of them have a version of Chrome that ships the fix by default in October and closes the ticket. They’re the kind of problem that’s never done, and our entire recent muscle memory in web security is built around problems that finish.
So the real risk of the green checkmark we all get in October 2026 isn’t that it’s wrong. It’s that it feels like an ending. Fifteen years of “look for the padlock, get the cert, turn on HTTPS” trained an industry to believe transport security is the security story. Now the story’s last chapter is being written into the browser as a default, and the natural human response to finishing a long project is to believe the category is handled.
It isn’t. We built a perfectly encrypted road to a destination we still can’t reliably identify, guarded by 150 gatekeepers we can’t individually vouch for, with a revocation system that mostly doesn’t work and a signpost anyone can read from across the street. That was never what HTTPS promised to fix. It’s just what’s left once it did.
The easy part is over. That’s the good news and the whole problem at once.