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

[Aaron]

On Wed, Oct 9, 2013 at 9:44 PM, Philipp Winter
<identity.function at gmail.com>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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20131010/48b0b7e3/attachment.html>