[tor-bugs] #7549 [Flashproxy]: Facilitator should not give client registrations to Tor exits

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Dec 8 23:31:36 UTC 2012


#7549: Facilitator should not give client registrations to Tor exits
-------------------------+--------------------------------------------------
 Reporter:  dcf          |          Owner:  jct           
     Type:  enhancement  |         Status:  needs_revision
 Priority:  normal       |      Milestone:                
Component:  Flashproxy   |        Version:                
 Keywords:               |         Parent:                
   Points:               |   Actualpoints:                
-------------------------+--------------------------------------------------

Comment(by jct):

 The attached '''fac-onionoo.zip''' is a proof of concept of the following:

 It is a threaded TCP server that is capable of:
   * Query an Onionoo server in order to build a local database of Tor Exit
 nodes
   * Answer queries from a client (mainly the Facilitator) about if a given
 IP belongs to a Tor Exit node or not.

 The main module is the new module '''fac-onionoo''' and it is using the
 new modules '''base_server.py''' and '''custom_ssl.py'''. It is also using
 the old module '''fac.py''', but with the new function '''fac.ip_ver'''.

 Comments about the modules:
   * The module '''base_server.py''' is a kind of "factor out" from the
 module '''facilitator'''
     * I've extracted from the last the base code for a Threaded TCP
 server:
        * If the '''base_server.py''' is accepted, then it will be needed
 to refactor '''facilitator''' in order to use it (but that isn't
 difficult).
   * The module '''custom_ssl.py''' has the code needed to use HTTPS in a
 secure way, cause there is an issue with Python < 3 using the standard SSL
 module:
     * The module has a dependency with the module '''certifi'''. It was
 the easiest way to have a list of root certificates.
   * The module '''fac_onionoo''' has two roles:
     * Mantain a local database of Tor Exit nodes:
       * It uses the '''Onionoo''' project in order to build this database:
          * It wasn't possible to use the simple query
 https://onionoo.torproject.org/summary?type=relay&running=true
 (https://lists.torproject.org/pipermail/tor-
 dev/2012-December/004235.html), cause in this case I'm receiving all the
 relays and I don't have enough information if it is an Exit node or not
 (according the specification the addresses returned are "IPv4 or IPv6
 addresses where the relay accepts onion-routing connections or which the
 relay used to exit to the Internet"). For this reason I was needing to
 retrieve the '''Details documents''' and calculate from the
 '''exit_policy''' array if the relay is an Exit node or not. In order to
 do that, I was using the Stem library (it already has a function in order
 to calculate that -> https://stem.readthedocs.org).
     * The second role is to answer queries asking if a given IP belongs to
 a Tor Exit node:
       * The server defines a protocol for that and the module '''fac-
 onionoo-test''' is showing the client function ('''ask_is_exit''') that is
 using this protocol in order to query the server:
         * This function should be located later at the '''fac.py''' module
 and it will be used from the Facilitator in order to check if a Proxy 's
 IP belongs to a Tor Exit node or not.

 The module '''fac-onionoo-test''' is a small test that is showing how is
 working the server. It is a bit slow cause the query to the Onionoo server
 takes time (it is using HTTPS and also is processing a lot of data). Also
 the test isn't very automatic, cause it is possible that the IP for the
 known Tor Exit (I've extracted it using  the TBB) is changing (or down,
 etc.).

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7549#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list