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.
> The attacker HTTPS contemplates controls whether victims see SYN+ACK packets in response to their 80/tcp SYNs.
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.
if an attacker is in the position to try to MITM TLS, they're in the position to just serve whatever they want on port 80 even if your server isn't doing that.
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).
Hmm. I am perhaps confusing announced plans, and the effect of the HSTS preload lists, with actually released changes to defaults.
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.
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.
A MITM can intercept the SYNs to port 80 and send their own SYN+ACK.
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.
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().
> For a lot stuff on my local network I don’t want the hassle […] because there is no easy way to set up public certificates
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.
Fair enough. The only reason that I bothered setting up HTTPS certificates in my home network was because I was using a domain where I had previously enabled HSTS. I was wasn't very enthusiastic about it when I first added the certificates, but once I figured it out, I appreciated seeing a little padlock when I logged in to my router. That's essentially the only benefit though, so I certainly don't blame you for not wanting to go through the effort to set it up.
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.
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.
Not being able to access the web interface where you have to manually upload a new certificate due to HSTS and the old certificate having expired a couple hours ago...
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.
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.
> The attacker HTTPS contemplates controls whether victims see SYN+ACK packets in response to their 80/tcp SYNs.
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.
if an attacker is in the position to try to MITM TLS, they're in the position to just serve whatever they want on port 80 even if your server isn't doing that.
They can't all be winners!
Thanks for sending them on their way regardless. It does tend to move things forward.
Like a good dose of dietary fiber.
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).
> Modern versions of Chrom{e|ium} & Firefox (and other browsers based on them) have defaulted to HTTPS when the protocol is not specified.
This is not true but it would be nice if it was.
https://news.ycombinator.com/item?id=46443199
Hmm. I am perhaps confusing announced plans, and the effect of the HSTS preload lists, with actually released changes to defaults.
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.
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?
A MITM can intercept the SYNs to port 80 and send their own SYN+ACK.
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.
No, not really. You can still be MITMed on port 80.
Right. Clients (web browsers) would have to stop using it too for it to work I guess.
>no?
No.
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.
XD
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.
“ 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().
> For a lot stuff on my local network I don’t want the hassle […] because there is no easy way to set up public certificates
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.
Neat part is that’s my local network and I don’t want to spend time doing that.
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.
Fair enough. The only reason that I bothered setting up HTTPS certificates in my home network was because I was using a domain where I had previously enabled HSTS. I was wasn't very enthusiastic about it when I first added the certificates, but once I figured it out, I appreciated seeing a little padlock when I logged in to my router. That's essentially the only benefit though, so I certainly don't blame you for not wanting to go through the effort to set it up.
IMO: The right time to ask this question is when all browsers default to HTTPS; instead we should ask why browsers default to http instead of https.
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.
Firefox, Safari, Chrome, Edge and even Brave have "HTTPS first" or "HTTPS by default" enabled out of the box. HTTP is only used as a fallback.
Why are you saying lies?
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.
Then why did mine do http first? Use the F12 screen to watch your browser resolve a domain that you type into the address bar.
Even with default https etc, HSTS still adds some defence against MITM - browsers won’t let you even forcibly accept a self signed certificate
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.
Yeah it’s more of an annoyance for sure. I only discovered it was a thing when intentionally MITMing a domain on my router
Not being able to access the web interface where you have to manually upload a new certificate due to HSTS and the old certificate having expired a couple hours ago...
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.)
> Chromium-based browsers violate the HSTS spec and allow bypass.
If you were able to bypass HSTS using google chrome, that sounds like a bug.
you can type "thisisunsafe" on HSTS error page to bypass
When does HSTS get in your way?
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.
When I'm unable to turn it off.
it's a note at the very end, but there are TLDs like .dev where all domains under it have HTTPS enforced.
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.