Opened 6 months ago

Last modified 2 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 (16)

comment:1 Changed 6 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 6 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 6 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 6 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 6 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 6 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 6 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 6 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 5 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 5 months ago by cypherpunks (previous) (diff)

comment:10 Changed 5 months ago by cypherpunks

Relevant: #28955.

comment:12 Changed 4 months ago by pili

Sponsor: Sponsor44-can

Adding Sponsor 44 to ESR68 tickets

comment:13 Changed 3 months ago by antonela

Cc: antonela added

comment:14 in reply to:  7 Changed 3 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 3 months ago by gk

Keywords: ff68-esr removed

comment:16 Changed 2 months ago by mrphs

Cc: mrphs added
Note: See TracTickets for help on using tickets.