Tor Launcher should set ClientTransportPlugin according to the bridge list

If one wants to create a Tor Launcher distribution that supports some pluggable transports, one has to configure them statically with a ClientTransportPlugin line in torrc before running Tor Launcher. However, since ClientTransportPlugin and the *Proxy options are mutually exclusive, any such distribution prevents usage of proxies even if the user doesn't want to use bridges.

We should fix this by making Tor Launcher itself set ClientTransportPlugin, when necessary, by extracting any plugin parts from the bridge list inputted by the user.

See the set_ClientTransportPlugin branch on git://git.tails.boum.org/tor-launcher for what we do in Tails to achieve that. Note that it is not a complete fix but more of an emergency fix that works for Tails. To make it into a proper, robust fix we'd need at least the following additions:

• Support for IPv6 bridges. Currently a naive regex is used to detect the IPv4 address part of the bridge line (so we can determine the transport plugin part, if it exists) which is fine in Tails, since we only do IPv4. If possible a real IPv{4,6} validator should be used instead of some cheap regexes but I have thus far failed to figure out if xulrunner provides anything like that.

• The path to the pluggable transport proxy binary should be obtained using _getTorFile(), so a default path can be set like for the other TBB files used by Tor Launcher. Therefore _getTorFile() should be moved to the tl-util module. In my branch a working path must be set in extensions.torlauncher.transportproxy_path which clearly is insufficient.

• Tor Launcher should disable the GUI controls when a mutually exclusive option is set, e.g., if a proxy is configured, one should not be able to select "Yes" in the bridge wizard page (and vice versa). It'd be helpful if an explanation was given too. My branch does not do this.

• Tor Launcher should show a warning if an unsupported transport plugin is inputted by the user. My branch does not do this.

added component::applications/tor launcher owner::brade priority::medium resolution::wontfix status::closed type::defect labels

Thanks for filing this bug and for working on a fix.

I added Mike and David to the CC; I am sure one or both of them knows more about this. brade and I did not realize that the presence of a ClientTransportPlugin config item would make tor fail to accept the *Proxy settings. If that is the case, then the proxy options in TBB 3.6b2 won't work unless someone edits torrc-defaults and removes the ClientTransportPlugin lines.

Regardless, it seems like the right fix would be to improve tor and/or the pluggable transport plugins. At the very least, the mere presence of a ClientTransportPlugin should not cause tor to fail to accept or use the *Proxy settings. I think people are working on allowing the PT plugins to respect the *Proxy settings, but I cannot find a trac ticket right now.

Trac:
Cc: N/A to dcf, mcs, mikeperry

I agree that the proper fix is something like #7467 (moved). However it seems nothing has happened with that ticket in the past 17 months so I believe we need a short-term fix in Tor Launcher. It's unclear to me whether you are contesting that.

Replying to mcs:

Regardless, it seems like the right fix would be to improve tor and/or the pluggable transport plugins. At the very least, the mere presence of a ClientTransportPlugin should not cause tor to fail to accept or use the *Proxy settings. I think people are working on allowing the PT plugins to respect the *Proxy settings, but I cannot find a trac ticket right now.

#8402 (moved) and related tickets, currently targeting 0.2.6, comment on the ticket if you want it sooner.

Replying to anonym:

I agree that the proper fix is something like #7467 (moved). However it seems nothing has happened with that ticket in the past 17 months so I believe we need a short-term fix in Tor Launcher. It's unclear to me whether you are contesting that.

I was just trying to obtain a better understanding of the work that is currently underway. I now agree that we need a short-term fix of some kind. TBB 3.6b2 suffers from this bug: if someone tries to set a proxy without even looking at the bridges portion of the Tor Launcher UI, they will see an error like:

Unable to save Tor settings.

Unacceptable option value: You have configured more than one proxy type.
(Socks4Proxy|Socks5Proxy|HTTPSProxy|ClientTransportPlugin)

Unfortunately, it seems like this will be a messy thing to add to Tor Launcher. Kathy and I will take a look at what you did.

Replying to mcs:

Kathy and I will take a look at what you did.

... which now should be possible since I just pushed the branch. Sorry for forgetting that earlier!

Kathy Brade and I did some evaluation of this issue. We would prefer to have Tor Launcher know as little as possible about the ClientTransportPlugin configuration, especially since this issue should disappear when #8402 (moved) is completed.

Our proposal is to store the ClientTransportPlugin values as hidden preferences, like so:

pref("extensions.torlauncher.transport_plugin.fte",
  "fte exec ${TORPATH}/PluggableTransports/fteproxy --managed");
pref("extensions.torlauncher.transport_plugin.obfs2,obfs3",
  "obfs2,obfs3 exec ${TORPATH}/PluggableTransports/obfsproxy.bin managed");
pref("extensions.torlauncher.transport_plugin.flashproxy",
  "flashproxy exec ${TORPATH}/PluggableTransports/flashproxy-client --register :0 :9000");

