Opened 12 months ago

Last modified 5 months ago

#30753 new task

Think about using DNS over HTTPS for Tor Browser 9

Reported by: gk Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: arthuredelstein, antonela, mrphs Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor44-can

Description

Right now we have DNS over HTTPS (DoH) not enabled in Tor Browser but we should think about whether we should do that. https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ has some good illustration about this feature

Some pros

  • it cuts out some potential for messing with DNS queries
  • it should help mitigating the DNS proxy leak threat inherent to using a SOCKS proxy
  • it might help with the attacks mentioned in "The Effect of DNS on Tor's Anonymity" (https://nymity.ch/tor-dns/tor-dns.pdf)

...

Some cons

  • it adds a central party seeing all Tor Browser users's DNS requests (even though a lot of DNS queries (about 40%) go to Google already according to the above mentioned paper that's not 100%)
  • it might add latency
  • First Party Isolation of the requests and the cache might need to get added

...

Child Tickets

Change History (18)

comment:1 Changed 12 months ago by cypherpunks

If doing so, please think about using onion services for this. Else you will have a cock and egg problem for resolving the DoH domain first.

Known existing:
https://dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443/dns-query
Reference:
https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over-tor/
https://blog.cloudflare.com/welcome-hidden-resolver/

comment:2 in reply to:  1 Changed 12 months ago by teor

Replying to cypherpunks:

If doing so, please think about using onion services for this. Else you will have a cock and egg problem for resolving the DoH domain first.

But DNS over HTTPS uses an IP address for its server?

comment:3 Changed 12 months ago by arma

What would "using DoH" look like here?

If Tor clients are doing it themselves, then two more cons include:

  • Several more round-trips across the Tor network for each web request, which would seem to be a huge performance penalty.
  • Most every circuit will also include (start with?) a stream to a known destination, which would be...confusing in terms of anonymity but it doesn't strike me as good.

If the exit relays are doing DoH on their own in order to resolve addresses that the clients ask for on the exit circuits, that seems much more workable to me, because it would let the exit relay cache and reuse answers for a while across all requestors, and because it would remove the need for the full Tor network round-trips just to do a resolve. But then it would become a different sort of ticket, more like "encourage Tor exit relay operators to change their local dns resolver to use a DoH option."

Please do tell me that I'm totally missing the obvious reasons why this ticket is a good idea. :)

comment:4 in reply to:  3 Changed 12 months ago by gk

Replying to arma:

[snip]

Please do tell me that I'm totally missing the obvious reasons why this ticket is a good idea. :)

Thinking about this topic and documenting what we thought so we can point folks to it in case the question comes up (and I expect it will because, hey, aren't non-tampered DNS responses a good thing??) seems to me indeed to be a good idea. (which is why the ticket summary and description are phrased as they are) :)

comment:5 in reply to:  3 ; Changed 12 months ago by teor

Replying to arma:

What would "using DoH" look like here?

If Tor clients are doing it themselves, then two more cons include:

  • Several more round-trips across the Tor network for each web request, which would seem to be a huge performance penalty.
  • Most every circuit will also include (start with?) a stream to a known destination, which would be...confusing in terms of anonymity but it doesn't strike me as good.

If the exit relays are doing DoH on their own in order to resolve addresses that the clients ask for on the exit circuits, that seems much more workable to me, because it would let the exit relay cache and reuse answers for a while across all requestors, and because it would remove the need for the full Tor network round-trips just to do a resolve. But then it would become a different sort of ticket, more like "encourage Tor exit relay operators to change their local dns resolver to use a DoH option."

We could also build a DoH library into tor, and use it by default on tor exits.
But I don't know if the ecosystem is there yet. At this time, I'd be worried about single points of failure.

comment:6 Changed 12 months ago by cypherpunks

Just set up DNS MiTM detectors (also with parallel DoH requests) on exit nodes to find out the necessity of this change.

comment:7 in reply to:  5 ; Changed 12 months ago by cypherpunks

Using DoH would NOT longer give EXIT Nodes the Ability to passively learn clear-text domain names of target. Of users using Clients TLS1.3 with ESNI !
DNSPort currently is sadly unreliable and unpredictable and limited to tiny query type set. AAAA lookups randomly fails.

Replying to arma:

What would "using DoH" look like here?

If Tor clients are doing it themselves, then two more cons include:

  • Several more round-trips across the Tor network for each web request, which would seem to be a huge performance penalty.

Example:
https://blog.cloudflare.com/content/images/2018/06/tor.gif

uses Hops reduced Single Onion Services. This way, it is no more hops compared to than using DNSPort. From a Client perspective.

"encourage Tor exit relay operators to change their local dns resolver to use a DoH option."

This is another step forward. Shouldn't this be the default requirement nowadays?

Replying to teor:

Replying to arma:

...

If the exit relays are doing DoH on their own in order to resolve addresses that the clients ask for on the exit circuits, that seems much more workable to me, because it would let the exit relay cache and reuse answers for a while across all requestors, ....

We could also build a DoH library into tor, and use it by default on tor exits.
But I don't know if the ecosystem is there yet. At this time, I'd be worried about single points of failure.

This would be awesome, making exit traffic less passively watchable for targets and good reasons mentioned.

Replying to teor:

Replying to cypherpunks:

If doing so, please think about using onion services for this. Else you will have a cock and egg problem for resolving the DoH domain first.

But DNS over HTTPS uses an IP address for its server?

Well, for example, fireox uses network.trr.uri=https://mozilla.cloudflare-dns.com/dns-query but not the follwing:

network.trr.bootstrapAddress

(default: none) by setting this field to the IP address of the host name used in "network.trr.uri", you can bypass using the system native resolver for it.

This means, the system resolver for mozilla.cloudflare-dns.com is a single point of failure.

For exit servers, someone wants open new ticket as described by teor an arma?
For client, Tor browser already have it builtin. Just set

network.trr.uri=https://dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion:443/dns-query 
network.trr.mode=3

Replying to cypherpunks:

Just set up DNS MiTM detectors (also with parallel DoH requests) on exit nodes...

Hello from another cypherpunks, Would be nice to have to discover more BadExit Nodes too!

comment:8 Changed 12 months ago by cypherpunks

First Party Isolation of the requests and the cache might need to get added

I think this is the most serious requirement.

comment:9 Changed 11 months ago by cypherpunks

DoTN (DNS over Tor Network) is what's needed by Tor Browser (and other clients), i.e. not DNS server/proxy/cache on Tor client as it was before, but DNS service, provided by the Tor network itself (like consensus, etc).

DoH (DNS over HTTPS) might be useful for exit nodes (to exclude MiTM in exit<->DNS server), but as you mentioned you'd like to move the trust zone out of the Tor network (exit nodes), then we'd really have problems with trust! Moving it to SPoF like Google/CF/etc is not an option.

DoO (DNS over Onion) which is a variety without HTTPS of what cpunk mentioned above has similar drawbacks.

Last edited 11 months ago by cypherpunks (previous) (diff)

comment:10 Changed 11 months ago by cypherpunks

Relevant: #28955.

comment:12 Changed 10 months ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

comment:13 Changed 8 months ago by antonela

Cc: antonela added

comment:14 in reply to:  7 ; Changed 8 months ago by arma

Replying to cypherpunks:

For exit servers, someone wants open new ticket as described by teor an arma?

I think there is no need for such a ticket until we live in a world where there are many diverse DoH servers. Encouraging exit relay operators to switch their dns to cloudflare or google, whether they use link encryption or no, is pushing us backward toward centralization.

comment:15 Changed 8 months ago by gk

Keywords: ff68-esr removed

comment:16 Changed 8 months ago by mrphs

Cc: mrphs added

comment:17 in reply to:  14 ; Changed 5 months ago by dkg

Replying to arma:

I think there is no need for such a ticket until we live in a world where there are many diverse DoH servers.

One useful talking point to convince a diverse set of DoH servers to exist is to point out that the Tor project is ready to use DoH to do DNS resolution, but isn't recommending it yet because they want to see more operators.

If we could get #7829 resolved, then we'd have a more viable story to tell about why DoH wasn't necessary, but for now, DoH or DoT over Tor looks likely to provide the least-leaky form of DNS resolution possible for full anonymous DNS queries.

comment:18 in reply to:  17 Changed 5 months ago by cypherpunks

Replying to dkg:

Replying to arma:

I think there is no need for such a ticket until we live in a world where there are many diverse DoH servers.

There a coming more and more public DoH Resolvers.

Here is a list of currently 115 public ones:

https://dnscrypt.info/public-servers

Note: See TracTickets for help on using tickets.