Support for full DNS and DNSSEC resolution

changed milestone to %Tor: 0.4.4.x-final

added DNS DNSSEC component::core tor/tor milestone::Tor: 0.4.4.x-final priority::medium reporter::chrisss404 reviewer::ahf severity::major status::needs-review type::enhancement labels

Trac:
Username: chrisss404

317-secure-dns-name-resolution.txt

Trac:
Username: chrisss404

If the DNS Resolver is on a onion service, but we want it to not correlate different name requests together. Do we need to setup a new circuit to it for each domain resolution?

Because of:

HiddenServiceExportCircuitID protocol
The onion service will use the given protocol to expose the global circuit identifier of each inbound client circuit

The Onion Resolver could create a profile of all domains visited per

circuit identifier

If no stream isolation is used.

I added the implementation here: https://github.com/torproject/tor/pull/1869

For the DNS connections I introduced a new session group: SESSION_GROUP_DNS_LOOKUP https://github.com/torproject/tor/blob/153f81f340ea84bc5df7471b2d0a7bfbf3ad318c/src/core/or/or.h#L990

Then I setup the connection as follows: dns_conn->entry_cfg.session_group = SESSION_GROUP_DNS_LOOKUP; dns_conn->entry_cfg.isolation_flags = ISO_DEFAULT; dns_conn->entry_cfg.ipv4_traffic = 1; dns_conn->entry_cfg.ipv6_traffic = 1; dns_conn->entry_cfg.dns_request = 0; dns_conn->entry_cfg.onion_traffic = 1; dns_conn->entry_cfg.use_cached_ipv4_answers = 0; dns_conn->entry_cfg.use_cached_ipv6_answers = 0; https://github.com/torproject/tor/blob/153f81f340ea84bc5df7471b2d0a7bfbf3ad318c/src/core/or/dns_resolver.c#L458

Can you please help me to determine if this approach is prone to correlation attacks?

Trac:
Username: chrisss404

Whoa, cool patch! That's a lot of stuff to look at, but I'll try to make sure somebody takes a look soon. First thing to do is going to be sending the proposal to the tor-dev@ mailing list so people can comment on it.

Trac:
Milestone: N/A to Tor: 0.4.4.x-final
Status: new to needs_review

Replying to nickm:

Whoa, cool patch! That's a lot of stuff to look at, but I'll try to make sure somebody takes a look soon. First thing to do is going to be sending the proposal to the tor-dev@ mailing list so people can comment on it.

Nick, I think this code is based on an existing proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.txt

But it would be great to send an updated version of that proposal to the tor-dev mailing list.

I just saw the updated proposal here: https://lists.torproject.org/pipermail/tor-dev/2020-April/014252.html

Thanks for the great patch.

It is one big step forward to giving more reliability and control to client of what plaintext information, addresses of contacted hosts you may share with exit relays. Less trust must be given to exit relay, because they could lie to you in DNS response without your knowledge! DNSSEC gives a way to verify.

Also it will make client connections through exit servers more reliable. Because many of them fail at not so unimportant low rates, that makes them "unusable" (for tbb ) or any domain name based connections. discussed beforehand #32864 (moved)

It will take of load and bandwidth off exit relays witch is the overall lowest advertised bandwidth in tor consensus to date.

SESSION_GROUP_DNS_LOOKUP will ensure, that if you look up hostname from socksport request to .torproject.org, it will not be send to the resolver over the same exit circuit the than resolved ip connection stream is going to use. If a clearnet resolver may be used. This gives the exit node or anyone monitoring it, no clue about what host you may contacted, if not does deep packet inspection and the IP not have a single mapped domain and no reverse dns record to it or used protocol exposes it. (like http host header| | tls without esni)

My only concern is the privacy gain that one may like or think to earn from using onion resolvers with this solution configured with DNSResolverNameservers.

SESSION_GROUP_DNS_LOOKUP along with default isolation effectively allows to let two streams or lets call it domain name resolution lookups to share the same circuit.

Example Scenario:

TBB user visits .torproject.org and in new tab visits .cock.li

Without

DNSResolver

tor will open two destination isolated circuits each attaching stream resolving its domain through exit. exit will not learn both destinations.

With enabled

DNSResolver 1

tor will open two destination isolated circuits each resolving its domain beforehand through stream to configured DNSResolverNameservers through same resolver circuit. exit will not learn both destinations. Bonus Exit will not learn domain name. Resolver will learn, a user that first contacted .torproject.org may got a mail address from .cock.li too. even if Resolver is contact with the default onionresolvers. Because, the first stream of resolver MAY can share the same circuit. The resolver owner will not know the ip or country of the request but knows that both came from the same client (individual)! Effectively ignoring and erasing the isolation flags of socksport, decreasing the isolation level. Allowing resolver to learn activity profiles over time, by correlating dns requests. Mapping unique circuitID with requested domains to onionresolver .

it is even worse if the client should use the same resolver as before the two isolated exit servers belong to. because now there is a correlation between these two resolvers connections. i hope to have made it clear with the example.

Possible solution:

never allow to share a resolver stream with another by setting:

dns_conn->entry_cfg.isolation_flags = ISO_STREAM;

or more dificult, learn what isolation was requested from the socksport handshake and use the same isolation level. please remember, socksport request can not only have isolation flags but use username:password@socks5 for isolation too as TBB does.

Note: I only did a quick look over it. That is what came up to my mind. Not tested it out actually yet.

sogar wenn der client denselben resolver verwenden sollte wie zuvor die beiden isoliert verwendeten exit server, ist es schlechter. da nun ein Zusammenhang zwischen diesen beiden besteht. ich hoffe es mit dem Beispiel deutlich gemacht zu haben.

Trac:
Reviewer: N/A to ahf

This seems to need some more discussion that is happening in parallel on tor-dev@lists.torproject.org.

mentioned in issue #34135 (moved)

moved to tpo/core/tor#34004 (closed)

Support for full DNS and DNSSEC resolution

Child items 0

Activity