Tor Launcher would simply replace ${TORPATH} and use the resulting string for the SETCONF ClientTransportPlugin commands.

Also, we can avoid the IPv6 issue if we assume that the first token in the bridge configuration may be a transport type; if it happens to be an IPv4 or IPv6 address, it won't match any known types so it will be ignored. The only downside we see for this simple approach is that Tor Launcher will not be able to display a warning for unknown types. A slightly smarter approach might be to check that the first token consists entirely of 0-9, A-F, ":" and "." (in which case it should be an IPv4 or IPv6 address with optional :port and not a transport type).

For the UI, we will need to think more about how to handle the fact that the proxy and bridge options are mutually exclusive.

Replying to mcs:

Kathy Brade and I did some evaluation of this issue. We would prefer to have Tor Launcher know as little as possible about the ClientTransportPlugin configuration, especially since this issue should disappear when #8402 (moved) is completed.

Our proposal is to store the ClientTransportPlugin values as hidden preferences, like so: {{{ pref("extensions.torlauncher.transport_plugin.fte", "fte exec ${TORPATH}/PluggableTransports/fteproxy --managed"); pref("extensions.torlauncher.transport_plugin.obfs2,obfs3", "obfs2,obfs3 exec ${TORPATH}/PluggableTransports/obfsproxy.bin managed"); pref("extensions.torlauncher.transport_plugin.flashproxy", "flashproxy exec ${TORPATH}/PluggableTransports/flashproxy-client --register :0 :9000"); }}}

Tor Launcher would simply replace ${TORPATH} and use the resulting string for the SETCONF ClientTransportPlugin commands.

This looks good enough for me (and Tails). It will add a slight maintenance burden for us but it may actually be good that we're forced to pay attention to which transports we pull in via obfsproxy etc.

Note that even when we have #8402 (moved), my (more complex) approach would actually add some value since there would be no need to configure ClientTransportPlugin lines in torrc. However, I do not mind scrapping it in favour of your simpler approach. KISS.

Also, we can avoid the IPv6 issue if we assume that the first token in the bridge configuration may be a transport type; if it happens to be an IPv4 or IPv6 address, it won't match any known types so it will be ignored. The only downside we see for this simple approach is that Tor Launcher will not be able to display a warning for unknown types. A slightly smarter approach might be to check that the first token consists entirely of 0-9, A-F, ":" and "." (in which case it should be an IPv4 or IPv6 address with optional :port and not a transport type).

Then I should reconsider the name of my "DEADBEEF" transport plugin.

Seriously, doesn't xulrunner provide libraries? Interfaces to internal Firefox functions, where an IP validator certainly must exist?

For the UI, we will need to think more about how to handle the fact that the proxy and bridge options are mutually exclusive.

Right, but I suppose that actually is a separate issue deserving a new ticket.

Has there been any progress on this?

Replying to anonym:

Has there been any progress on this?

As of TBB 3.6.2, a local HTTP or SOCKS proxy can be configured for all included Pluggable Transports. The presence of ClientTransportPlugin config statements should not affect regular use of proxies either. If Tails can incorporate (or has incorporated) the PT and tor fixes that are included in TBB 3.6.2, it should no longer be necessary to modify Tor Launcher. If you agree, we can close this bug.

Replying to mcs:

Replying to anonym:

Has there been any progress on this?

As of TBB 3.6.2, a local HTTP or SOCKS proxy can be configured for all included Pluggable Transports. The presence of ClientTransportPlugin config statements should not affect regular use of proxies either. If Tails can incorporate (or has incorporated) the PT and tor fixes that are included in TBB 3.6.2, it should no longer be necessary to modify Tor Launcher. If you agree, we can close this bug.

I see. You have backported the (current) fix for #8402 (moved) into the Tor you ship in TBB 3.6.2. I doubt we want to carry this delta in Tails since we prefer to ship the unmodified, stable Tor versions built by the Tor Project, both to benefit from their QA process, and to ease our maintenance burden.

Since you have this fix in Tor I understand that any a fix in Tor Launcher (as proposed before) does not make sense for you any more. I suppose we just continue to modify our Tor Launcher in Tails until Tor 0.2.6.x goes stable.

Replying to anonym:

[...] until Tor 0.2.6.x goes stable.

Tor 0.2.5.x I hope! :)

Replying to arma:

Tor 0.2.5.x I hope! :)

That'd be great indeed! I just looked at #8402 (moved)'s milestone, which states "Tor: 0.2.6.x-final", and took that at face value.

Replying to anonym:

Replying to arma:

Tor 0.2.5.x I hope! :)

That'd be great indeed! I just looked at #8402 (moved)'s milestone, which states "Tor: 0.2.6.x-final", and took that at face value.

Alas, I had thought that your 6 was surely a typo. It looks like your 6 is accurate. Carry on. :/

Trac:
Status: new to closed
Resolution: N/A to wontfix

closed

mentioned in issue #11658 (closed)

moved to tpo/applications/tor-launcher#11512 (closed)