SSL cert problems accessing dweb.link with IPNS
eminence opened this issue · comments
Hi all, I believe I have the right home for the issue, but if not, please redirect me as needed.
I believe the following URL should work: https://dweb.link/ipns/ipfs.io/
The official docs seem to suggest an IPNS url like this is allowed.
When loaded in Chrome 86 on Windows 10, I get this message from chrome:
Your connection is not private
Attackers might be trying to steal your information from ipfs.io.ipns.dweb.link (for example, passwords, messages, or credit cards). Learn moreNET::ERR_CERT_COMMON_NAME_INVALID
ipfs.io.ipns.dweb.link normally uses encryption to protect your information. When Google Chrome tried to connect to ipfs.io.ipns.dweb.link this time, the website sent back unusual and incorrect credentials. This may happen when an attacker is trying to pretend to be ipfs.io.ipns.dweb.link, or a Wi-Fi sign-in screen has interrupted the connection. Your information is still secure because Google Chrome stopped the connection before any data was exchanged.
And trying on Firefox 82 on the same Windows 10 machine, I get this message:
Did Not Connect: Potential Security Issue
Firefox detected a potential security threat and did not continue to ipfs.io.ipns.dweb.link because this website requires a secure connection.
Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for ipfs.io.ipns.dweb.link. The certificate is only valid for the following names: *.i.ipfs.io, *.ipfs.dweb.link, *.ipfs.io, *.ipns.dweb.link, dweb.link, ipfs.io
Error code: SSL_ERROR_BAD_CERT_DOMAIN
The message from Firefox is especially confusing since it certainly looks like ipfs.io.ipns.dweb.link matches the wildcard *.ipns.dweb.link
Thanks!
Hi @eminence,
thanks for the report! I believe this is a known bug, but I can't find the ticket. I suspect if I say @lidel's name three times, he just might appear with some context. :)
The message from Firefox is especially confusing since it certainly looks like ipfs.io.ipns.dweb.link matches the wildcard *.ipns.dweb.link
One of the "fun" quirks of DNS is that wildcards only work for that 1 level and but not multiple levels (sub-subdomains). The wildcard cert we have for *.ipns.ipfs.io would be valid (but not functional) for just ipns or io, but not ipns.io. Note: browsers do not support a super-wildcard cert like *.*.ipns.ipfs.io or similar.
So the browser errors are to be expected given the domain we redirect to. That said, we shouldn't be redirecting to such a domain. It should be a <cid> of the ipns record (or somesuch).
It might make sense to move this to go-ipfs repo, but I'll hold off on moving for now.
Ahh, I see. That is indeed a fun little quirk, though a bit disappointing. I guess in theory the redirection would be OK over http, but since dweb.link has HSTS, that's not relevant here. Turns out getting IPNS, HTTPS, and custom domains is a bit challanging!
Many thanks for the info
If you mention me only once, it takes longer, but I will appear anyway! ;)
Indeed, it is unfortunate that DNSLink names trigger TLS error.
As @mburns noted, we can't have a certificate for more than a single wildcard level.
Potential solutions/workarounds are listed in ipfs/in-web-browsers#169:
- Personally I find (C) the most pragmatic
- works with existing infrastructure, we would just add support for single-label-encoding to go-ipfs and that is all
- TL;DR idea behind (C) is something like:
https://dweb.link/ipns/my.v-long.example.com→https://my-v--long-example-com.ipns.dweb.link
Note:
- This is not a problem on local gateway at
*.ipns.localhostbecause there is no TLS.- Sidenote: we don't need TLS because localhost addresses do not hit network and should be marked as Secure Contexts. This is already true in Chromium and will be the same in Firefox 84. We are working with Igalia to ensure that is indeed the behavior in all browsers and part of web platform tests (WPT) – recent updates can be found in ipfs/in-web-browsers#109 (comment)
Thanks for appearing with some good info @lidel :) since this is a known issue, I'm happy to close this issue and move the discussion to the two in-web-browsers ticket you linked.
Awesome stuff, thanks all for making this work!