Snakes On A Tor Scanner - 0.0.3

[Mike Perry]

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

As a quick refresher, the scanner consists of two parts:

The Metatroller:
   A Tor Controller that allows you to customize properties of your
   Tor routes. You can control path length, exit country, "fast node"
   cutoff, and lots of other neat things.

Snakes On A Tor:
   A Scanner that uses the Metatroller to scan the network for nodes
   that are unstable and/or modifying exit traffic. Docs are now
   obtained randomly from google queries.

Metatroller will work in ActivePerl on Windows without any other
dependencies, however SOAT will require curl, md5sum, and openssl. 

I think SOAT and Metatroller are in good enough shape that they
should make for good QA tools for Tor to help reduce circuit failure,
and also useful tools for people who would like to monitor the Tor
network. 

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.


Here's the CHANGELOG for 0.0.3:

 Metatroller:
  - Now gets its node list directly from Tor using the control port
  - Implemented guard nodes
  - Added circuit/stream failure statistics
  - Improved reliability/recovery from circuit and stream failures
  - All commands can now take no arguments to print current value

 Soat:
  - obtains its doc list via google filetype queries
  - verifies this list contains no dynamic content
  - Saves long-term aggregate failure stats from metatroller

I've given Roger and Nick some patches to expose circuit failure
reason codes to the controller. I think part of these made it into
0.1.2.2-alpha, and hopefully the rest will be in 0.1.2.3. Metatroller
does not need these reason codes to record failures, but it is more
accurate if they are present.



Here's the current list of Metatroller commands:

214  COUNTRY <CC|ALL>
214   - Pick a two letter country code to select exits from, or ALL
214  COUNTRIES
214   - List countries that have tor exits
214  PERCENTFAST <#>
214   - What % of the network is considered 'fast' for node selection
214  BWCUTOFF <#>
214   - Minimum observed bandwidth (KB) that a node must have to be selected
214  UNIFORM <1|0>
214   - Should selection among fast nodes be uniform (or bandwidth-biased)?
214  ORDEREXITS <1|0>
214   - Should exits be chosen one after another instead of randomly?
214  FASTEXITS <1|0>
214   - Should exits be chosen from 'fast' nodes or all nodes?
214  GUARDNODES <1|0>
214   - Use guard nodes?
214  PATHLEN <#>
214   - What should the path length of circuits be?
214  NEWEXIT
214   - Throw away all circuits and choose a new exit
214  SETEXIT <NAME>
214   - Hardcode an exit for all future circuits
214  GETLASTEXIT
214   - Lists the last used exit
214  FAILRATES
214   - Print out the failure rates of nodes


While it is still not advisable for you to use SOAT on a machine you
wish to preserve your anonymity with, Metatroller is perhaps not as
dangerous as I thought.

I've looked into the Tor source, and it turns out that in some cases
Tor does make circuits out of low-uptime nodes. With that, and the
addition of Guard Nodes to Metatroller, it is perhaps not nearly as
dangerous as I had originally thought. The main dangers revolve around
PATHLEN and PERCENTFAST, and are explained in the README.

I believe normal usage should be comparable to Tor in safety at this
point, though there are a couple of attractive fixes in 0.1.2.x I
would like to adopt.

Plans for the future include more finer-grained failure statistics,
node max/min/avg bandwidth stats, and 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).

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

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs