Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#10418 closed enhancement (fixed)

Make a "Use Default Bridges" Radio button in the Tor Launcher Bridge UI

Reported by: mikeperry Owned by: brade
Priority: High Milestone:
Component: Applications/Tor Launcher Version:
Severity: Keywords: MikePerry201402R
Cc: dcf1, mcs, mrphs, asn, isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor Launcher should include a radiobutton to use a set of bridges that it pulls from prefs that we can include from extension-overrides.js.

We should set these bridge lines to a set of default PT bridges that will work in most places out of the box.

Child Tickets

Attachments (3)

bridges-wizard.png (261.9 KB) - added by brade 6 years ago.
Proposed first run panels
network-settings.png (105.4 KB) - added by brade 6 years ago.
Proposed network settings dialog
bridges-panel.png (86.5 KB) - added by brade 5 years ago.
revised bridges panel (first run wizard)

Download all attachments as: .zip

Change History (54)

comment:1 Changed 6 years ago by dcf

The list of default bridges that were included in the 2.x pluggable transports bundles is here: https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bundle-torrc-gnulinux.

The funny address 0.0.1.0:1 in the line

Bridge flashproxy 0.0.1.0:1

is a dummy address that is ignored by the plugin. The address can be anything; the important part is the Bridge flashproxy part.

comment:2 Changed 6 years ago by brade

Cc: mcs added

comment:3 Changed 6 years ago by brade

I don't think it will be too difficult to add radio buttons to allow use of a default set of bridges. Will the other non-bridge configuration options be pre-configured in torrc-defaults? Or will Tor Launcher need to configure other parameters?

comment:4 in reply to:  3 ; Changed 6 years ago by dcf

Replying to brade:

I don't think it will be too difficult to add radio buttons to allow use of a default set of bridges. Will the other non-bridge configuration options be pre-configured in torrc-defaults? Or will Tor Launcher need to configure other parameters?

From my point of view, it would be great for the button to effectively uncomment the commented lines in https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/blob/901eab38b929ba1f3784437f2a16ca94aa7fc22e:/Bundle-Data/linux/Data/Tor/torrc-defaults. That is, the Bridge lines, LearnCircuitBuildTimeout, and CircuitBuildTimeout. We already have the ClientTransportPlugin lines uncommented because we have a patch for #5018.

If you want to separate the transports, separate buttons for obfs2/obfs3 and flash proxy, then for obfs2/obfs3 you just need to turn on the Bridge obfs2 and Bridge obfs3 lines. For flash proxy, you want the single Bridge flashproxy 0.0.1.0:1 line as well as LearnCircuitBuildTimeout 0 and CircuitBuildTimeout 60.

