[tor-bugs] #5011 [Pluggable transport]: Discuss possible designs for an external program that discovers bridge addresses to tell Tor about them

[Tor Bug Tracker & Wiki]

#5011: Discuss possible designs for an external program that discovers bridge
addresses to tell Tor about them
---------------------------------+------------------------------------------
 Reporter:  karsten              |          Owner:  mikeperry
     Type:  task                 |         Status:  new      
 Priority:  normal               |      Milestone:           
Component:  Pluggable transport  |        Version:           
 Keywords:  MikePerry201203      |         Parent:  #5010    
   Points:                       |   Actualpoints:           
---------------------------------+------------------------------------------

Comment(by nickm):

 Replying to [comment:15 mikeperry]:
 >
 > I was hoping we could get away with fixed port. I think any sort of
 configuration is going to make people sad and confused, unless they're
 walked through the pairing process to generate a secret and give it to
 both Vidalia/Orbot and their plugin of the week. But how does that happen
 on a phone?

 Fixed port is going to be tricky, since we want to support multiple Tors
 on one system.

 I think there are also lots of per-system 'software bus' mechanisms for
 IPC/registry stuff, but those aren't nice and general like what we're
 talking about here.

 > Can we skip the shared secret authentication step in initial
 imlementations, or is it must-have even if we require that "IPC 1" has a
 proper handshake, well-formed-or-die behavior, and triggers user
 confirmation from Vidalia?

 Depends on threat model, I guess.  I don't really trust user confirmation
 to get us out of this problem, since people are pretty bad about clicking
 "ok" to everything, and since it's not clear that the average user could
 even tell which of these messages would be out of the ordinary.  So, do we
 think that there is hostile software here that might want to deanonymize
 people, and is that in the threat model we care about?  If so, we need to
 do _some_ kind of thing to keep that software from adding bridges before
 we actually give this to users.

 For the point of view of this spec and the March 15 deadline, it's
 probably fine to say what kind of mechanism we need, mention a few
 alternatives, and look for better alternatives as we go forward.

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