[HN Gopher] HSTS preload adoption and challenges
___________________________________________________________________
HSTS preload adoption and challenges
Author : 8organicbits
Score : 18 points
Date : 2023-06-11 13:04 UTC (9 hours ago)
(HTM) web link (alexsci.com)
(TXT) w3m dump (alexsci.com)
| throwawaaarrgh wrote:
| 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.
| HL33tibCe7 wrote:
| 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".
| vbezhenar wrote:
| 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.
| sureglymop wrote:
| So your router has no setting to turn on https? I guess I'm
| spoiled because OPNSense has always had that option...
| tgsovlerkhgsel wrote:
| 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).
| 2h wrote:
| > 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.
| chrismorgan wrote:
| > _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. -\\_(tsu)_/-
| theobeers wrote:
| 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.
| 8organicbits wrote:
| 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.
| MrStonedOne wrote:
| [dead]
___________________________________________________________________
(page generated 2023-06-11 23:01 UTC)