And that's with experienced admins and developers. Doing this with our average B2B customer? Hah, oh dear.
This informationally dense and adventurously worded sentence is the kind that you can only understand if you already understand it, it feels like. I certainly can't unpack it without getting my hiking gear on. Not this rainy morning, though, may the transport layer gods forgive me.
This is not true but it would be nice if it was.
I'll have to install some fresh VMs and see what behaviour I get out-of-the-box with no HSTS cache (and sites not on the preload lists) on various OSs, to correct my understanding.
No.
Not serving on port 80 means a passive viewer won't see any content, but if you were just serving a redirect, there's not much content to see.
IMHO, if you use HSTS preload and you prime HSTS by serving your favicon with https and HSTS, you can go ahead and serve your (unauthenticated) content with http. A modern browser will switch over to https; a MITM could fetch your https pages and return them over http; and you'll be accessible on ancient browsers that can't manage modern TLS.
For a lot stuff on my local network I don’t want the hassle and there are loads of use cases in local networks for normal people to just have port 80 no certs on something like 192.x.x.x because there is no easy way to set up public certificates for that and I don’t want everything hostem on cloud - some stuff I want to still host for myself in my local network.
Corporations or companies should not do that - even internal networks should have proper certs and encryption but it also is not that easy.
Stuff sent over the internet for others to see should have TLS always because you don’t know where your packets travel.
Tbh I don't see what's hard about this. All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy. You can even use a free ddns service if you want. Wouldn't bother with this for development, but anything hosted for longer than a few days absolutely yes. Imo not getting browser warnings is alone worth the few minutes it takes nowadays.
And to distribute keys that allow those appliances to update the DNS records, to secure those keys, have an a way to install those keys (and update/rotate them), and make sure your DNS host is supported by your acme client.
I can yeah it is easy but I have 20 years of experience.
I don’t want to spend time setting that up.
For less technically capable people you just lost them in first sentence.
Everything on my home network uses publicly-trusted certs from LE, including my router with only 8MB of flash and 128MB of memory. You need to use the DNS challenges if you don't want the services to be publicly accessible, but you can run ACME on nearly everything these days.
I’d much rather spend time arguing about it on HN.
That’s the neat part of “it is my time” and I want to use it the way I want.
It doesn’t apply to stuff I publish over the internet all personal pages blogs have https, that’s not negotiable.
IE: I just typed "google.com" into Brave and it made a request to http://google.com which responded with a 307 redirect to https://google.com, which then made a 301 redirect to https://www.google.com.
I just installed fresh chromium and firefox in a clean Linux VM and typed "google.com" (and a few others) in the URL bar with tcpdump running and they both initiated with TCP port 80. Can confirm that the https-only setting is disabled for both when looking in settings/preferences.
> HTTP is only used as a fallback.
Separately, using HTTP as fallback makes the whole thing mostly pointless security-wise. If an attacker can MitM port 80 it is very likely that they can also interfere with 443 to silently force a protocol downgrade. STRIPTLS.
SMTP STARTTLS has the same problem. ISPs and authorities have been known to harvest email traffic by the same technique.
We don't really need HSTS to address most scenarios. Just have browser not attempt http:// for addresses in the address bar unless explicitly specified. Have it try https:// without falling back to http://.
HTTPS-by-default with fallback is not a good default setting since it's vulnerable to the above attack. Strict HTTPS-only is not a good default setting since it prevents legitimate http traffic on internal networks. HSTS adds problematic edge-cases. It's hard to fathom that none of the major browser vendors seem to have figured out the obvious solution to just stop inferring http:// unless asked for.
I'm not sure the best way to secure that situation. Unencrypted traffic that only stays on my own computer is a valid use case, and unencrypted traffic on my home network is about as risky as skinny dipping in your own back yard.
To appease them, I switched the redirect off in dev/staging, and soon enough even devs are having trouble accessing the site because they type 'website.com' and that can't resolve, only 'https://website.com' can.
(And before you say it, yes we use HSTS, but I presume there were some scenarios where that wasn't already cached/hit).