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

Re: [tor-bugs] #6435 [Vidalia]: Add client-side pluggable transports support to Vidalia



#6435: Add client-side pluggable transports support to Vidalia
---------------------+------------------------------------------------------
 Reporter:  asn      |          Owner:  chiiph
     Type:  defect   |         Status:  new   
 Priority:  normal   |      Milestone:        
Component:  Vidalia  |        Version:        
 Keywords:           |         Parent:  #6434 
   Points:           |   Actualpoints:        
---------------------+------------------------------------------------------

Comment(by asn):

 There are two ways to configure client-side transport proxies:

 The first way is called 'external mode' and it's like saying to Tor "Hey,
 if you want to speak obfs2 to a bridge, just send your SOCKSed data to
 127.0.0.1:5555.". In torrc it looks like this: `ClientTransportPlugin
 obfs2 socks5 127.0.0.1:5555`.
 The second way is called 'managed mode' and it's like saying to Tor "Hey,
 there is a transport proxy at /usr/bin/foo. I want you to spawn it and
 have it handle obfs2.". In torrc it looks like this:
 `ClientTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --managed`.

 The managed mode is the standard way for end-users to configure obfsproxy.
 The external mode is good for debugging and for more advanced usage.
 Vidalia should ideally support both modes.

 I can see the following ways of configuring client-side pluggable
 transport support in Vidalia:

 - The ''easy'' way, where we have premade pluggable transport
 configurations that can be enabled/disabled. For example, when you enable
 such a configuration, it will do something like `ClientTransportPlugin
 obfs2 exec ./Apps/obfsproxy --managed` without the user having to know
 where the obfsproxy binary is, or what the "--managed" switch does. We
 should support all the transports/proxies that are included in the bundle
 as premade configurations.

 - The ''advanced managed mode'' way, where the user specifies his
 transport name, the path to the managed proxy binary and the argv. So the
 user will be able to specify something like `ClientTransportPlugin <DIY>
 exec <DIY> <DIY>`.

 - The ''advanced external mode'' way, where the user specifies where his
 'external mode' proxy is sitting by giving an IP:PORT. So the user does
 something like `ClientTransportPlugin <DIY> socks5 <DIY>:<DIY>`.

 I think that the ''easy'' way should be the standard way for end-users to
 use pluggable transports. The ''advanced'' ways would also be useful for
 advanced configurations.

 Also, there should be a way for users to associate their bridges with
 enabled transports. This could be a drop-down menu for each bridge, so
 that the user can select which of the available transports should be used
 to contact that bridge.

 These options are enough for 0.2.3.x. For 0.2.4.x. we might need to add
 some more stuff like passing additional options to transports (public-
 keys, etc.) etc..

 PS: Should obfsproxy log on the default premade configurations? I think
 so.

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