LearnCircuitBuildTimeout and CircuitBuildTimeout need some explanation. Without these settings, a flash proxy bridge will fail almost exactly 20% of the time--Tor will refuse to use it, even if it is the only bridge configured, and even if you got a connection to a browser proxy, which is the hard part. The reason is that LearnCircuitBuildTimeout is designed to learn a timeout that excludes the lowest 20% of circuits. When you connect over flash proxy, you are connecting through someone else's browser, so you never know how fast it will be. 20% of the time it will be too slow and leave you with a broken connection. There's a little writeup of the problem in this commit message. CircuitBuildTimeout might not be necessary since we are shipping Tor 0.2.4 (see #6304), as it's set to the default value.

That said, I think this ticket is worth doing even if it is only setting new Bridge lines and not any other settings.

comment:5 in reply to:  4 Changed 6 years ago by dcf

Replying to dcf:

LearnCircuitBuildTimeout and CircuitBuildTimeout need some explanation. Without these settings, a flash proxy bridge will fail almost exactly 20% of the time--Tor will refuse to use it, even if it is the only bridge configured, and even if you got a connection to a browser proxy, which is the hard part.

I just created #10429 which may allow us to get rid of the LearnCircuitBuildTimeout 0 workaround.

comment:6 Changed 6 years ago by dcf

A tor-level alternative to this ticket is comment:22:ticket:5018 (don't start ClientTransportPlugins until UseBridges is set). I think I prefer this ticket, because it would make it easier to enable and disable individual transports.

comment:7 Changed 6 years ago by mcs

Do users need to be able to see and possibly edit the list of default bridges after they choose to use them? Or can the UI be as simple as a set of radio buttons that allows for No Bridges, Use Default Bridges, and Custom Bridges?

comment:8 Changed 6 years ago by lunar

One thing that I don't see mentioned so far is updates. Users who chose “Use Default Bridges”
should probably see their bridge list updated when a newer TBB comes with an updated set of default bridges.

comment:9 Changed 6 years ago by dcf

Cross referencing #10538, which is more generally about configuring pluggable transports.

comment:10 Changed 6 years ago by mikeperry

mcs, brade: I don't think we should support editing the default bridge set. At least not via UI. You have it right, I think. "No Bridges", "Use Default Bridges", and "Custom Bridges".

If we store these bridge lines as torlauncher prefs in https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/extension-overrides.js, will they get updated properly?

I am thinking the most straight-forward way to provide this behavior is to create a pref branch like 'extensions.torlauncher.default_bridges', and create a number of subprefs like extensions.torlauncher.default_bridges.bridge1, extensions.torlauncher.default_bridges.bridge2, and so on to arbitrary bridgeN. That way, if the "Use Default Bridges" radiobutton is selected, Tor Launcher can just enumerate this pref branch, and enter all of the values of those prefs directly as bridge lines. Otherwise, we ignore them entirely. Does that sound like it could work?

comment:11 in reply to:  10 Changed 6 years ago by mcs

Replying to mikeperry:

If we store these bridge lines as torlauncher prefs in https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/extension-overrides.js, will they get updated properly?

Updating extension-overrides.js will not be a problem. But once the user chooses "Use Default Bridges" the settings will be fed to tor by Tor Launcher and thus written to torrc. The current plan is to not update torrc as part of any automated update process. That means that, if "Use Default Bridges" is active, Tor Launcher would need to replace all of the old settings with new ones (pulled from the preferences). That would work OK if the only config items that need to be set are bridge lines. But I am not sure how Tor Launcher will detect that a new set of preferences has arrived (thereby triggering a refresh of the bridge settings via the control port). Setting them every time TBB starts up would work but is kind of ugly.


I am thinking the most straight-forward way to provide this behavior is to create a pref branch like 'extensions.torlauncher.default_bridges', and create a number of subprefs like extensions.torlauncher.default_bridges.bridge1, extensions.torlauncher.default_bridges.bridge2, and so on to arbitrary bridgeN. That way, if the "Use Default Bridges" radiobutton is selected, Tor Launcher can just enumerate this pref branch, and enter all of the values of those prefs directly as bridge lines. Otherwise, we ignore them entirely. Does that sound like it could work?

Yes, that should work, with the caveats I mentioned above.

Another idea (from Kathy) is to ship a second torrc-defaults that has the default bridge settings. If someone enables the "Use Default Bridges" setting, Tor Launcher would tell tor to load the alternate torrc-defaults. But I think transitioning from one torrc-defaults to another will require a complete restart of the tor process (which is not something Tor Launcher knows how to do yet).

comment:12 Changed 6 years ago by mikeperry

I think completely resetting bridge settings to use the values from the prefs every startup (and also every time that pref is selected) is a fine option. Another edge case this will cover is if the user enters manual bridges at one point and then decides to try switching to the defaults at a later date. Tor launcher should wipe their current bridge settings in that case, too.

Changed 6 years ago by brade

Attachment: bridges-wizard.png added

Proposed first run panels

Changed 6 years ago by brade

Attachment: network-settings.png added

Proposed network settings dialog

comment:13 Changed 6 years ago by brade

Please review and comment on the attached screenshots. For the first-run wizard, Mark and I decided that it makes sense to insert a new panel that asks a Yes/No question. This is more consistent with the other parts of the wizard and it also allows us to introduce the concept of bridges.

comment:14 Changed 6 years ago by lunar

I don't know if it's worth mentioning here but I have seen a couple messages on the help desk from users requesting bridges… because they could not reach some hidden services. Maybe replacing “hidden relays” by “unlisted relays” or something close enough could prevent some confusion?

comment:15 in reply to:  14 Changed 6 years ago by mcs

Replying to lunar:

I don't know if it's worth mentioning here but I have seen a couple messages on the help desk from users requesting bridges… because they could not reach some hidden services. Maybe replacing “hidden relays” by “unlisted relays” or something close enough could prevent some confusion?

Thanks. We replaced "hidden relays" with "unlisted relays" as you suggested.

We finished the UI and backend changes and committed everything:

https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/5a9a0c2699110e6b6b0f2267b71aefacbdba74ce

Currently this is only on a bug10418 branch in the .../user/brade/tor-launcher.git repo.
Also, we did not add any default bridges to the preferences yet.

Next we will test with the TBB 3.x-based PT bundles. We also need to check on a couple of localization issues.

comment:16 Changed 6 years ago by brade

Kathy and I did some testing on Mac OS 10.9.1 with a PT bundle that we downloaded from https://people.torproject.org/~dcf/pt-bundle/3.6-beta-1-20140112/

The Tor Launcher "Use Default Bridges" option seems to work well, so I think this code is ready for a PT/TBB 3.6 Tor Launcher branch. Certainly it will be good to have other developers and testers try it out soon.

One issue we have to resolve is that if a particular PT is not being used (e.g., no bridges are configured), tor emits warnings such as:

Jan 22 15:20:41.000 [warn] Pluggable transport proxy (obfs2,obfs3 exec
PluggableTransports/obfsproxy.bin managed) does not provide any needed transports
and will not be launched.

This is no big deal, except if Tor Launcher sees lines like that it puts a caution icon on the "Open Settings" and "Copy Tor Log to Clipboard" buttons. That might generate some undesirable traffic to the help desk.

A side note: We experienced some flakiness with flashproxy (e.g., it does not find enough remotes at first, but if I use telnet to initiate an inbound TCP connection to the flashproxy port it often wakes up and finds more remotes). But we don't have any past experience flashproxy so we do not really know what to expect.

comment:17 Changed 5 years ago by dcf

Something to think about: It would be good if flash proxy could be disabled by default, until the user has taken the steps to enable port forwarding at FlashProxyHowto. That is, it would be nice if "enable default bridges" turned on the obfsproxy bridges, but bridge flashproxy 0.0.1.0:1 were a separate switch (or even just absent from the interface, requiring you to input the bridge address manually). The reason is that enabling flash proxy without having set up port forwarding is useless and creates a little bit of network noise: an HTTP request that appears to go to www.google.com, and several incoming connection attempts from random IP addresses.

As it stands now, the majority of flash proxy registrations are broken, because it's enabled by default in the PTTBB, but most people haven't set it up.

Last edited 5 years ago by dcf (previous) (diff)

comment:18 Changed 5 years ago by mikeperry

dcf: What if we just didn't include flashproxy in the default bridge prefs? Also, is UPNP likely to remain off or insufficient? If so, should we just provide these instructions from BridgeDB, and require that flashproxy remain a custom bridge type only?

I would like to avoid cluttering the "Use default Bridges" UI with additional configuration steps and optional instructions, if possible. I'm of the opinion that it should remain a no-config option that provides bridges for the most likely functional transport type only.

I also still don't like probing as a general matter, especially in a way that happens every single startup. If we do have to go the config route or multiple transport type route, it seems like we should make the prefbranches be extensions.torlauncher.default_bridge.type.N rather than extensions.torlauncher.default_bridge.N, and have the user pick a type and stick with it.

comment:19 in reply to:  18 ; Changed 5 years ago by dcf

Replying to mikeperry:

dcf: What if we just didn't include flashproxy in the default bridge prefs? Also, is UPNP likely to remain off or insufficient? If so, should we just provide these instructions from BridgeDB, and require that flashproxy remain a custom bridge type only?

Not including flash proxy in the default bridges is a good idea. I recommend it. Now that we know LearnCircuitBuildTimeout is not needed, the only torrc changes needed to activate flash proxy are Bridge lines, and those can be edited in Tor Launcher. We can document how to do it in FlashProxyHowto.

Putting instructions in BridgeDB may not make sense because you don't use BridgeDB with flash proxy. I guess if you think of a beginning user who doesn't know where to look, so they look at BridgeDB, it would make sense to include some instructions like "this may work for you if you turn it on." For people who don't need it, it's a lot of extra information though.

I don't know whether tor-fw-helper is going to be turned on. I don't think I have any say in that. My guess is it would greatly increase the number of people who are able to use flash proxy automatically. I'm sure there will still be a lot of people (behind two NATs, behind institutional NATs) for whom it won't work. Activating flash proxy's support for port forwarding, assuming tor-fw-helper is included in the bundle, is a matter of adding an option to the ClientTransportPlugin command line. It might be nice to build a test bundle including tor-fw-helper and ask people to test it.

comment:20 in reply to:  19 ; Changed 5 years ago by mikeperry

Replying to dcf:

Replying to mikeperry:

dcf: What if we just didn't include flashproxy in the default bridge prefs? Also, is UPNP likely to remain off or insufficient? If so, should we just provide these instructions from BridgeDB, and require that flashproxy remain a custom bridge type only?

Not including flash proxy in the default bridges is a good idea. I recommend it. Now that we know LearnCircuitBuildTimeout is not needed, the only torrc changes needed to activate flash proxy are Bridge lines, and those can be edited in Tor Launcher. We can document how to do it in FlashProxyHowto.

Ok, this sounds fine.

Putting instructions in BridgeDB may not make sense because you don't use BridgeDB with flash proxy. I guess if you think of a beginning user who doesn't know where to look, so they look at BridgeDB, it would make sense to include some instructions like "this may work for you if you turn it on." For people who don't need it, it's a lot of extra information though.

Well, I really think BridgeDB will be heading in some form of "Pick your pluggable transport type" anyway as well, with separate landing pages for each bridge type. The "Get FlashProxy Bridges" page could just include the entirety of the FlashProxy HOWTO (but hopefully a simpler form of it once we solve the port forwarding problem).

I don't know whether tor-fw-helper is going to be turned on. I don't think I have any say in that. My guess is it would greatly increase the number of people who are able to use flash proxy automatically. I'm sure there will still be a lot of people (behind two NATs, behind institutional NATs) for whom it won't work. Activating flash proxy's support for port forwarding, assuming tor-fw-helper is included in the bundle, is a matter of adding an option to the ClientTransportPlugin command line. It might be nice to build a test bundle including tor-fw-helper and ask people to test it.

Since this decision is effectively mine, I can tell you that you do in fact have a say in that, and indeed I think you just proposed a viable plan! ;)

If tor-fw-helper actually ends up working out in a test bundle, and if we can limit its execution to people who actually try to use flashproxy, it seems like a no-brainer to me to include it in the default bundle.

comment:21 Changed 5 years ago by mikeperry

mcs, brade: Ok, we also made some progress discussing this on IRC. I think we do want to break out the 'extensions.torlauncher.default_bridge.' prefbranch into 'type' subtrees, and provide another radio button to allow users to select the PT type they want. Tor Launcher would then only configure Tor with the bridge lines from that type subtree. We should also add "(recommended)" as a separate DTD entity, so we can put that localized entity text next to a specific PT type we know works for a specific localized bundle. I think radiobutton type that this "(recommended)" text appears next to should be governed by another pref (that way we can switch it during the localization bundling process).

The PT choice should be recorded in a user pref and remembered across updates, even if an update changes the default set of bridges.

If Tor then fails to connect using a selected PT type, Tor Launcher should bounce back to this PT type choice dialog and indicate to the user they should either check their Internet connection, or try a new PT type.

For the actual radiobutton text, I think we can keep it simple and use the 'type' portion of the prefbranch directly as the radiobutton text, and nothing more save for an optional "(recommended)". We won't need to localize these. Using pref names like 'extensions.torlauncher.default_bridge.ObfsProxy.1', 'extensions.torlauncher.default_bridge.FlashProxy.1', and 'extensions.torlauncher.default_bridge.ScrambleSuit.1' would mean that three radio buttons would appear: "ObfsProxy", "FlashProxy", and "ScrambleSuit".

Does this make sense? Does it sound plausible and feasible?

comment:22 Changed 5 years ago by mrphs

Cc: mrphs added

comment:23 in reply to:  21 Changed 5 years ago by brade

Replying to mikeperry:

I think we do want to break out the 'extensions.torlauncher.default_bridge.' prefbranch into 'type' subtrees, and provide another radio button to allow users to select the PT type they want. Tor Launcher would then only configure Tor with the bridge lines from that type subtree.

I think we can make this work. Is it OK to use a dropdown menu instead of radio buttons? Mark and I mocked something up and we will attach a screenshot in a minute.

If Tor then fails to connect using a selected PT type, Tor Launcher should bounce back to this PT type choice dialog and indicate to the user they should either check their Internet connection, or try a new PT type.

We may need some changes in tor to make the above happen. When all of the configured bridges are unusable, I don't think tor generates a bootstrap failure or reports an error. This means that the Tor Launcher progress window will just sit there indefinitely without making progress and the user won't know what is going on. I thought there was an open bug about this but I cannot find it.

Changed 5 years ago by brade

Attachment: bridges-panel.png added

revised bridges panel (first run wizard)

comment:24 Changed 5 years ago by mikeperry

Cc: asn added

This looks good. asn notes though that the example bridge line in "Use Custom Bridges" is confusing. Perhaps it should say something like "bridge type address:port" without the "OR". We're going to converge on that anyway, at least for the non-Tor types.

comment:25 Changed 5 years ago by isis

Cc: isis added

comment:26 in reply to:  24 ; Changed 5 years ago by mcs

Replying to mikeperry:

This looks good. asn notes though that the example bridge line in "Use Custom Bridges" is confusing. Perhaps it should say something like "bridge type address:port" without the "OR". We're going to converge on that anyway, at least for the non-Tor types.Replying to mikeperry:
This looks good. asn notes though that the example bridge line in "Use Custom Bridges" is confusing. Perhaps it should say something like "bridge type address:port" without the "OR". We're going to converge on that anyway, at least for the non-Tor types.

In Tor Launcher, the "bridge" part is optional and it seems simpler to omit it. We will definitely get rid of the OR.

Do we want to add a type for plain Tor bridges? Tor Launcher could just strip it out when getting/setting the configuration; eventually, if tor is modified to support the new type TL can be changed to just pass it through to tor. If the answer is "yes" we will need to decide on a good type keyword to use. Maybe just "tor"?

The other thing mentioned on IRC was the idea of using the same type keywords in the dropdown menu as we use in torrc. Should we do that? Then the dropdown would look something like:

   +----------------------+
   |  obfs3 (recommended) |
   |  flashproxy          |
   |  scramblesuit        |
   +----------------------+
  

comment:27 in reply to:  26 ; Changed 5 years ago by asn

Replying to mcs:

Replying to mikeperry:

This looks good. asn notes though that the example bridge line in "Use Custom Bridges" is confusing. Perhaps it should say something like "bridge type address:port" without the "OR". We're going to converge on that anyway, at least for the non-Tor types.Replying to mikeperry:
This looks good. asn notes though that the example bridge line in "Use Custom Bridges" is confusing. Perhaps it should say something like "bridge type address:port" without the "OR". We're going to converge on that anyway, at least for the non-Tor types.

In Tor Launcher, the "bridge" part is optional and it seems simpler to omit it. We will definitely get rid of the OR.

Do we want to add a type for plain Tor bridges? Tor Launcher could just strip it out when getting/setting the configuration; eventually, if tor is modified to support the new type TL can be changed to just pass it through to tor. If the answer is "yes" we will need to decide on a good type keyword to use. Maybe just "tor"?

The other thing mentioned on IRC was the idea of using the same type keywords in the dropdown menu as we use in torrc. Should we do that? Then the dropdown would look something like:

   +----------------------+
   |  obfs3 (recommended) |
   |  flashproxy          |
   |  scramblesuit        |
   +----------------------+
  

Yes, I think the version with the literal names ('obfs3' instead of 'ObfsProxy') is better. Since we are exposing transport names to users, let's expose the correct ones. Maybe we could do

obfs3 (obfsproxy) [recommended]

so that people recognize the obfsproxy name.

comment:28 in reply to:  27 Changed 5 years ago by mcs

Replying to asn:

Yes, I think the version with the literal names ('obfs3' instead of 'ObfsProxy') is better. Since we are exposing transport names to users, let's expose the correct ones. Maybe we could do

obfs3 (obfsproxy) [recommended]

so that people recognize the obfsproxy name.

I don't have enough context and sense of history to know if it is worthwhile to include "obsproxy." Will many people recognize that name? If so, is "obfs3" to "obfs3 (obfsproxy)" the only special mapping we need to add to Tor Launcher or are there others?

comment:29 Changed 5 years ago by mcs

Kathy and I finished the work to select default bridges by type. We also addressed various other loose ends. The latest and greatest code is here:

https://gitweb.torproject.org/user/brade/tor-launcher.git/shortlog/refs/heads/bug10418

Preference values that should be pre-set / bundled:

extensions.torlauncher.default_bridge_recommended_type
extensions.torlauncher.default_bridge.TYPE.#

The choice the user makes for transport type is stored in:

extensions.torlauncher.default_bridge_type

If that pref has a non-empty value, Tor Launcher uses default bridges, reconfiguring them each time TBB is started. If the stored transport type does not match any of the available default bridges, Tor Launcher will display an error message and prompt the user to choose a different type (this situation could happen after an upgrade, and we did not want to silently go from using bridges to not using any bridges).

Known issues:
1) Tor Launcher does not do anything special to detect the situation where Tor is unable to successfully bootstrap using the bridges that are chosen. On the other hand, if this happens while the user is still in the initial setup wizard, they will be sitting on the bridge settings wizard panel when the error occurs... which is probably where we want them to be anyway.

