Snakes On A Tor Scanner - 0.0.3

[Roger Dingledine]

On Fri, Oct 13, 2006 at 11:20:41PM -0500, Mike Perry wrote:
> Over the past month or so I've been testing and improving my Tor
> network scanner, and it seems to be shaping up pretty nicely.
> 
> http://fscked.org/proj/minihax/SnakesOnATor/SnakesOnATor-0.0.3.zip

Hi Mike,

This looks great. Here are a few responses from reading your README:

>The Metatroller requires two Tor config options in your torrc:
>
>ControlPort 9051
>__LeaveStreamsUnattached 1

You could have your Metatroller connect to Tor and set
__LeaveStreamsUnattached=1 itself. Then the user doesn't have to mess
with his torrc at all (assuming he already has the controlport set). In
fact, when the metatroller exits you could unset it, so Tor becomes a
normal client again.

> Lastly, the metatroller currently does not subscribe to router info or
> (non-existent) network status events, so it should be restarted
> periodically. When network-status events are available in 0.1.2.x I'll
> support them.

If you could help us get moving on that, that would be great. Some sort
of spec patch and preliminary code patch would be fabulous.

> 3. SOAT is not likely to work optimally if you are using the same Tor
> client for other things. In some cases this can cause the exit to change
> between the time that SOAT uses it and the time that it detects an
> error and asks Metatroller what exit was used.

When you extendcircuit, you can specify purpose=controller, and
then Tor won't ever touch those circuits on its own.

>                                                It is probably best to
> run a secondary Tor client with a different control port just for SOAT
> and the Metatroller. You probably want this for anonymity reasons also,
> especially since the default path length used by SOAT is only 2.

True.

> I'm also suspicious of the 7/8 node cutoff for "fast" nodes.  I think
> that perhaps it should be raised to 65% or so, but I have no hard data
> as of yet to illustrate this cutoff point. Since adoption is critical
> to anonymity, and regular people won't use Tor if they think it is
> slow, I believe it is far more imporant that we have known reliable,
> fast nodes than lots of slow ones that are prone to dropping circuits.
> Hopefully we can discover these cutoffs using this tool.

That's an interesting question -- do the slow ones drop circuits more
often? I'd be curious to hear some data on that.

More generally, while using a fraction of the nodes (7/8 or 65%) lets
us adapt better to whatever network we have available, it may still not
be the right approach if our goal is to have high chances of getting a
non-sucky circuit. On the other hand, people who sign up to be relays
but never get used may be sad. On the third hand, so what? Hm.

> Plans for the future include ...
> possible integration with the
> directory servers to help avoid unstable/malicious nodes (or at the
> very least, an internally saved blacklist for high failure-rate
> nodes).

Right, I think this is definitely worth investigating further. We could
add a getinfo statusflags/id/foo and maybe a setinfo to go along with
it, and any directory authority that wanted to could run your script to
learn whether to set the BadExit flag on a given router. (Note that we've
already put in a new flag called BadExit that clients will recognize in
future versions.)

While we're at it, would it be interesting to look into adding a country
code to the network-status list, saying our best guess based on whois
or whatever of where the node is? As more and more tools hardcode "fetch
it from serifos, unauthenticated and with a single point of failure",
it might be nice to offer a better option.

Thanks!
--Roger