Honest question/thought - at this point where we have all HTTP requests for a site just redirecting everything to HTTPS, we use HSTS and browsers default to trying https when scheme is not given, why don't we just stop serving on port 80 altogether? Why even bother with HSTS?
I have a few internal services on which I like to crank transport security to 11. No port 80, only TLS 1.3, only modern ciphers. You'd be surprised how much confusion not opening port 80 caused across technical people. And I've learned a bunch of things about supported TLS versions and supported ciphers of windows server versions from this crusade.
And that's with experienced admins and developers. Doing this with our average B2B customer? Hah, oh dear.
The answer to this question is interesting, and it's that not serving HTTP doesn't actually help. The attacker HTTPS contemplates controls whether victims see SYN+ACK packets in response to their 80/tcp SYNs. TCP itself isn't authenticated. So you need something "sticky" in the browser to remind it not to try 80/tcp, and thus risk being bamboozled by a MITM attacker.
For new sites that is definitely practical. Modern versions of Chrom{e|ium} & Firefox (and other browsers based on them) have defaulted to HTTPS when the protocol is not specified. The only potential issue is if users do specify the protocol and leave the S out, it would be good for browsers to try HTTPS when HTTP fails (though only if it completely fails to connect).
Just wait a bit and there will be some TLS denialism spawning here.
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.
> 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.
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.
> All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy
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.
“ All you need is an A record pointing to your 192.x.x.x, acme capable dns host and a modern reverse proxy”. That’s a LOT more than socket(), listen(), and accept().
Old links to your site might still be http - HSTS prevents that request being in the clear. Also, if you have a man-in-the-middle attack, it doesn't matter if you return a redirect or not as the attacker has already replaced your site with a phishing attack instead of a redirect. HSTS prevents this.
The number of MITM attacks that's thwarted for me remains zero, while sites forgetting to renew their certs despite setting HSTS is a fairly regular occurrence.
It would be nice. Our security team started complaining that we serve a 301 redirect on port 80 for our website (just like 99.9% of websites do... sigh) and wanted port 80 shut down.
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).
I think we're probably at the endgame where ordinary people start to benefit from HTTPS-by-default. Ten years ago it was way too annoying for me to even suggest to my mother that she should have this, although I did use it myself because I understand the caveats, but today "We don't have HTTPS" either means you don't really support web browsers (e.g. some protocols deliberately are HTTP-based but don't use TLS and some even can't if they wanted to) or that the whole site is mothballed so if it didn't have TLS in 2015 it still doesn't today.
As we transition ordinary users to HTTPS-by-default the HSTS feature loses importance. The target audience for HSTS isn't me, or the package management software I run, or some Python code using requests, it's my mother and sister and other ordinary users, and so if they increasingly have HTTPS-by-default then HSTS stops mattering.
I've been running not just HTTPS-by-default but strict HTTPS-only for a while now. Firefox, at least, mostly even handles things like captive portals correctly. Judging by the rarity of encountering anything that has HTTP and doesn't listen on HTTPS, I think we're to the point where any non-technical user could use an HTTPS-only configuration and correctly treat any site that doesn't work with it as broken.
HSTS remains a broken antifeature which violates the covenant of a browser agent being a browser agent. (A server should never have more authority than me on dictating how my agent works.)
Firefox refuses to support the ability to bypass HSTS which generally means I'm forced to use a different browser when HSTS is getting in the way of me doing my job.
(Thankfully or unfortunately, Chromium-based browsers violate the HSTS spec and allow bypass. But there seems to be no appetite to actually repair the HSTS spec to permit this.)
Most commonly when fixing certificate errors! A lot of modern web applications have all of their certificate configuration in the web interface... which you can't access when your certificate breaks. I think once I had to break out IE11 to fix a certificate because Firefox wouldn't let me...
But also sometimes I need to access a website where the certificate lapsed yesterday. This is not a security issue and no reasonable person would assume a certificate expired yesterday is compromised, but we are living in a world of madness. I am not going to wait for some third party to fix their site, I'm just going to circumvent HSTS, I have better things to do.
Specifically .dev has HSTS pre-loaded everywhere. But that's not the same thing as HTTPS enforced. There are protocols built on HTTP which can't do TLS, those also don't obey HSTS (it would be pointless) and so they work fine on .dev as do HTTP services for non-humans who also needn't obey HSTS and presumably already understand the consequences.
reply