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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:                
-------------------------+--------------------------------------------------
Changes (by dcf):

  * status:  new => needs_revision


Comment:

 Replying to [comment:1 jct]:
 > I just attached a patch with a candidate code in order to solve the
 ticket.

 This looks pretty good, nice job.

 I don't want the "disable the proxy" thing to be a part of this ticket.
 Please assume that `flashproxy.js` will be unchanged and send back an
 empty reply, not an error message.

 I would like to add as little extra complexity to the facilitator process
 as possible. I don't like having the facilitator itself doing background
 HTTP requests and parsing of directory documents. I would rather have a
 completely separate process polling for the exit list, and either writing
 the list to a file shared with the facilitator, or else operating as a
 daemon that the facilitator can query. Now that I think about it, I kind
 of like the daemon idea: it receives a single line containing an address,
 and writes back a byte that indicates whether the address given is an
 exit. The only change needed in the facilitator will be a function that
 knows how to query this local daemon. Failure to connect to this local
 daemon would not be a fatal error.

 I'm not comfortable with the method of getting the exit list. I don't know
 much about how the directories work, but I think you are supposed to make
 an authenticated connection to them, and take a consensus among many of
 them. I'm guessing that the right way to do this is to run a Tor instance
 (with no listening ports) on the same host as the facilitator, just for
 the sake of retrieving a network consensus. See if there is a way to
 easily export this data in a form that the exit daemon can use.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7549#comment:2>
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