[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Detecting if a IP address belongs to a Tor Exit node.



On Tue, Dec 04, 2012 at 08:25:25PM +0000, Julian Yon wrote:
> On Tue, 04 Dec 2012 18:51:16 +0100
> Michael Zeltner <m@xxxxxxxx> wrote:
> 
> > Excerpts from Julian Yon's message of 2012-12-04 14:10:50 +0100:
> > > On Tue, 4 Dec 2012 13:25:15 +0100
> > > Jorge Couchet <jorge.couchet@xxxxxxxxx> wrote:
> > > 
> > > > I'm working with the ticket 7549
> > > > (https://trac.torproject.org/projects/tor/ticket/7549).
> > > > ...
> > > > So, the question is: is there any other reasonable way (efficient
> > > > -development and execution time- and safe) to see if an IP address
> > > > belongs to a Tor Exit node?
> > > 
> > > *looks at the ticket and your approach*
> > > 
> > > Why not just run and query an Onionoo server?
> > 
> > Onionoo isn't really optimised in regards to giving out lists of
> > exits, the parsing of the JSON sounds like a duplicate effort to me.
> > Also, shipping Onionoo with every facilitator seems a bit overkill.
> 
> Have you actually read the ticket? This is in contrast with running a
> full Tor client and connecting to its ControlPort. Now that is what I
> call overkill! And parsing JSON is hardly difficult. But you're right:
> there's no need to run the entire Onionoo server. But there is need for
> a mechanism to retrieve the relevant data.

Is running a Tor client really so heavyweight? Let me explain more about
what we're trying to do. The facilitator needs to know, for each
request, whether the requestor is a Tor exit. The facilitator gets many
requests. It's on the order of several per second now, and we haven't
advertised it yet. We're designing for a few thousand requests per
second. I think that rules out anything like a DNS query or
TorBulkExitList.py per request.

A reasonable solution is to update a local cache once an hour. What
Jorge is asking is, what's the best way to feed this cache? Any source
needs to be at least authenticated and should reflect a consensus of
just one authority. This is why I suggested a local Tor client, because
it will check the authentication.

Another design (non-)constraint: There are few facilitators (currently
one), so ease of deployment is not the biggest concern. It does not have
to be as easy as setting up a relay (figure that there will be many more
websocket relays than facilitators).

The command in the ticket
	cat $HOME/auto-naming/moria1/cached-des* | python $HOME/git/contrib/exitlist <ip>:<port> > exitlist
seems to me that it is reading a list of exits from a local Tor. This
seems pretty reasonable to me. I read that Onionoo reads its information
from metrics; where does metrics get the data from?

David Fifield
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev