Does anyone have an idea of how good browser support is for the W3C Secure Contexts standard? Could it be that vendors are abusing certificates in this way in order to get around communications with loopback addresses being blocked as insecure mixed content by non-conforming browsers?
On Wed, Jun 21, 2017, 4:59 AM Ryan Sleevi <r...@sleevi.com> wrote: > 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
