[tor-talk] Need a stable .onion address hosted by the Tor project.

[Roger Dingledine]

On Wed, Oct 25, 2017 at 07:22:18PM +0200, Rob van der Hoeven wrote:
> > Keep in mind the false positives caused by crappy networks that just
> > resolve _all_ domains and then serve ads, a captive portal, etc. on
> > whatever IP address. Checking the https://check.torproject.org/api/ip
> > response body seems like it would be safer.
> > 
> 
> A normal DNS server will not be able to resolve an onion address
> undetected.
> 
> My program uses the transparent proxy provided by the Tor daemon which
> resolves an onion address to an address in a non routable address
> range. 
> 
> If the DNS server returns an address outside the VirtualAddrNetworkIPv4
> range, I know that something is wrong...

This is a good example of why "testing your local Tor configuration by
making a request out to the network" is a fragile approach. In this case,
a local attacker who knows the algorithm could respond to .onion dns
requests with an IP address in a range that makes your program think
everything is correct even when it's not.

Another problem with the approach, which might not seem like a big deal
now but has historically turned into a big deal in a surprising way,
is that users of your tool will always start out doing some specific
network activity, which immediately sets them apart from other users.
For example, if your tool hits the Facebook onion on startup, and then
the user actually visits the Facebook onion soon after, will there be
ways for Facebook to link the two visits together, and draw a conclusion
about whether the user who just logged into Facebook is using your tool?

I think the more stable answer long term is not to try to have some
resource always available on the Internet, but rather to change the
design of your checks so that they are correctly checking, locally,
whether your requests are making it to the Tor client as expected.

Tor Browser went through exactly this evolution: we used to have Tor
Browser hit check.torproject.org at startup, so the user could make sure
everything is ok. That approach led to a series of small miseries, where
the website would get overloaded, or a small fraction of requests would
end up with false negatives (since tordnsel, which feeds check.tp.o, is
not perfect).

The better approach turned out to be teaching Tor Launcher about the
Tor control interface, and then it can connect and see for itself (via
controller events) that its connections are indeed arriving at the local
Tor client. No actual network traffic needs to be generated.

In fact, in the distant past we had a special-purpose domain (like .onion)
in Tor named ".noconnect", which could be used for exactly this "try it
and check that it worked" purpose:
https://spec.torproject.org/address-spec
We removed that special-purpose domain though, right around the time we
disabled the ".exit" domain by default too -- there were too many cool
tricks that websites could do to manipulate your path selection.

I believe the eventual strategy that Tor Launcher settled upon was to
arrange so it was not possible to configure Tor Browser in any other
way besides sending its traffic through Tor. That approach was better
for usability *and* (thus) better for security.

Hope that helps,
--Roger