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.
Please correct me if I'm missing something, but there's two options that are easy to integrate that already exist:
Tor Bulk Exit List, if all you need is checking for access on port 80 https://check.torproject.org/cgi-bin/TorBulkExitList.py
And TorDNSEL, which would include checking for IP:port https://www.torproject.org/projects/tordnsel.html.en
While this is the canonical answer to the question, I held back from saying so because: “This ideally will use a locally cached database of exits. (Not an on-demand DNS lookup.) It should continue to work (perhaps with some classification errors) even if the database can't be refreshed for some time.” So, it needs to maintain its own cache, be explicitly non-realtime, be able to refresh its own database but also to gracefully degrade to disconnected operation. By the time you've coded all that up, you've replicated a big chunk functionality.
But, hey, maybe the requirements are poorly stated. It's hard to tell without further info.
Julian