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

[Rob van der Hoeven]

On Wed, 2017-10-25 at 22:15 -0400, Roger Dingledine wrote:
> 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.
> 

I do not agree. Only a highly privileged *LOCAL* attacker can do the
things you mention unnoticed. In that case no program can protect you,
all hope is lost...

> 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 do not think this will be a problem. Even if an attacker knows that a
user is using my program there's probably little he/she can do. All
that my program does is setting up an environment consisting of a
net_cls cgroup and some iptables rules that forward traffic from
programs within the cgroup to the TransPort and DNSPort of the Tor
daemon. My program does not actively take part in the forwarding,
that's done by *POWERFUL KERNEL MAGIC*. This approach is simple and
much safer than my previous transproxy program AVNE.

Talking about my AVNE program. When I released it I had a discussion
with Yawning. He/she mentioned that its networking code worked much
like Orbot's Android VPN code. Both use a tun interface in combination
with User Space Networking. Maybe the cgroup/iptables method I use in
my program also works on Android. If it does, it can reduce the
complexity and improve the security of Orbot.

> 
> 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.
> 

I like the controller events idea. It will probably double the code
size of my program but that will be fine *IF* my program becomes
popular. I think it's best to release the program and see if people
like it. Then I can decide. 

Thank you for your feedback,

Rob.
https://hoevenstein.nl