Re: [tor-dev] Design for an exit relay scanner: feedback appreciated

On Wed, Oct 9, 2013 at 9:44 PM, Philipp Winter <identity.function@xxxxxxxxx> wrote:

I am working on a Python-based exit relay scanner which should detect malicious
and misbehaving exits. The design should have a reasonable balance between
being fast/parallel and stressing the network as little as possible.

I came up with the following three steps:

1. Spawn a "parent" Tor process to get an up-to-date consensus.

2.1 For every selected exit relay, spawn a lightweight Tor process.

2.2 The consensus is copied from the "parent" process to the lightweight
process' data directory. That way, the consensus has to be downloaded only
once.

2.3 Every lightweight Tor process has the following configuration:

---
SOCKSPort auto
ControlPort 0
__DisablePredictedCircuits 1
UseEntryGuards 0
FetchServerDescriptors 0
DataDirectory <data_directory>
ExitNodes <exit_relay>
---

Entry guards are not used to distribute the load. Predicted circuits are
disabled to prevent expensive creation of circuits which would not be used
anyway. In addition, I am considering adding "EntryNodes" or "Bridge" to
concentrate the first hop's load on machines under my control.

3. torsocks is then used to establish decoy connections over the respective
exit relay. After that, the process is terminated.

Any thoughts on how to further improve the design or ideas for a better one?

Hi Phillip,

I'm excited to hear you're interested in working on an exit scanner.

I have some thoughts regarding the design that might interest you.

I have been working on adding a "Tor Network Test Template" to ooni-probe; the basic concept is to extend the Tor controller library we use (txtorcon) to be able to build and attach circuits to specific streams, and iterate over the exits in the consensus. That is, we'll provide primitives that will allow you to specify a network interference test and tell ooni to run that test against every exit we know about (or a subset, a specific exit, or what have you). ooni-probe features a concurrency-based scheduler, so as to limit the impact on the network, and we've designed it to support plug-in rate limiting hooks if you want to do something fancier.

My intent is to provide Tor network tests as part of ooni-probe's standard set of tests, so that many individuals will measure the Tor network and automatically publish their results, and so that current and future network interference tests can be easily adapted to running on the Tor network. Future ideas include adding signing support to ooni reports so that reliable reporters can build trust, and automatically parsing submitted reports to generate BadExit after a threshold of reporters is reached.

Hope this interests you,

--Aaron

Cheers,
Philipp
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev