4 ms·

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

by ornxka 4y ago

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.

dinosaurdynasty 4y ago
This sounds like if you create a custom CA, import it, create a cert for localhost, and then connect Chrome to https://localhost 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.
- throw1230 4y ago
  > 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.
  - remram 4y ago
    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.
  - aaronmdjones 4y ago
    > 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.
- deleted 4y ago
  [deleted]
matthewaveryusa 4y ago
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.
- zarzavat 4y ago
  How about no? Enterprise can use Chrome for Enterprise. Why are they using a consumer browser?
  - ocdtrekkie 4y ago
    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.
    - marcosdumay 4y ago
      So, now there's a good reason for them not to be the same browser, but rather be the same executable, but with different default settings.
- oefrha 4y ago
  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?
  - jeroenhd 4y ago
    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.
oefrha 4y ago
> 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.
2Gkashmiri 4y ago
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"
- yjftsjthsd-h 4y ago
  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:)
  - Thorrez 4y ago
    >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 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.
    - 2Gkashmiri 4y ago
      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? also, i am not talking about "critical infra"
deleted 4y ago
[deleted]
aaronmdjones 4y ago
Wait, Chrome is now requiring HSTS for localhost? If you point it at https://localhost/ 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.
- Already__Taken 4y ago
  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.

by ornxka 4y ago

dinosaurdynasty 4y ago

This sounds like if you create a custom CA, import it, create a cert for localhost, and then connect Chrome to https://localhost 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.

throw1230 4y ago
> 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.
- remram 4y ago
  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.
- aaronmdjones 4y ago
  > 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.
deleted 4y ago
[deleted]

matthewaveryusa 4y ago

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.

zarzavat 4y ago
How about no? Enterprise can use Chrome for Enterprise. Why are they using a consumer browser?
- ocdtrekkie 4y ago
  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.
  - marcosdumay 4y ago
    So, now there's a good reason for them not to be the same browser, but rather be the same executable, but with different default settings.
oefrha 4y ago
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?
- jeroenhd 4y ago
  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.

oefrha 4y ago

> 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.

2Gkashmiri 4y ago

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"

yjftsjthsd-h 4y ago
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:)
- Thorrez 4y ago
  >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 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.
  - 2Gkashmiri 4y ago
    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? also, i am not talking about "critical infra"

deleted 4y ago

[deleted]

aaronmdjones 4y ago

Wait, Chrome is now requiring HSTS for localhost? If you point it at https://localhost/ 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.

Already__Taken 4y ago
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.