[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7549 [Flashproxy]: Facilitator should not give client registrations to Tor exits
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs