Why is mixed content allowed on http://127.0.0.1?

[John Mellor]

Loopback IP addresses (e.g. http://127.0.0.1 and http://[::1]) are defined to be Potentially Trustworthy origins, and hence are allowed access to sensitive APIs like Geolocation that are only allowed on Secure Contexts to avoid inadvertently leaking information.

But Mixed Content checks are skipped on non-HTTPS pages. So http://127.0.0.1 can happily load scripts from http://insecure-cdn.com, or post the user's geolocation to http://insecure-api.com, even though such requests leak information from a secure context to a non-secure context.

Are we comfortable with this? If not, is there any path to fixing this without frustrating developers too much (it might unfortunately be common for http://127.0.0.1 to make requests to http: staging servers)?

Thanks,

John

[Eric Lawrence]

Interesting point.

The loading of scripts from non-secure CDNs does seem like a source of concern, although I don't know how we could practically address that without making localhost so cumbersome that it defeats the point of treating it as potentially trustworthy. 

(Both Secure or Potentially Trustworthy origins can already POST any data it has to any non-secure endpoint, because Mixed Content checks don't govern navigations.)

-Eric

[John Mellor]

> The loading of scripts from non-secure CDNs does seem like a source of concern

To make matters worse, protocol relative URLs like <script src="//cdn.com/jquery.js"> will presumably load the script over http. HTML Boilerplate recommended this pattern until 2015. Perhaps a first step would be to treat protocol relative URLs as https on http://127.0.0.1 and friends?

> (Both Secure or Potentially Trustworthy origins can already POST any data it has to any non-secure endpoint, because Mixed Content checks don't govern navigations.)

Well, forms with a mixed content action are treated as passive mixed content since crbug.com/253249 / crrev.com/311033003

(see https://www.o2.co.uk for an example). And the use counters added in that patch are encouraging: Blink.UseCounter.Features MixedContentFormsSubmitted occurs on only 0.03% of PageVisits, which is the right order of magnitude to start considering deprecation.

[Mike West]

On Wed, Aug 2, 2017 at 6:20 PM, Eric Lawrence <elaw...@google.com> wrote:

Interesting point.

The loading of scripts from non-secure CDNs does seem like a source of concern, although I don't know how we could practically address that without making localhost so cumbersome that it defeats the point of treating it as potentially trustworthy. 

I agree both that it's a concern, and that I don't think there's much we can do about it in the short term without breaking developer expectations. I'd certainly be interested in any concrete suggestions you've got, but it seems like blocking `http://...` requests from `http://127.0.0.1/` would break things developers are relying on today, even if they're not relying on the security of the context.

I suppose we could add some metrics to see how often loopback pages load resources from non-loopback endpoints, and how often those resources are non-secure. I suspect the number would be high, but maybe it's not?

(Both Secure or Potentially Trustworthy origins can already POST any data it has to any non-secure endpoint, because Mixed Content checks don't govern navigations.)

Right. Top-level navigations aren't mixed content, so these pages can leak data via `window.open()`, `window.location.href`, `<form>`, etc.