Add client-side pluggable transports support to Vidalia
Vidalia should help censored users use pluggable transports.
Activity
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 --managedwithout 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.
-
Vidalia right now accepts things like "obfs2 someip blabla" in the "add bridge" settings dialog. So we should try to keep it as simple as possible for the user.
The ClientTransportPlugin line depends a lot on how Vidalia is distributed (say, TBB vs installation with a linux package manager). So my tendency here is to think this from two different sides:
The software packager side:
- If you want to distribute Tor+SomeTransport+Vidalia, you need to do it with the proper torrc lines.
The user side:
- If you want the usage to be simple, well, it's a complicated feature so ship presets and then the user puts "obfs2 etc" in the "add bridge" thingy and it just works.
- If you want use a particular transport, then you can have a plugin with all the weird things you can do with this, or just open the torrc editor and do it in there.
My point here is, I imagine a person that doesn't even know what an IP is, they just can't access the internet, I don't imagine them understanding the idea of "transport". They only know they have to put this weird text in a configuration and it just works. So may be we should focus in distributing TBB with the proper presets and create a Vidalia plugin to do the advance stuff?
-
Replying to chiiph:
Vidalia right now accepts things like "obfs2 someip blabla" in the "add bridge" settings dialog. So we should try to keep it as simple as possible for the user.
The ClientTransportPlugin line depends a lot on how Vidalia is distributed (say, TBB vs installation with a linux package manager). So my tendency here is to think this from two different sides:
The software packager side:
- If you want to distribute Tor+SomeTransport+Vidalia, you need to do it with the proper torrc lines.
The user side:
- If you want the usage to be simple, well, it's a complicated feature so ship presets and then the user puts "obfs2 etc" in the "add bridge" thingy and it just works.
- If you want use a particular transport, then you can have a plugin with all the weird things you can do with this, or just open the torrc editor and do it in there.
My point here is, I imagine a person that doesn't even know what an IP is, they just can't access the internet, I don't imagine them understanding the idea of "transport". They only know they have to put this weird text in a configuration and it just works. So may be we should focus in distributing TBB with the proper presets and create a Vidalia plugin to do the advance stuff?
I think this is a sound idea. I like the idea of focusing on easy configuration with premade/preset transport configurations that the user can select for his bridges. This is also easy to do at the moment, since there are not many pluggable transports released.
I still think that advanced configuration is important, but we can give it secondary focus for now. The fact that there are not many transports out there, makes advanced configuration not-super-useful for now. Advanced configuration being a Vidalia plugin sounds OK, if you think it will be helpful.
Also, note that the advanced configuration I explained in comment:1 is not transport-specific. Still, it wouldn't surprise me if in the mid-term future there are pluggable transports that require from the user to tweak them (like, to input a shared secret) and that might require a transport-specific Vidalia plugin.
PS: I wonder if the preset transport configurations should have obfsproxy with logging enabled. Having logs around will be quite helpful if any bugs appear.