DNS leak when browser is set to use DoH or a proxy

[Snawoot]

I've tried to reach authors via email provided in security policy for such reports, but I haven't received any response after two attempts. First attempts was made on 12 of June.

Description

Once enabled, IPFS Companion browser extension leaks some domain name requests via requests to local IPFS gateway on DNS resolve endpoint.

It violates user privacy in cases when direct DNS requests are unacceptable. Namely:

• When DoH enabled.
• When DNS requests are supposed to be performed on remote HTTP/HTTPS/SOCKS5 proxy (configured manually or by a 3rd party VPN browser extension).

In fact, it breaks user's anonymity and confidentiality of some requests.

It's likely that such behavior violates Add-on Policies defined for Firefox extensions (see "compromises user privacy" in "Unexpected Behavior") and Google Chrome Web Store Developer Agreement
(4.3 - privacy statement and 4.4.1.3 - interference with other network services and browser extensions).

To Reproduce

Steps to reproduce the behavior:

1. Install IPFS Companion on any supported browser.
2. Set browser to use SOCKS5 proxy with remote resolve or HTTP proxy or HTTPS proxy or DoH.
3. Do a test on https://browserleaks.com/ip
4. Observe DNS leaks in test results or in query log of DNS forwarder in your local net.

Expected behavior

No DNS leaks.

Screenshots

Dump of requests to local IPFS gateway from browser extensions:

Excerpt from query log of DNS forwarder on local network:

Desktop:

• OS: GNU/Linux (Fedora 32)
• Browser: Chromium (81.0.4044.138-1.fc32.x86_64) and Firefox (77.0.1-2.fc32.x86_64)
• Extension version: 2.13.1 (both Chromium and Firefox)

Additional context

PCAP file:

ipfs-companion.pcap.gz

Excerpt from query log of DNS forwarder on local network:

query.log

[jessicaschilling]

@Snawoot Thank you for filing this - confirming that it’s been received and seen.

[lidel]

Thank you @Snawoot for the very thorough and clear report.
Below is my quick analysis of situation and potential next steps.

Clarification: go-ipfs leaks, not Companion

When go-ipfs opens /ipns/example.com it does DNSLink lookup internally, so even if Companion did not call /api/v0/dns at go-ipfs, the leak would still happen.

Just to be very clear, the "DNS leak" happens when:

• user EXPLICITLY does not want to use DNS resolver provided by their own operating system, and either:
  • manually enables DoH (DNS over HTTPS) in their browser (which disables use of DNS resolver provided by the OS)
  • manually enables proxy (delegating DNS lookups to the proxy)

It is a problem for mentioned setups, but for regular user with a browser that uses DNS resolver provided by the operating system there is no decrease of privacy (browser already does DNS leak for every visited website anyway).

That being said, browser vendors start to experiment with enabling DoH, and when that is enabled, we would indeed decrease privacy for default setups, which is a significant concern.

Why /api/v0/dns is called?

IPFS Companion checks if DNSLink exists to display IPFS integrations. Sadly there is no WebExtension API that would enable our extension to do DNS TXT record lookups using DoH configured in the browser. That is why we use /api/v0/dns in go-ipfs (assuming that user trusts their own DNS resolver).

Upstream issue for Firefox exists, but it is highly unlikely that we will see something like that any time soon in both Chromium and Firefox.

Mitigation

I see two ways to close the leak without changing anything in IPFS Companion or go-ipfs:

(M1) Disable DNSLink lookup when using DoH or proxy

Quick mitigation for those use cases is to disable DNSLink lookups in Preferences:

(M2) Run local caching server that forwards queries over TLS

Alternative is to run local DNS caching server configured to uses TLS. Example of relevant config for unbound:

forward-zone:
        name: "."
        forward-tls-upstream: yes
        # Cloudflare DNS
        forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
        forward-addr: 1.1.1.1@853#cloudflare-dns.com
        forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
        forward-addr: 1.0.0.1@853#cloudflare-dns.com
        # Quad9
        forward-addr: 2620:fe::fe@853#dns.quad9.net
        forward-addr: 9.9.9.9@853#dns.quad9.net
        forward-addr: 2620:fe::9@853#dns.quad9.net
        forward-addr: 149.112.112.112@853#dns.quad9.net

Potential ways of fixing underlying problem

(S1) Configurable DNS in go-ipfs

Configurable DNS and DoH support in go-ipfs is tracked in: ipfs/kubo#6532
If we used DoH for DNSLink lookup in go-ipfs by default, and made it possible for user to change DoH server, it should be enough. Both internal provessing and /api/v0/dns would use DoH, and there would be no leaking.

(S2) Configurable DNS in ipfs-companion

Implement DoH in IPFS Companion. Use a trusted DoH server for all DNSLink lookups and make it possible to configure DoH server in Companion Preferences screen.

Useful notes on binary format in DoH can be found in ipfs/helia-ipns#53, but I am not sure if going this route makes sense. Even if Companion uses DoH and does not leak anything, when request for /ipns/example.com is redirected to localhost gateway go-ipfs will do the DNSLink lookup itself, defeating the leak protection in Companion.

This means we need S1, as it makes both internal and external lookups to go over DoH.

Summary

I believe S1 is the only viable fix I see atm, so this is blocked by upstream ipfs/kubo#6532

For now, we will update Companion's Privacy Policy and add a section that explicitly documents privacy considerations related to DNSLink support: #901

---

Let me know if I missed anything, or if you see a better way of tackling this that was not considered above in S1/S2 – feedback would be really appreciated.

[Snawoot]

I agree S1 is preferable. Apart from S2 downsides, there are additional reasons why it's better to have some sort of secure DNS precisely in go-ipfs:

• No protocol limitation. You may use plain DNS, DoT, DoH and DNSCrypt. Here is example of such software in Go with multi-protocol upstream DNS support. Amount of code responsible for interaction with all sort of upstreams is not too big: about 1.5k LOC with tests.
• Finer control over implementation. There are no concurrency limits, no browser limits etc.
• go-ipfs itself may have some benefit from incorporating secure DNS client. It may be useful in cases when bootstrap servers censored via DNS filtering and/or if you want to push fresh bootstrap nodes via floating DNS name.

[RubenKelevra]

Snawoot wrote:

[...] there are additional reasons why it's better to have some sort of secure DNS precisely in go-ipfs:

• No protocol limitation. You may use plain DNS, DoT, DoH and DNSCrypt. Here is example of such software in Go with multi-protocol upstream DNS support. Amount of code responsible for interaction with all sort of upstreams is not too big: about 1.5k LOC with tests.
• Finer control over implementation. There are no concurrency limits, no browser limits etc.
• go-ipfs itself may have some benefit from incorporating secure DNS client. It may be useful in cases when bootstrap servers censored via DNS filtering and/or if you want to push fresh bootstrap nodes via floating DNS name.

Sorry for the off-topic.

Correct me when I'm wrong, but:

We also need a secure DNS to have a trusted anchor to mitigate any MITM-Attacks. Since signature verification on DNS queries is basically still in its infancy and only very few domain providers actually support DNSSEC anyway.

If we use plain text DNS requests and don't do any signature verification OR the domain has no DNSSEC information stored, we don't have any security for the content similar to a page that gets loaded over HTTP.

It would be nice if we could do at least secure DNS requests for any DNSLink request until DNSSEC validation is more feasible.

I added a ticket for DNSSEC validations of DNSLinks: #970

[SgtPooki]

grooming meeting notes: @SgtPooki to look at this and ensure labels/priority/etc are accurate.