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

[Julian Yon]

On Tue, 04 Dec 2012 18:51:16 +0100
Michael Zeltner <m at 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 at 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

-- 
3072D/F3A66B3A Julian Yon (2012 General Use) <pgp.2012 at jry.me>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121204/b06af5ee/attachment-0001.pgp>