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

Redirecting .ETH/ -> .ETH.LINK should use HTTPS instead of HTTP #841

Closed
DavidBurela opened this issue Feb 5, 2020 · 2 comments · Fixed by #847
Closed

Redirecting .ETH/ -> .ETH.LINK should use HTTPS instead of HTTP #841

DavidBurela opened this issue Feb 5, 2020 · 2 comments · Fixed by #847
Assignees
Labels
kind/bug A bug in existing code (including security flaws) topic/security Work related to security

Comments

@DavidBurela
Copy link

Platform:
Windows
Microsoft Edge / Chrome,

Issue
Navigating to almonit.eth/ redirects to http://almonit.eth.link/

Expected result
It should redirect to https://almonit.eth.link/

Defaulting to HTTPS makes sense, as .eth.link supports HTPS, and Edge/chrome will start warning that http sites are unsafe.

@DavidBurela DavidBurela changed the title Redirecting .ETH/ to .ETH.LINK should use HTTPS instead of HTTP Redirecting .ETH/ -> .ETH.LINK should use HTTPS instead of HTTP Feb 5, 2020
@DavidBurela
Copy link
Author

DavidBurela commented Feb 5, 2020

If I had to take a wild guess of what needs to be updated, I would think it is this line.
I don't have an environment set up to do extension development, otherwise I'd attempt creating a PR for this

https://github.com/ipfs-shipyard/ipfs-companion/blob/c3f4c531514522bf11ca74ce878051480f8ad773/add-on/src/lib/ipfs-request.js#L409

@lidel lidel self-assigned this Feb 14, 2020
@lidel lidel added kind/bug A bug in existing code (including security flaws) topic/security Work related to security labels Feb 14, 2020
lidel added a commit that referenced this issue Feb 14, 2020
@lidel
Copy link
Member

lidel commented Feb 14, 2020

Thank you @DavidBurela, fixed in #847

There is a small caveat to this:

Limitation of wildcard certificate at *.eth.link

@chris-remus FYI there is an open issue with HTTPS on *.eth.link – is there an open issue for this somewhere? If not, where I can report below?

Gateway at eth.link uses LetsEncrypt certs that work only with *.eth.link and will fail for *.*.eth.link.

For example https://blog.khinsen.eth.link/ (loaded without ipfs-companion) produces certificate validation errors in both Firefox and Chromium. User can manually bypass the error and page will load fine, but its bad UX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws) topic/security Work related to security
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants