[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #6412 [Vidalia]: Add way to configure obfsproxy bridges

#6412: Add way to configure obfsproxy bridges
-----------------------+----------------------------------------------------
 Reporter:  Sebastian  |          Owner:  chiiph
     Type:  defect     |         Status:  new   
 Priority:  normal     |      Milestone:        
Component:  Vidalia    |        Version:        
 Keywords:             |         Parent:        
   Points:             |   Actualpoints:        
-----------------------+----------------------------------------------------

Comment(by asn):

 Bridge-side Vidalia should be able to handle 'managed proxies'. 'Managed
 proxies' is when you say to Tor "Hey, there is a proxy binary in /bin/foo.
 Fire it up, and have it serve the 'obfs2' pluggable transport.".

 I can see two ways of configuring managed proxies in Vidalia:

 - The ''easy'' way, where Vidalia has premade transport configurations
 that the user can simply activate/disable using checkboxes (or sth). For
 example, the user will be able to select 'obfs2' and internally
 `ServerTransportPlugin obfs2 exec ./Apps/obfsproxy --managed` will be
 enabled. This is possible since we are putting the transport proxies
 inside the bundle and we know what they support.

 - The ''advanced'' way, where Vidalia allows the user to specify the name
 of the transport he wants to spawn, the path to the binary, and the argv.
 Then Vidalia internally forms `ServerTransportPlugin <name> exec <path>
 <argv>`.

 IMO, the ''easy'' way should definitely be supported, and it should be the
 main way to enable pluggable transports in a bridge: it's one click and
 the user needs to know minimal information. The ''advanced'' way would
 also be nice for more advanced users.

 These options are enough for 0.2.3.x. For 0.2.4.x. we will need to add
 some more stuff like enabling/disabling of Extended ORPort, additional
 options for transports, etc.

 BTW, a little problem with 0.2.3.x is that it does not solve #5609. So the
 user will need to look at the message log to find the port where the
 transport is listening.

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