Opened 7 years ago

Closed 12 months ago

#6435 closed defect (wontfix)

Add client-side pluggable transports support to Vidalia

Reported by: asn Owned by: chiiph
Priority: Medium Milestone:
Component: Archived/Vidalia Version:
Severity: Normal Keywords: archived-closed-2018-07-04
Cc: Actual Points:
Parent ID: #6434 Points:
Reviewer: Sponsor:

Description

Vidalia should help censored users use pluggable transports.

Child Tickets

Change History (5)

comment:1 Changed 7 years ago 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.

comment:2 Changed 7 years ago by 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?

comment:3 in reply to:  2 Changed 7 years ago by asn

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.

comment:4 Changed 19 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:5 Changed 12 months ago by teor

Keywords: archived-closed-2018-07-04 added
Resolution: wontfix
Status: newclosed

Close all tickets in archived components

Note: See TracTickets for help on using tickets.