HSTS preload adoption and challenges | Hacker News Reader

HSTS preload adoption and challenges

alexsci.com

29 points8organicbits16 comments

Controversial opinion: optional security isn't security.

HSTS is a crappy hack introduced because the industry has never had a sunset plan for protocols. When you do Enterprise engineering, you are aware that nearly every single project will die, and so you start the project by planning for how you will kill it in such a way that people can migrate to a new thing as painlessly as possible. But the industry doesn't do that with protocols. So they can't ever die. Because of that, we need backwards compatibility forever and there's extremely little innovation in widely adopted solutions. So any new "fix" has to come as an optional band-aid that falls off if you look at it sideways.

HSTS is the band-aid used to continue propping up our lack of ability to kill off HTTP. Quite simply, HTTPS just doesn't work everywhere. That's why HSTS exists - because we can't just tell browsers "stop supporting unencrypted HTTP". And rather than try to find a way to kill HTTP, or change HTTPS to provide for the things HTTP does, instead we have this optional flag that tells the browser how to manage two things: 1) the site's certs, and 2) browser behavior around a subdomain.

Why do I say it's not security? Because there's plenty of ways around it. Because not all clients support it. Because a server has to explicitly enable it, and do it correctly, which this article shows isn't happening even for the biggest websites. And because if your website isn't in this special preload list, you don't get the benefits of it anyway. (Why the fuck do we have PKI based on the integrity of 350 different CAs if it's meaningless without bundling your individual domain's special configuration with the browser?)

Real security isn't something you can just turn off or avoid. It doesn't require you to submit every domain you want to be secured to a special list packaged in the browser.

Killing off HTTP completely is simply not going to happen, and in the meantime using HSTS does confer a tangible and real security benefit.

Regardless of whether we can kill of HTTP, this argument that “optional security is not security” is completely facile. For example, I could write my own browser right now that doesn’t verify TLS certs. Does that make HTTPS’ authentication “not security”? The real question is what proportion of clients _do_ honour HSTS, and the answer to that is “most”.

> HSTS is the band-aid used to continue propping up our lack of ability to kill off HTTP

HTTP doesn't need to be killed, so your entire premise is flawed. HTTPS is a useful protocol in many situations, but its not, and should not be required for all connections. for many reasons, but one for example is that TLS connections are at least an order of magnitude slower than HTTP, and that wont ever change.

My guess is that Google will just kill HTTP one day for public addresses. https for my router UI is still not solved problem in 2023, so that obviously will be an exception for the next 20 years. But when you'd type `example.com`, Chrome will connect to HTTPS. And if it can't, it'll connect to `https://proxy.google.com/example.com` under the hood. So no security compromises anymore.

So your router has no setting to turn on https? I guess I'm spoiled because OPNSense has always had that option...

It does, but it doesn't have a good way to get a public hostname + publicly trusted certificate.

Using self-signed https or https with an externally provided cert is "easy" but not something a normal user would or could do (properly).

Wait but why do you need that? Are you planning to make your router web interface publicly accessible? I don't really understand. I just created the cert myself and since I control the router I also control the LAN from which it is accessible. And I can install the cert on machines in that LAN.

Without a public hostname and cert, it's inconvenient to use. And how do you tell the equipment to use your certificate when you can't communicate with it because http is banned and https doesn't work without an approved certificate.

You're right, I didn't consider that! Although most users allow you to plug in your laptop before plugging in any upstream. So you can reconfigure that before actually installing the router.

Either you have a valid cert, or you need to manually install the cert, or you're clicking through a scary warning (every time you start a fresh browser session, I think).

For a normal user, the procedure for manually installing a certificate is "put the router back in the box, return it to the store, and buy a different brand".

Businesses that care about this stuff enforce it contractually.

> facebook.com / max-age=15552000; preload

That is a really weird value. It fails two of the three requirements for the HSTS header value specified at <https://hstspreload.org/>:

> 1. The max-age must be at least 31536000 seconds (1 year).

> 2. The includeSubDomains directive must be specified.

> 3. The preload directive must be specified.

It doesn’t even comply with their rules for grandfathered entries, which only lower the minimum max-age, but still require includeSubDomains. Yet it’s still in the list. ¯\_(ツ)_/¯

It's hard to find the history, but facebook is on the preload list by the great grandfathered method: they asked the chrome team to be added prior to the existance of the hsts preload submission site. It's been forever since I looked at the config file, but last time I looked, FB had hand configured CA pinning as well.

Disclosure: I worked at WhatsApp until 2019, and was the person who submitted whatsapp domains to the preload site after I setup hsts headers on them. I think WhatsApp domains should be in the FB CA pinning config now, but I'm not 100% sure, and don't really want to try to find the preload config file to check.

Is this what you are referring too?

https://chromium.googlesource.com/chromium/src/+/refs/heads/...

I wonder why Cloudflare still recommends a value of 6 months (15552000 seconds) for Max-Age in the HSTS header, when that isn't enough to qualify for Google's preload list. They do acknowledge this problem in their docs, but (afaik) without explaining why they've stuck with 6 months as the default and recommended value.

I suspect well written docs avoid pushing HSTS and HSTS preload too hard. On first pass it sounds like a great security tool, so people rush to enable it, but then many have issues. When your HSTS preload setting gets hardcoded into a browser, you can't remove it. You've got to wait for all your users to update.

I think the Cloudflare recommendation is based on the Qualys tool, which uses six months as their recommendation. Interestingly, Twitter is using 631138519 seconds (20 years) for their setting, so they are extra confident.

Reply on news.ycombinator.com