2) We did not really add any support in Tor Launcher for a pseudo-transport named "tor". Maybe we should just wait until tor itself supports that... in the meantime, you can add a set of default bridges that appear to the user (in the dropdown menu) to use a transport named tor, e.g.,

pref("extensions.torlauncher.default_bridge.tor.1", "XXX.XXX.163.47:23");
pref("extensions.torlauncher.default_bridge.tor.2", "XXX.XXX.213.48:23");

3) We do not add "(obfsproxy)" or other alternate names to the dropdown menu. Tor Launcher just displays the TYPE from the extensions.torlauncher.default_bridge.TYPE.# preferences.

comment:30 in reply to:  20 Changed 5 years ago by dcf

Replying to mikeperry:

Replying to dcf:

It might be nice to build a test bundle including tor-fw-helper and ask people to test it.

Since this decision is effectively mine, I can tell you that you do in fact have a say in that, and indeed I think you just proposed a viable plan! ;)

If tor-fw-helper actually ends up working out in a test bundle, and if we can limit its execution to people who actually try to use flashproxy, it seems like a no-brainer to me to include it in the default bundle.

Here is a branch that packages tor-fw-helper on top of TBB 3.5.2. It's set up to have flashproxy-client listen on an ephemeral port and use tor-fw-helper to forward it. I sent a request to tor-qa that it be tested.

https://lists.torproject.org/pipermail/tor-qa/2014-February/000324.html
https://people.torproject.org/~dcf/pt-bundle/3.5.2-fwhelper-1/
https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/shortlog/refs/heads/tor-fw-helper

There are existing tickets #4959 and #5213 that are about enabling tor-fw-helper. I closed #4959 and pointed it to #5213; I guess discussion of the patch can happen there.

The only part that's not a no-brainer, assuming the branch actually works on all platforms, is that the safety of the miniupnpc and libnatpmp libraries is unknown (comment:3:ticket:9033). I didn't review it myself.

comment:31 Changed 5 years ago by mikeperry

Keywords: MikePerry201402R added

comment:32 Changed 5 years ago by mikeperry

#11069 has been filed about the Tor PT bootstrap hang issue from comment:23.

#11071 has been filed about future work on the selection dropdown based on discussion in the dev meeting. I want something sooner rather than later, though, so I think we will likely merge this form first, and then deliberate and decide on the exact layout of #11071 later.

comment:33 Changed 5 years ago by brade

We collapsed and rebased these Tor Launcher changes onto a new branch, here:

https://gitweb.torproject.org/user/brade/tor-launcher.git/shortlog/refs/heads/bug10418-rev2

comment:34 Changed 5 years ago by mikeperry

