Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
the8472 opened this issue Feb 14, 2016 · 7 comments
Closed

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

the8472 opened this issue Feb 14, 2016 · 7 comments
Labels
kind/discussion Topical discussion; usually not changes to codebase status/blocked/missing-api Blocked by missing API status/blocked/upstream-bug Blocked by upstream bugs topic/security Work related to security

Comments

@the8472
Copy link
Contributor

the8472 commented Feb 14, 2016

Adding nsiProtocolHandler.URI_SAFE_TO_LOAD_IN_SECURE_CONTEXT to the handlers should allow the URI schemes to be used to load subresources into secure contexts.

Public gateways use TLS anyway and thus can already be embedded as 3rd party content. Private gateways hopefully are under control of the user / in a trusted network.

@lidel lidel added kind/maintenance Work required to avoid breaking changes or harm to project's status quo topic/security Work related to security labels Feb 14, 2016
@lidel
Copy link
Member

lidel commented Feb 14, 2016

I am okay with adding the flag: content-addressing provides better protection against MITM than TLS anyway (as long as user controls the gateway).

We probably need to add a new section to SECURITY.md and explicitly advise people against use of custom gateways outside of their control.

I am worried we don't see all security implications. Perhaps we should add this as a separate preference (disabled by default):
"Allow resources from HTTP Gateway to be loaded in HTTPS contexts"

@lidel lidel added the help wanted Seeking public contribution on this issue label Feb 14, 2016
@lidel lidel added kind/discussion Topical discussion; usually not changes to codebase and removed kind/maintenance Work required to avoid breaking changes or harm to project's status quo labels Feb 14, 2016
@lidel lidel added this to the v1.6.0 milestone Feb 14, 2016
@Kubuxu
Copy link
Member

Kubuxu commented Jun 15, 2016

It would be great to have this, currently for example https://ipfs.pics doesn't work on the redirect, one has to use http version which is much much worst.

Also FF people are considering making all localhost as trusted content, only opposition are those who want to block browser off localhost completely. https://bugzilla.mozilla.org/show_bug.cgi?id=903966

@lidel
Copy link
Member

lidel commented Jun 20, 2016

@Kubuxu

https://ipfs.pics doesn't work on the redirect

I tried to replicate, but https://ipfs.pics/QmR48aP79GaXfs5rh469kAJw9wDLA5yYrcgsL5gyuQjmBe loads http://127.0.0.1:8080/ipfs/QmR48aP79GaXfs5rh469kAJw9wDLA5yYrcgsL5gyuQjmBe just fine, the only drawback is mixed-content warning:

2016-06-20-204825_328x35_scrot

Am I missing something?

@Kubuxu
Copy link
Member

Kubuxu commented Jun 20, 2016

Hmm, I thought it was blocking the mixed content completely but it looks like it works now.

Sorry for that.

@lidel lidel added the status/blocked/missing-api Blocked by missing API label Aug 6, 2016
@lidel lidel removed this from the v1.6.0 milestone Sep 14, 2016
@lidel
Copy link
Member

lidel commented Apr 3, 2017

Update via Bug 903966 - Don't block mixed content from localhost:

According to the spec, content from loopback addresses should no longer
be treated as mixed content even in secure origins. See:

Note that we only whitelist '127.0.0.1' and '::1' to match Chrome 53 and
later. See:

@lidel lidel added status/blocked/upstream-bug Blocked by upstream bugs and removed help wanted Seeking public contribution on this issue labels Jul 22, 2017
@lidel
Copy link
Member

lidel commented Jul 22, 2017

I just confirmed that there is no "mixed content" warning under Firefox 56 when using local (127.0.0.1) gateway.

@lidel lidel closed this as completed Jul 22, 2017
@ivan386
Copy link

ivan386 commented Aug 7, 2017

I install stunnel on 8443 port and make certificate for 127.0.0.1 and other domains. Root certificate (rootcert.pem or rootcert.crt) need to be added to trusted certificate repository. Then site can detect by JavaScript that local gateway available on 8443 port and switch to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/discussion Topical discussion; usually not changes to codebase status/blocked/missing-api Blocked by missing API status/blocked/upstream-bug Blocked by upstream bugs topic/security Work related to security
Projects
None yet
Development

No branches or pull requests

4 participants