#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs