Mixed Content Warning when using localhost Gateway

[lidel]

This one is kind of Rube Goldberg machine, so I'll start with a bit of background information.

Mixed Content warning happens when a page loaded over HTTPS contains a resource (eg. image) that is loaded from insecure HTTP. Browser vendors recognized that loading content over unencrypted HTTP from the box browser is running on is a special case that provides similar security guarantees to HTTPS over the internet, so they whitelisted 127.0.0.1 and it no longer trigger the warning.

IPFS Companion defaults to using localhost instead of 127.0.0.1 since #291 was closed. To be more specific, if user enters gateway URL that includes 127.0.0.1 it will be replaced with hostname localhost.

The goal was to improve UX in Location Bar (localhost looks much better than raw IP), but it came with unexpected side effect regarding Mixed Content whitelisting implemented in Firefox and Chrome. It seems that browsers whitelisted 127.0.0.1 but not localhost, which still produces Mixed Content warning.

In our use case, the Mixed Content Warning is triggered when there is an IPFS resource on HTTPS page and ipfs-companion's redirect loads it from Local Gateway that has localhost in its URL.

---

(I used pls.watch as a PoC in examples below, because it is a public HTTPS site that enables users to trigger Mixed Content Warning by loading external resources from HTTP URLs)

127.0.0.1 (O.K.)

Firefox: the green padlock

Chrome: the green padlock + "Secure"

localhost (Mixed Content Warning)

Firefox: grey padlock with warning

Chrome: no padlock, warning under (i) icon

---

For now, we need to decide what is more important:

• keeping human-readable localhost in Location Bar at a cost of signaling that use of local IPFS gateway is somehow "not secure"

or

• keeping "the green padlock" at a cost of going back to 127.0.0.1 in location bar.

Personally, I think "keeping the green padlock" is more important and we should go back and default to 127.0.0.1. Rationale: we can work with browser vendors to whitelist localhost and switch back to it at a later time, when it does not cause Mixed Content Warning.

I am usually biased towards security over UX, so would love to hear what others think before doing any changes.

---

References:

• https://bugzilla.mozilla.org/show_bug.cgi?id=903966 (Firefox whitelists 127.0.0.1 since v55)
• https://chromium.googlesource.com/chromium/src.git/+/130ee686fa00b617bfc001ceb3bb49782da2cb4e (Chrome whitelis 127.0.0.1 since v53)

[ghost]

I think the OS is a concern we should doublecheck -- I know that both FF and Chrome have been pretty inconsistent on multiple vectors when it comes to IPv6 DNS (changed behaviour over time, different behaviour on different OSes, config flag removals). This in particular doesn't directly affect what we're doing, it's just something to check.

Otherwise sounds good to me!

[lidel]

@lgierth yeah, after I created this issue started playing with ::1 and found various edge cases that need to be tested/addressed first, so I removed note about ipv6 from this issue to keep it on topic.
Will get back to it in separate issue, for now its safer to default to ipv4 (127.0.0.1).

[olizilla]

I'm in favour of switching back to 127.0.0.1 and fixing the mixed content warning.

[lidel]

Alright, this change landed in v2.1.1beta6 🌵

[feilongfl]

same problem here,my website https://musing-pare-9e8d81.netlify.com/

it show me that

Mixed Content: The page at 'https://musing-pare-9e8d81.netlify.com/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://feilong-server.lan:8080/ipns/feilong.ml/comic.json'. This request has been blocked; the content must be served over HTTPS.

[lidel]

For the record, this changed at some point and
https://pls.watch/#i=http://localhost:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR now works in both Chrome 78 and Firefox 69 without mixed-content warnings:

We should flip normalization, as localhost looks much better than raw IP.
PR: #780