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