> It's been an on-going question for me, since the use case (as a software > developer) is quite real: if you serve a site over HTTPS and it needs to > communicate with a local client application then you need this (or, you > need to manage your own CA, and ask every person to install a > certificate on all their devices)
I think it's both safe and reasonable to talk to localhost over HTTP rather than HTTPS, because any party that can intercept communications to localhost presumably has nearly full control of your machine anyhow. There's the question of mixed content blocking: If you have an HTTPS host URL, can you embed or otherwise communicate with a local HTTP URL? AFAICT both Chrome and Firefox will allow that: https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e and https://bugzilla.mozilla.org/show_bug.cgi?id=903966. I haven't checked other browsers. Note that you have to use "127.0.0.1" rather than "localhost." See https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03 for why. So I think the answer to your underlying question is: Use HTTP on localhost instead of a certificate with a publicly resolvable name and a compromised private key. The latter is actually very risky because a MitM attacker can change the resolution of the public name to something other than 127.0.0.1, and because the private key is compromised, the attacker can also successfully complete a TLS handshake with a valid certificate. So the technique under discussion here actually makes web<->local communications less secure, not more. Also, as a reminder: make sure that the code operating on localhost carefully restricts which web origins are allowed to talk to it, for instance by using CORS with the Access-Control-Allow-Origin header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
