#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