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.
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.
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.
it's a note at the very end, but there are TLDs like .dev where all domains under it have HTTPS enforced.
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.
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.
Your second example would also be prevented by just not serving on port 80 as the parent comment suggests, no?
No, not really. You can still be MITMed on port 80.
>no?
No.
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.