Track advocacy and uptake of "applications shouldn't resolve onion addresses"

IETF RFC 7686 specifies that:

Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup.

I hear that Firefox implemented this feature, so if you try to visit an onion address in Firefox, it refuses to try. There's an about:config way to disable that feature -- and in theory it allow it if the browser is sending the traffic into Tor, and how exactly it knows that...this gets complicated.

So the vision of this ticket is to keep track of which applications have implemented this change (and how they did it), and which apps have tickets for implementing it (and how they propose to do it).

Then we can look for patterns and figure out:

• if there's advice we can provide for how best to achieve the goal in the RFC (like "don't change your app, and instead get the change into the resolver that your app uses"), and also

• if there are particular external pieces of software we should open tickets for changing.

moved from tpo/community/team#30 (moved)

Sorry Gus that I put this in the community team's list. I spent a long time looking at other gitlab components and couldn't find one that fit. This is definitely a topic that falls into the cracks between teams -- please help us find a home for it. :)

Maybe it should go in whatever component we're going to use (or make) for the "unblock Tor at destination websites" campaign?

I think community is the right place for this ticket. Once we know exactly any change we need to do, then we can change it to other place.

ahf points us to https://bugs.chromium.org/p/chromium/issues/detail?id=562265 for the (a?) chromium ticket.

and ahf points out that unbound has an explicit default zone for onion, as described in the man page

@jnewsome was wondering how this idea interacts with torsocks, and in theory they can go well together: the application calls gethostbyname without knowing or caring about onion addresses, and then either

• gethostbyname asks the system resolver, which says "oh that's an onion address, not gonna send that hostname out onto the network, here's your nxdomain", or

• torsocks hooks and replaces gethostbyname, and then torsocks does whatever it sees fit, e.g. providing a local virtual address and then informing Tor about what hostname that address really corresponds to.

So in that sense we really don't want each application to learn that onion addresses are special, because if the application had its own logic before it calls gethostbyname, then torsocks has to get in on hooking that too.

It seems like part of what gets messy here is the "don't resolve it unless you're sending your traffic through Tor", so applications that are Tor-aware should be doing something different, and maybe we should provide guidelines for how they should be doing that, else we'll get ten different contradictory approaches in the wild.

A little about why this is worth doing:

A resolver that doesn't recognize a .onion address as special will try to resolve it over the network via the DNS protocol, leaking that the user tried to access the given .onion address to the root domain server and to anyone else on the network who observes the request. https://www.verisign.com/assets/onionleakage.pdf?inc=www.verisigninc.com

In the past this has resulted in chrome leaking .onion addresses.

Fixing this would also provide defense-in-depth against bugs like tpo/core/torsocks#11727. In that bug a user who uses torsocks with irssi to access a .onion address will leak the address. (Work in torsocks and/or irssi is needed for .onion addresses to work correctly, but a local DNS resolver that recognized the .onion address and blocked the request would at least prevent leaking the address).

Another topic we discussed is potentially implementing the behavior in libraries, such as libc's gethostname or libevent's resolver api. This would likely be beneficial, e.g. in cases where the first-level resolver service isn't on the local host, or that resolver doesn't already implement this behavior.

This might be a little bit harder of a sell though since, e.g., gethostname arguably has no business recognizing resolver special cases before passing it to a real resolver service.

Also as Roger noted above though, we need to be careful to not advocate that applications block .onion addresses (or at least that the behavior can be disabled), since that would interfere with torsocks's ability to torify that application.

we need to be careful to not advocate that applications block .onion addresses

Actually RFC 7686 says the opposite. Should we consider trying to amend the RFC?

From the RFC:

Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion and SHOULD NOT perform a DNS lookup.

IIUC this would break our ability to use torsocks with that application.

added Icebox label

made the issue confidential

marked this issue as related to #85

mentioned in issue #85

Signal preloading and a little research

Small update: we received a report about Signal not conforming to the RFC and leaking .onion addresses in DNS queries.

There's a chance that a further research can list whether other messaging applications are also doing this -- like Slack and Mattermost.

For those in the mail thread, a reference for quickly finding it is:

Date: Thu, 13 Apr 2023 16:44:25 -0400
From: Roger Dingledine <arma@torproject.org>
Subject: Re: signal link preloads

We could discuss the urgency/priority and a plan for this issue at some point -- and if the RFC needs an amendment (see Jim's comment and #85).

/cc @micah

Here is a more thorough version of the paper that Jim pointed to above:

https://seal.cs.ucf.edu/doc/tnet17.pdf

It explores the many ways that onion address resolve attempts end up getting to the dns roots.

Discussion about a Tor Spec

Related issue: Formalize toggle override for non-Tor applications that follow RFC 7686 (#202) · Tor Specifications

changed the description

marked this issue as related to tpo/core/torspec#202

made the issue visible to everyone

added Onion Services label

Quick possibly related idea, could onion URLs be deep-linked?

You mean deep linking, mobile deep linking or something else?

Thinking of mobile deep linking, so if I receive an onion address on Signal and click on it, could it suggest opening the link through Tor Browser?

Similar discussion about bridges: tpo/anti-censorship/team#126 (for context, see this discussion during the CR meeting).

Yes, that's partially related, but I think it deserves it's own ticket :)

Quickly created a ticket here: #220

marked this issue as related to #220

Shall we change the ticket to, instead of just advocating non-resolution, support RFC 7686 by either use Tor and resolving .onion addresses (like link previous from .onion sites through Signal), or refusing to resolve .onion domains (so they're not leaked in the DNS)?

This can be a better message to give, and could increase support for Tor.