Re: [tor-bugs] #30753 [Applications/Tor Browser]: Think about using DNS over HTTPS for Tor Browser 9

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#30753: Think about using DNS over HTTPS for Tor Browser 9
--------------------------------------+--------------------------
 Reporter:  gk                        |          Owner:  tbb-team
     Type:  task                      |         Status:  new
 Priority:  Medium                    |      Milestone:
Component:  Applications/Tor Browser  |        Version:
 Severity:  Normal                    |     Resolution:
 Keywords:  ff68-esr                  |  Actual Points:
Parent ID:                            |         Points:
 Reviewer:                            |        Sponsor:
--------------------------------------+--------------------------

Comment (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 [comment:3 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:
 [[Image(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 [comment:5 teor]:
 > Replying to [comment:3 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 [comment:2 teor]:
 > Replying to [comment:1 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 [comment:6 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!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30753#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs