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.
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.
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.
Wait, Chrome is now requiring HSTS for localhost?
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.
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.
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"
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:)
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.
that data wont be leaving my subnet if at all anything more so whats the threat model for a local only service?
also, i am not talking about "critical infra"
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.
>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?
Plus, what’s the benefit of encrypting on a loopback connection? Who’s intercepting?