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 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
