Wait, Chrome is now requiring HSTS for localhost? This is absolute madness. Somebody needs to sit down with the people responsible for this and explain to them that this is not solving anybody's problems and is just making life more difficult for everyone.
This sounds like if you create a custom CA, import it, create a cert for localhost, and then connect Chrome to https://localhost and it sends an HSTS header that Chrome accepts.
Which is something you probably shouldn't be doing in the first place.
Browsers aren't supposed to accept HSTS on self-signed certs so connecting to a self signed localhost shouldn't do this.
> Browsers aren't supposed to accept HSTS on self-signed certs so connecting to a self signed localhost shouldn't do this.
There's nothing against self signed certificates working with HSTS at all. It's perfectly fine for browsers to accept HSTS regardless of who signed it.
I think the point is that if you add a temporary exception to accept the unverified certificate, you shouldn't be left with a permanent requirement that localhost have a certificate in the future because of the HSTS header you got during that time.
> There's nothing against self signed certificates working with HSTS at all.
Actually, there is.
Section 8.1 of RFC 6797 opens with:
"If an HTTP response, received over a secure transport, includes an STS header field, conforming to the grammar specified in Section 6.1, and there are no underlying secure transport errors or warnings (see Section 8.4), [...]"
Section 8.4 then goes on to define "errors or warnings" as including any errors caused by UA certificate validity checks.
Additionally, section 14.3 opens with:
"The user agent processing model defined in Section 8 stipulates that a host is initially noted as a Known HSTS Host, or that updates are made to a Known HSTS Host's cached information, only if the UA receives the STS header field over a secure transport connection having no underlying secure transport errors or warnings."
(and then goes on to provide the rationale for this decision)
> It's perfectly fine for browsers to accept HSTS regardless of who signed it.
No, it isn't. This enables active attackers to cause a permanent denial of service even when you subsequently move out of their reach. That's the rationale.
If you point it at https://localhost/ and the cert is valid (e.g. you installed a private CA and used it to sign a cert for localhost) and the site serves an HSTS header, yes. Like any other hostname.
People who set up an HTTPS dev environment and have it send an HSTS header and then get annoyed when it behaves exactly as designed (and they know it) are rather out of touch, in my opinion. If you don't want the browser to force HTTPS, don't tell it to.
localhost isn't solely the property of whatever is serving that site at that time though. You're at the mercy of one app doing it then breaking everything else for you.
> This is designed to work with Chrome >=78 on macOS
Chrome 78 is like 25 releases ago, so nothing new here, they’re not requiring HSTS for localhost now, or ever, hopefully. Whoever the hell decides to force an HTTPS connection to localhost with an HSTS header have themselves to blame. localhost is a secure context without HTTPS.
I have a question. If there is something on localhost,why do browsers like chrome scare you into "proceed with unsafe anyways"?
Its not like I care about a mitm attack on my own computer or what if I am on 192 or 10.0 ? Isn't that inherently a non-internet access so why don't these scary warnings ingnore local devices? I know I can set up a CA for my nginx test or apache but why? What benefit other than " inculcating a habit"?
I mean I run home assistant and grafana in my local network but android tells me often its "unsafe"
So for RFC 1918 addresses (10/8, 192.168/16, 172.16/12) I would argue that it is unsafe, or at least the browser/machine can't tell that it's safe; AIUI there's generally nothing on a standard home wifi network that would stop one device (coffee maker, visiting cousin's cheap unbranded tablet) from watching all local traffic (definitely recording, not sure about spoofing). So it's an unlikely threat model for most people, but it is real.
Actual localhost traffic that never leaves your machine.... yeah, I can't think of a case where that would ever matter. If something can intercept that you have bigger problems:)
>Actual localhost traffic that never leaves your machine
Unless you run
ssh servera -L 8080:serverb:80
I sometimes do this if there's a firewalled serverb that I can't access that's running a webserver, and a non-firewalled servera that I have ssh access and can access serverb.
Then you can open http://localhost in your browser and talk to serverb. If you want HTTPS to work, then ideally you'll map serverb to 127.0.0.1 in your /etc/hosts so that its HTTPS certificate matches the host, or use --host-resolver-rules="MAP serverb 127.0.0.1" as a Chrome commandline flag. Of course then you're no longer using localhost in the host.
come on. by that point you are explaining something weird.
my question is this. if i set up nginx/apache2 on my local network to serve a webpage, or i have a plex server or something similar or say nextcloud or whatever people self host these days, why should i be forced to have https?
that data wont be leaving my subnet if at all anything more so whats the threat model for a local only service?
You don't need to enable HTTPS for those use cases. Your Plex and Nextcloud will work just fine.
If you configure your server to send a HSTS header, though, you're telling your browser to only trust HTTPS connections for that domain from then on. That's what's happening here, and that's something you just… shouldn't do, I guess? If I tell my browser to permanently redirect localhost to Google.com, there's no reason why I should be mad at my browser for listening to my perma redirect.
HTTP traffic is a bigger problem in huge, flat, corporate networks, running intranet services with routes spanning several locations. At any time a hacker could be listening in an exfiltrating company logins. Also think about the Snowden slides, where the NSA intercepted unencrypted traffic over Google's internal network. Local network encryption is essential in those use cases and relatively easy to set up.
That's not localhost. One threat model is some IoT device you have attached to your wifi gets hacked. Or your wifi has a weak password and it gets hacked. Or a guest that you let onto your wifi has a devices that's been hacked.
look, isnt the responsibility of preventing coffee maker from accessing your local data on the admin?
>So it's an unlikely threat model for most people, but it is real.
today, what kind of local network service can a person set up that people can intercept and snoop on? its not like i am talking about accessing payment gateways or anything, just local services. if there is something that "needs" security, dont you think the technically inclined would have it on that and leave the rest as is because its a bit more effort for what benefit?
It’s solving a very real problem for enterprises. They want to run local agents that serve up content with a cert chained to an installed trusted corp ca. In general localhost is a pain to reason about security-wise —- the best approach is to simply kill it (despite my personal nostalgic love for it.) Use a proxy instead and forget it exists — enterprise is now the owner of that domain.
Local agents can serve up content with proper domain names, which can resolve to anything, including 127.0.0.1. There’s exactly zero reason to use the insane setup of HTTPS + HSTS with localhost.
Plus, what’s the benefit of encrypting on a loopback connection? Who’s intercepting?
I'd be very annoyed if I were troubleshooting HTTPS/HSTS bugs and found out that certain headers were ignored because the target IP is localhost. It makes my life harder for no good reason other than to protect those who misconfigure their webserver from their own mistakes.
You have that backwards. Parent was stating internal domain names can resolve to 127 to enable HSTS. Specifically using "localhost" should be the exception, not the resolution of 127. you could shove securehost in /etc/hosts as 127.0.0.1 to turn on HSTS for example.
Let me tell you a secret: They're all just the same browser. Every enterprise policy applies to consumer Chrome installs. The only real difference is that consumers often get a user-folder-installed version which annoyingly doesn't require admin rights to install, and businesses generally properly deploy an MSI file that installs to Program Files.
