potential issues with https sites / https gateway

[notslang]

When this is used with an https site & https gateway, it throws a mixed content error, like:

Blocked loading mixed active content "http://localhost:8080/ipfs/QmSSPK25wLZ7JmJ2qE6ECK5veiTHVD7UVze9Nx6LB2o681/jquery.min.js"

...Since localhost is on http. Obviously loading from localhost via http is fine, since it never actually goes over the network, but firefox will throw an error anyway.

Also, this isn't an error with the current version, but rather a problem that arises if it is modified and a gateway other than http://gateway.ipfs.io is used, or if gateway.ipfs.io supports https in the future.

[lidel]

In Ideal world, the addon should white-list local gateway URL/domain so that mixed-content is accepted for localhost connections. Done.

Sadly, Firefox only enables user to disable this protection globally: about:config → security.mixed_content.block_active_content → false
This can be automated via Toggle Mixed Active Content Addon, but that is still a global ON/OFF switch. We could ship similar feature with the ipfs addon, but playing with this global flag does not seem like a good Idea: it will degrade security of regular sites, and is only Firefox-specific.
And yes, there was a long ticket for adding a mixed-content white-list functionality to Firefox but it ended up as WONTFIX. I'd say it is a lost cause, and we need to look for a solution outside of a browser.

Right now we can solve this for all browsers by putting HTTPS-enabled reverse proxy in front of go-ipfs (eg. nginx), but this requires additional setup.
Perhaps a better way to handle this would be for go-ipfs to provide HTTPS endpoint by itself (with auto-generated self-signed certificate by default). This would instantly secure gateways that are shared between multiple users in LAN networks without need for nginx.
If so, we should move this conversation to https://github.com/ipfs/go-ipfs/issues/

Including @dylanPowers, as this probably impacts ipfs-chrome-extension too.

[notslang]

Hmm... wouldn't a self-signed cert still require the user to manually accept the cert within Firefox? Or can/should we do that programmatically?

One idea that I had was to setup an ipfs:// protocol handler that is configured to allow loading in any security context. And then that protocol handler would just proxy all the requests to localhost:8080. I'm a bit new to writing Firefox addons, so I'm not certain that it would work, but that's what I'm experimenting with right now.

[lidel]

1. Manual white-listing of self-signed certificate is required only once: should be fine for now.
   I've found some samples about adding custom certificates to Firefox's trust store, but did not dig deep enough to confirm this is what we need to solve this issue.
2. The ipfs:// protocol is supported but for clarity's sake it is redirecting instead of proxying. This is on purpose. Canonical IPFS policy for URLs is to go with unix-like /ipfs/ notation (see Support website hints to reroute HTTP query to IPFS #16 (comment)). URIs starting with /ipfs/ are not supported by this addon yet. I've stumbled upon some issues described in Support unix-like URI /ipfs/ in address bar #13 (comment), so right now it uses raw gateway address as a canonical URL in address bar.
   That being said, supporting /ipfs/ is on the TODO list (Support unix-like URI /ipfs/ in address bar #13)
3. Keep in mind that I am also new to Firefox addons. I did a quick search and was unable to find APi for disabling mixed-context only for a specific URL/protocol, but if you have time feel free to tinker around this :-)

[danielmotaleite]

humm... so if i create a clone site from bigbank.com, put it in ipfs, you will be able to see a "https" enabled phishing site
Maybe some digital signatures to the files and the browser/extension could verify then?
anyway, i sense that this is a big problem as is a parallel way to deliver data

[lidel]

Yes, but you can do the same in pure HTTP: trusting https://ipfs.io/ipns/bigbank.com is just like trusting https://bigbank.com.foo.com (with a valid certificate for *.foo.com). Phishing always works (even with TLS), because people do not keep/compare fingerprints.

IPFS HTTP gateway is.. a gateway. HTTPS was not designed with IPFS in mind, and using TLS with gateway does not provide any authentication, only basic encryption.

IMO authentication is provided by IPFS: hash of the root element in IPNS resource does match the one in DNS TXT record.
I feel this is more secure than putting FQDN in Common Name of a TLS certificate (which can be minted by Root CA employees without your consent).

[notslang]

@lidel: using HTTPS with an IPFS gateway is still a good idea, because it prevents people from listening in on your connection and recording your browsing history. IPFS already prevents them from modifying data in-transit, so it's not quite as useful, but if you're actually passing over a network (not just connecting to localhost) then it's a good idea to have HTTPS.

@danielmotaleite: If bigbank.com was an IPFS-based site (designed to be immutable and fully separated from the banking API that it uses), it wouldn't matter which domain you host it on... Unless the site uses relative links: those could break or point to unintended resources when the domain is changed. But besides that, you would be able to ensure that you have a valid copy of the banking site, no matter who you get it from, just by checking the hash.

[the8472]

With custom protocols (#70, #48) we could add the necessary flag to allow embedding:

Also left a note in protocols.js

[lidel]

Closing this one, we continue the "HTTP/HTTPS mixed-content" discussion in:

• Prevent mixed content warnings for TLS sites embedding ipfs URIs #75