[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

Luca Cipriani <l.cipriani at arduino.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |l.cipriani at arduino.cc

--- Comment #18 from Luca Cipriani <l.cipriani at arduino.cc> ---
Hello, Arduino officially speaking here.

We do have a system that HAS to interact with a local server: https://github.com/arduino/arduino-create-agent

This agent is installed already in a couple hundred thousand devices. Due to the blocking of 127.0.0.1 by webkit we are forced to create a Certificate Autority for Localhost and install it in the certificate chain, this is much worse than just allowing http://127.0.0.1/ (then obviously we remove the CA key permanently)

if you read the w3c specs in details you can see that 127.0.0.1 is considered a priori authenticated and indeed this is what both Firefox and Chrome do, they just respect the w3c specs and do not think they are better than the committee 

Again here:
https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy
is correctly stated:
If origin’s host component matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632], return "Potentially Trustworthy".

So you are hereby declaring you do not want to comply to w3c specs which is a bit *strange* for a browser engine.

127.0.0.1 is trusted because it is the same network device of the user and the app has to call it (eventually with all the CORS option needed) and is responsible for calling the right server.

In addition to that Firefox devs did a great job I think: https://dxr.mozilla.org/mozilla-central/source/dom/security/nsMixedContentBlocker.cpp#744

Now coming to your questions:

1. that only happens if the website explicitly calls a server in localhost, so there will some form of verification I hope, anyway it should not be a problem of the web engine to eventually block this apps but delegated to the web developer.

2. false, can only be done if the website which is calling localhost is passing some info, the master application is fully under control about the data will send to the 127.0.0.1:port application. 

3. you should only allow 127.0.0.1 instead of localhost, I can agree on this.

4. Consider by TLS/SSL specification there is no way to create a valid https certificate for localhost nor for 127.0.0.1 (obviously, and that is good).

5. Please provide any other alternative to this very usual scenario: you have a web app that has to talk via http to a local device to (as Arduino does) connect the web page to a serial monitor or a USB device. Consider WebUSB is a draft: https://wicg.github.io/webusb/
and WebSerial does not really exists as of now.

6. So please, can you just try to respect public specifications? Users based their application on w3c specs.

Thank you,

Luca

(In reply to Brent Fulgham from comment #14)
> I do not support this requested change in behavior. Allowing HTTP from
> localhost to be included in a secure page is a terrible idea for a few
> reasons:
> 
> 1. There is no guarantee that the server being used is the one the page
> content was expecting to connect to. E.g., a trojan server running as part
> of an application you installed intercepts file transfer information when
> you go to an external cloud storage server site.
> 
> 2. Content served through the local HTTP server can pull insecure
> information from anywhere on the internet, serve it to the hosting page, and
> completely undermine the protections HTTPS is supposed to provide.
> 
> We should do more to block this kind of poor design, not encourage it.

-- 
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/20180523/b1a78a84/attachment.html>