Resolution: fixed
Status: newclosed

Ok, thanks for the cleanup. I went ahead and merged this into master, and branched the previous master off into maint-0.2.4 (for 3.5.x).

comment:35 Changed 5 years ago by mikeperry

Oh, if all goes well, this should appear in a nightly soon at https://people.torproject.org/~linus/builds/

comment:36 Changed 5 years ago by mikeperry

And to post thrice without thinking once, that nightly will not include any actual PT types or default bridges yet. I sent a mail to the PT crew asking for some bridge lines to add. Will add them as soon as I hear from them, but they might not get back to me before the nightly is built.

comment:37 Changed 5 years ago by mikeperry

Resolution: fixed
Status: closedreopened

This appears to have a bug with how it handles the torrc. The ClientTransportPlugin lines are not being preserved. The result is that if you configure pluggable transports like obfs3, upon the second invocation the browser will fail to connect to the network. You can observe this with gk's test build for OSX, which contain working obfs3 bridge lines.

We should be preserving these ClientTransportPlugin lines regardless of the PT configuration (so that the user can go back and choose to use PTs at a later point, if necessary).

I reopened this ticket, but since this was already merged, we can open a new ticket for this if you like, but I think this does block an actual 3.6-beta release either way.

comment:38 Changed 5 years ago by mikeperry

