On Wednesday, June 21, 2017 at 1:43:18 AM UTC-5, jacob.hoff...@gmail.com wrote: > > 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.
I believe the underlying issue for many of these cases pertains to initiating a connection to a WebSocket running on some port on 127.0.0.1 as a sub-resource of an external web page served up from an external public web server via https. I believe that presently both Firefox and Chrome prevent that from working, rejecting a non-secure ws:/ URL as mixed content. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
