Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#6412 closed defect (fixed)

Add way to configure obfsproxy bridges

Reported by: Sebastian Owned by: chiiph
Priority: Medium Milestone:
Component: Archived/Vidalia Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: #6434 Points:
Reviewer: Sponsor:

Description

Vidalia should support creating an obfsproxy bridge. Required inputs would include at least the path to the obfsproxy binary, the name of the transport, and - probably on a per-known-transport basis - additional options necessary to launch it.

Child Tickets

Change History (8)

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

comment:2 Changed 7 years ago by asn

Parent ID: #6434

comment:3 Changed 7 years ago by Sebastian

One thing that I deem important is to make it similar to the current way of starting Tor, mainly "select a path to the tor.exe, and a port, and that's it". I am not entirely clear if that is covered in your list.

comment:4 Changed 7 years ago by chiiph

My comment in here will be similar to what I said in #6435. The simplest way for the user would be to have a transport combobox with all the transports, and have the user select one of those or "None" and then have everything else (in terms of GUI) be exactly the same.

Vidalia could have a configuration value in vidalia.conf to know what transport are available.

From the docs I assume we can't have multiple ServerTransportPlugin lines and "select" one for the configured bridge in torrc. Vidalia would need to add or remove STP depending on what the user wants. Does that sound right?

Opinions?

comment:5 in reply to:  4 ; Changed 7 years ago by asn

Replying to chiiph:

My comment in here will be similar to what I said in #6435. The simplest way for the user would be to have a transport combobox with all the transports, and have the user select one of those or "None" and then have everything else (in terms of GUI) be exactly the same.

Hm, the checkbox approach makes sense. Although remember that a bridge can support multiple transports.

Vidalia could have a configuration value in vidalia.conf to know what transport are available.

Hm, I'm not sure how vidalia.conf works. It seems that this configuration value would have to change every time a transport/proxy was added/removed. Are there any other vidalia.conf configuration values that require human editing in new releases? Who is doing this editing atm? Erinn?

This doesn't sound like a bad idea for now, but maybe we should look into automating it for the future.

From the docs I assume we can't have multiple ServerTransportPlugin lines and "select" one for the configured bridge in torrc. Vidalia would need to add or remove STP depending on what the user wants. Does that sound right?

Indeed, for every STP line a new transport(s) is started. You can't have multiple STPs but only some of them enabled at a given time.

Opinions?

comment:6 in reply to:  5 Changed 7 years ago by chiiph

Replying to asn:

Replying to chiiph:

My comment in here will be similar to what I said in #6435. The simplest way for the user would be to have a transport combobox with all the transports, and have the user select one of those or "None" and then have everything else (in terms of GUI) be exactly the same.

Hm, the checkbox approach makes sense. Although remember that a bridge can support multiple transports.

Ok, then I guess a list with checkboxes for each transport would be the way to go.

Vidalia could have a configuration value in vidalia.conf to know what transport are available.

Hm, I'm not sure how vidalia.conf works. It seems that this configuration value would have to change every time a transport/proxy was added/removed. Are there any other vidalia.conf configuration values that require human editing in new releases? Who is doing this editing atm? Erinn?

In general, the conf doens't change, but if so, yes, Erinn handles the changes (or may be Shondoit).

This doesn't sound like a bad idea for now, but maybe we should look into automating it for the future.

How would we automate something like this? The scenario we need to define is one where the user understand only that there is a thing called "transport" (or whatever word is best) and that it does some magic when bridges don't work for certain people.

So say we provide obfs2 for now. We can add the following to vidalia.conf:

Transport="Obfs2:<STP line>"

So Vidalia knows Obfs2 exists and it should use the corresponding STP line when the configured bridge is using this transport.

If in the future we distribute another transport, we need to tell Vidalia about it:

Transport="Obfs2:<STP line>; Blabla:<Other STP line>"

And so on.

But somehow Vidalia needs to know what transport there are, otherwise we need to ask the user to set that, in which case the user needs to know what to write. The advanced user can have a plugin that modifies that specific line in the configuration in a nice GUI way.

comment:7 Changed 7 years ago by chiiph

Resolution: fixed
Status: newclosed

An implementation for this has been merged to alpha and it will be out with 0.3.4-alpha.

comment:8 Changed 7 years ago by asn

Looks very good! I added some comments in #6729.

Note: See TracTickets for help on using tickets.