Prevent blocking mixed content from a private networks IP address
Reported by
badia.ni...@gmail.com,
Apr 28 2016
|
||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36
Steps to reproduce the problem:
Open a secure page (HTTPS) and do an an ajax request to a private IP like 192.168.1.10:
var req = new XMLHttpRequest();
req.open('POST', 'http://192.168.0.10');
req.send();
What is the expected behavior?
We're expecting that private network connections without domain names should be considered secure even if loaded using plain HTTP.
What went wrong?
The request is being blocked by the browser's mixed content blocker.
Did this work before? N/A
Chrome version: 50.0.2661.86 Channel: stable
OS Version: OS X 10.10.5
Flash Version: Shockwave Flash 21.0 r0
No being able to do insecure HTTP request from our secure app is a big issue for us because we need to be able to send print request to a local ePOS printer using it's IP.
,
Apr 29 2016
Well, I don't think we're doing to do what's asked for in this bug. There's no reason to treat any old RFC1918 address as secure: "SSL added and removed here" I do think I need to break down and stop being stubborn about 127.0.0.1, though. :/
,
Apr 29 2016
So if our users don't want to have to allow the request manually each time from the shield address bar icon, the only solution for them is to start chrome with the flag: --allow-running-insecure-content This seems to me like a pretty bad thing. The best solution I can think of would be to use a specific CSP rule to allow that. Something like this: Content-Security-Policy: default-src 'self'; connect-src http://192.168.0.10; Is there any reason why this is not working?
,
Apr 29 2016
> So if our users don't want to have to allow the request manually each > time from the shield address bar icon, the only solution for them ... It seems like this boils down to your claim that "private network connections without domain names should [always] be considered secure". I don't think that's a correct assessment of the transport properties. Again, the NSA's "SSL added and removed here" seems like a pretty topical counterexample. If you need to load things from an intranet securely, it seems reasonable to give those things names and certs. Otherwise the data would be flowing in plaintext across the network, which seems reasonable to block as mixed content. > Content-Security-Policy: default-src 'self'; connect-src http://192.168.0.10; CSP doesn't grant a page privileges it wouldn't have otherwise. That policy will ensure that CSP doesn't block the request, but it doesn't have any additional effect on anything else which would block the request.
,
Apr 29 2016
Except that we can't give names and certs to an ePOS printer as far as I know... |
||
►
Sign in to add a comment |
||
Comment 1 by rsesek@chromium.org
, Apr 28 2016Components: Internals>Network
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -OS-Mac OS-All Type-Bug
Owner: mkwst@chromium.org
Status: Assigned (was: Unconfirmed)