[Webkit-unassigned] [Bug 171934] Content from loopback addresses (e.g. 127.0.0.1) should not be considered mixed content

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=171934

--- Comment #59 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Mike West from comment #55)
> > that's what Mike is clearly suggesting that we do, and that's what Firefox and Chrome already do.
> 
> For clarity, Mike is suggesting that y'all first implement the restrictions
> in
> https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02
> such that `localhost` and `*.localhost` always resolve to loopback, and
> never hit the internet (see
> https://cs.chromium.org/chromium/src/net/dns/host_resolver_manager.
> cc?rcl=905e57ccac6951efcfbc514fe33839c6ede4fee2&l=2751 for example). I
> expect this would require CFNetwork changes for macOS, and might not be
> trivially implementable right away.
> 
> I don't think it's safe to treat `localhost` or `*.localhost` as secure
> contexts without that set of restrictions in place, as it's very unlikely
> that developers (or users!) understand that those names might resolve out to
> the internet in some cases.

Of course, with four different network backends, it's hard to guarantee they have all done this, and newer versions of WebKit are certain to be used against older network backends... but we've implemented this guarantee in GResolver a year ago, at your suggestion, so libsoup-based ports should be good: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/616

(In reply to c.goossens from comment #57)
> Hi, we are using this to connect with a user installed application that runs
> a local websocket to stream some data that they entered in the webbrowser to
> their app on request. This currently works in all browsers (as it should per
> spec) by connecting to ws://127.0.0.1:[port].
> 
> Currently this is broken in the latest version of Safari. What's the status
> on this bug report? Will Webkit (and Safari) start following the
> Mixed-Content spec on this issue? Let me know. Thanks in advance.

Nobody is working on this bug report, at least last we heard from Antoine was comment #56. But from comment #46, we see the actual code change here is a one-liner, so this is really just blocked on tests. Maybe review the comments above to see previous discussion on what's needed for the tests. I think we have consensus to accept this change, but the patch would need to include a test and ensure existing tests don't break.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200526/8df5c5ff/attachment.htm>