Woops, forgot to provide the link to gk's builds: https://people.torproject.org/~gk/builds/3.6-beta-1/

comment:39 in reply to:  37 ; Changed 5 years ago by mcs

Replying to mikeperry:

This appears to have a bug with how it handles the torrc. The ClientTransportPlugin lines are not being preserved. The result is that if you configure pluggable transports like obfs3, upon the second invocation the browser will fail to connect to the network. You can observe this with gk's test build for OSX, which contain working obfs3 bridge lines.

I cannot find a way to cause the ClientTransportPlugin lines to be lost. How can I reproduce the problem you saw?

The ClientTransportPlugin settings are in torrc-defaults, and Tor Launcher never does anything to modify ClientTransportPlugin configuration.

The second time I start TBB, I do see several messages like the following in the tor log:

Mar 04 09:57:54.000 [warn] We were supposed to connect to bridge '109.105.109.163:47779'
using pluggable transport 'obfs3', but we can't find a pluggable transport proxy
supporting 'obfs3'. This can happen if you haven't provided a ClientTransportPlugin
line, or if your pluggable transport proxy stopped running.

But the obfs3 process is running:

brade 3270 ... S 10:03AM 0:01.12 python PluggableTransports/obfsproxy.bin managed

And bootstrapping finishes. In fact, netstat shows outbound TCP connections to some of the configured obfs3 bridges.

