On Wed, Jun 21, 2017 at 5:32 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 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.
There are several distinct issues: 127.0.0.0/8 (and the associated IPv6 reservations ::1/128) "localhost" (as a single host) "localhost" (as a TLD) The issues with localhost are (briefly) caught in https://tools.ietf.org/html/draft-west-let-localhost-be-localhost - there is a degree of uncertainty with ensuring that such resolution does not go over the network. This problem also applies to these services using custom domains that resolve to 127.0.0.1 - the use of a publicly resolvable domain (which MAY include "localhost", surprisingly) - mean that a network attacker can use such a certificate to intercept and compromise users, even if it's not 'intended' to be. See https://w3c.github.io/webappsec-secure-contexts/#localhost 127.0.0.0/8 is a bit more special - that's captured in https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
