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@niij.org 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@gmail.com 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