I wonder if there is a race inside tor between starting the client transport plugins and trying to use the bridges? As we discussed, when default bridges are configured, Tor Launcher always starts tor with DisableNetwork=1. Then it does a SETCONF to set UseBridges=1 and to configure the bridges (Bridge=<list>). Then it does a second SETCONF with DisableNetwork=0.

comment:40 in reply to:  39 ; Changed 5 years ago by brade

Replying to mcs:

I wonder if there is a race inside tor between starting the client transport plugins and trying to use the bridges? As we discussed, when default bridges are configured, Tor Launcher always starts tor with DisableNetwork=1. Then it does a SETCONF to set UseBridges=1 and to configure the bridges (Bridge=<list>). Then it does a second SETCONF with DisableNetwork=0.

We did a little more investigation and learned that the "can't find a pluggable transport proxy
supporting 'obfs3'" warnings are emitted by tor even if tor is started with networking enabled and if no SETCONF commands are issued by Tor Launcher.

Interestingly, if we remove cached-descriptors and cached-descriptors.new before starting TBB, those warnings are not emitted by tor.

Here are some steps to reproduce the problem just by running tor at the command line.

1) Download and install one of GK's TBB builds from https://people.torproject.org/~gk/builds/3.6-beta-1/ (we tested on Mac OS).

2) edit Data/Tor/torrc and place these lines in it:

Bridge obfs3 83.212.101.3:60475 A09D536DD1752D542E1FBB3C9CE4449D51298239
Bridge obfs3 109.105.109.163:47779 844B1F53FFD548C998F8D3B01B7E19FA07C3396E
Bridge obfs3 109.105.109.163:38980 9D7259A696F7DAB073043B28114112A46D36CFFD
Bridge obfs3 169.229.59.74:31493 AF9F66B7B04F8FF6F32D455F05135250A16543C9
Bridge obfs3 208.79.90.242:35658 BA61757846841D64A83EA2514C766CB92F1FB41F
Bridge obfs3 169.229.59.75:46328 AF9F66B7B04F8FF6F32D455F05135250A16543C9
UseBridges 1

3) Run tor like this:

cd Tor
./tor --defaults-torrc ../Data/Tor/torrc-defaults -f ../Data/Tor/torrc \
      --DataDirectory ../Data/Tor GeoIPFile ../Data/Tor/geoip

4) Run tor a second time and you will see some "can't find a pluggable transport proxy
supporting 'obfs3'" warnings. Also, netstat will probably show outbound TCP connections to some of the bridges for which warnings were emitted... which does not make a lot of sense to me. The warnings seem spurious.

5) rm Data/Tor/cached-descriptors and run tor a third time. The warnings will not be emitted.

comment:41 Changed 5 years ago by mikeperry

When I hit the bug, bootstraping did not finish. I did get the same warnings from Tor though. The only way I could get bootstrap to finish was to remove the bundle and start it again (which would of course clear cached-descritors). I also noticed that the torrc was missing the ClientTransportPlugin lines (but not the bridge lines -- those were still there) after first run, which would be consistent with the warnings..

comment:42 Changed 5 years ago by mikeperry

My mistake guys. I was looking only at torrc. torrc-defaults still has the ClientTransportPlugin lines.

I am also able to get 50% into the bootstrap process a second time, but progress hangs at that point for much longer than I'd expect, but if I wait a couple minutes, it does eventually connect (though there is still that "Open settings" warning icon due to the warn log).

If I click through the config dialog again as soon as the warning button appears, then it seems to work much more quickly.

Perhaps we are looking at a pair of Tor bugs here, but different ones than I thought.

comment:43 in reply to:  42 Changed 5 years ago by dcf

Replying to mikeperry:

I am also able to get 50% into the bootstrap process a second time, but progress hangs at that point for much longer than I'd expect, but if I wait a couple minutes, it does eventually connect (though there is still that "Open settings" warning icon due to the warn log).

If it stalls at 50% for almost exactly 60 seconds, then it is probably #9229. It can stall at either 20% or 50%, I think depending on the state of the cache.

comment:44 in reply to:  40 Changed 5 years ago by asn

Replying to brade:

Replying to mcs:

I wonder if there is a race inside tor between starting the client transport plugins and trying to use the bridges? As we discussed, when default bridges are configured, Tor Launcher always starts tor with DisableNetwork=1. Then it does a SETCONF to set UseBridges=1 and to configure the bridges (Bridge=<list>). Then it does a second SETCONF with DisableNetwork=0.

We did a little more investigation and learned that the "can't find a pluggable transport proxy
supporting 'obfs3'" warnings are emitted by tor even if tor is started with networking enabled and if no SETCONF commands are issued by Tor Launcher.

Interestingly, if we remove cached-descriptors and cached-descriptors.new before starting TBB, those warnings are not emitted by tor.

Here are some steps to reproduce the problem just by running tor at the command line.

Thanks for the reproducible instructions. I did a bit of debugging on this. It can be found in #11156.

comment:45 Changed 5 years ago by mikeperry

Resolution: fixed
Status: reopenedclosed

Ok, I think this can go back to closed. I have tagged all the Tor tickets that it has generated as 'tbb-needs', as per nickm's request: https://trac.torproject.org/projects/tor/query?keywords=~tbb-needs

So far, it is my estimation that nothing there blocks the beta, though I think fixes for #9229 and #11156 should be backported to 0.2.4.x or applied by us before we call 3.6 stable. Unless someone screams, #11069 will be applied in 3.6-beta-1 itself.

Last edited 5 years ago by mikeperry (previous) (diff)

comment:46 Changed 5 years ago by mttp

The option for ORPort bridges need to be included in the dropdown menu. ORPort should also be set as the default type. According to metrics.torproject.org, ORPort is the most used bridge type by an order of magnitude.

As is, this interface in effect deprecates ORPort bridges, and there is no reason to do that. ORPort bridges are still useful on networks where Tor is blocked, but not by an intelligent firewall. With this interface, there is no way for users who already have ORPort bridges that work to use them.

If ORPort bridges are not included in the dropdown menu, we will have a lot of confused users emailing the help desk. The BridgeDB interface makes ORPort the default choice for bridges, and the tor-launcher does not let you use ORPort at all. Users who don't realize this will enter their ORPort bridges as obfs3 bridges, and then Tor will fail for them and they won't know why.

Last edited 5 years ago by mttp (previous) (diff)

comment:47 Changed 5 years ago by mttp

Resolution: fixed
Status: closedreopened

comment:48 in reply to:  46 Changed 5 years ago by mcs

Replying to mttp:

The option for ORPort bridges need to be included in the dropdown menu. ORPort should also be set as the default type. According to metrics.torproject.org, ORPort is the most used bridge type by an order of magnitude.

The dropdown only applies to the default (bundled, preconfigured) bridges. If we want to include some preconfigured ORPort bridges we could... but I have not see anyone suggest that so far. Users can copy/paste the configuration for any type of bridges into the text box below the "Use Custom Bridges" radio button.

If ORPort bridges are not included in the dropdown menu, we will have a lot of confused users emailing the help desk. The BridgeDB interface makes ORPort the default choice for bridges, and the tor-launcher does not let you use ORPort at all. Users who don't realize this will enter their ORPort bridges as obfs3 bridges, and then Tor will fail for them and they won't know why.

I do not think the above is accurate. The only thing I can see that might make it seem like ORPort bridges are not supported is that the example (gray text shown before you enter anything in the textbox) reads "type address:port" and currently there is no type for ORPort bridges.

comment:49 Changed 5 years ago by mikeperry

Right. In fact, nothing in this design here even prevents us from adding a list of default "Tor" type bridge IPs to that dropdown without a code change, but I certainly don't think they should be the default.

Again, these would be hardcoded IP+port pairs for the "Use default bridges" dropdown, and this selection has nothing to do with the copy+paste UI box (which is only activated if you use custom bridges).

One possible takeaway from mttp's confusion is that perhaps the "Use default bridges" dropdown should become greyed out if the "Use Custom Bridges" radiobutton is selected, so that it is more clear to the user that the dropdown type is not applying to the custom text entry. It probably should also be the case that the "Use Custom Bridges" and its entrybox should be greyed if "Use Default bridges" is selected, to make it more clear that the two options are mutually exclusive.

Would this improve the situation?

If so, I am inclined to think that change should probably either be part of #11071, or under a new ticket (ie "Improve bridge entry UI" that has #11071 as a child or something). There may be other forms of confusion that we learn about as this is deployed.

comment:50 Changed 5 years ago by mikeperry

Resolution: fixed
Status: reopenedclosed

Ok, I tried to improve mttp's confusion with some layout changes, and also changed some strings based on feedback on tor-qa and tbb-dev: https://people.torproject.org/~mikeperry/images/Settings.jpg

I also filed #11180 for future UI tweaks based on post-release feedback.

comment:51 Changed 5 years ago by mcs

I committed a couple of minor followup fixes:
https://gitweb.torproject.org/tor-launcher.git/commit/60c933d5e260303a32df3417332357c2950f439b

(increase dialog and wizard height to avoid scollbars on Mac OS; fix id for the associated control).

Note: See TracTickets for help on using tickets.