search

ipfs / ipfs-companion

Browser extension that simplifies access to IPFS resources on the web
https://docs.ipfs.tech/install/ipfs-companion/
Creative Commons Zero v1.0 Universal
2.06k stars 325 forks source link

Proxy DNSLink & ENS sites through go-ipfs when possible. #865

Open Stebalien opened 4 years ago

Stebalien commented 4 years ago

Is your feature request related to a problem? Please describe.

Currently, we redirect DNSLink and ENS sites to http://foo.eth.ipns.localhost:8080. Unfortunately, this leads to an ugly URL. I'd like to see http://foo.eth.

Describe the solution you'd like

I'd like to use the new HTTP proxy support in go-ipfs to preserve the domain name when possible. That is, proxy http://foo.eth through localhost:8080 so the domain in the URL bar looks correct.

Unfortunately, HSTS makes this impossible in some cases. If the site has already been loaded via https:// and sets the HSTS header, we won't be able to visit it via http://....

However:

  1. This will never be the case for .eth domains. This means that, at the very least, we can make .eth support look "native".
  2. We can detect if the site has set HSTS via https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/SecurityInfo.

There's still a downside: localhost is a "secure" origin while "eth" is not. This could break some DApps.

lidel commented 4 years ago

DNSLink :anger:

Doing this for every DNSLink website is hard blocked by:

I don't see any way to make it work.

ENS :thinking:

As you noted, HSTS is not a problem for *.eth, because nobody gives TLS certs for that TLD. The only issue here is the lack of secure context when loaded from go-ipfs-proxied http://foo.eth – I am not sure if this is any factor for ENS users. It is possible they always developed in a secure context due to loading from localhost and/or via https://eth.link gateway, but hard to tell if it will break anything.

:question: So the question is:

@chris-remus would that be beneficial or harmful to ENS?

cc @autonome @parkan

ps1. to mitigate, we could keep manual loads of http://foo.eth.ipns.localhost:8080 working, just so there is a way of loading ENS site with secure context, if needed. Or disable redirect to proxied version via Preferences experiment.

ps2. seems that proxying .eth was mentioned as an option in https://github.com/MetaMask/metamask-extension/pull/7740#issuecomment-586398994, I wonder what happens when two extensions try to register a proxy for the same URL pattern.

lidel commented 4 years ago

Quick demo (requires go-ipfs 0.5.0-rc2 or later):

$ chromium --user-data-dir=$(mktemp -d) --proxy-server="http://127.0.0.1:8080" "http://ipfs.eth"

Explainer: Opening "http://ipfs.eth" over HTTP proxy provided by go-ipfs works fine. It removes the need for DNS lookup of non-existent TLD (go-ipfs will swap .eth to .eth.link and find DNSLink. This works without local Ethereum client: ENS resolution is delegated to https://eth.link service.

MicahZoltu commented 4 years ago

Against foo.eth:

Losing the secure context can definitely be problematic, especially if you have a secure context site that is referencing IPFS assets by ENS name. Imagine someone has a normal HTTPS hosted traditional website, and in it they refer to some content that lives at foo.eth. With the current companion, those requests will be routed to localhost, which is a secure context and thus the content will load. With a change to foo.eth being an insecure context, that content will not load.

For foo.eth

Firefox still doesn't support subdomains as secure contexts, so already foo.eth.localhost is not a secure context for some portion of users. On top of that, until there is much broader browser support for ENS names, one cannot reasonably have a centralized site refer to http://foo.eth because you don't know if your client's browser supports it, and if you are specifically targeting IPFS companion users then you probably are aware of the issues around secure context and have a solution for them.