Bug #6985: Allows configuring unworkable combination of outbound port filtering + obfsproxy

Bug #6985

Allows configuring unworkable combination of outbound port filtering + obfsproxy

Added by alster 2014-03-28 17:58:29 . Updated 2015-03-23 02:02:31 .

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Tor configuration

Target version:

Tails_1.3.1

Start date:

2014-03-28

Due date:

% Done:

100%

Feature Branch:

feature/tor-launcher-0.2.7.2

Type of work:

Code

Blueprint:

Starter:

Affected tool:

Tor Launcher

Deliverable for:

Description

Yesterday I tried to use Tails for the first time, running Tails 0.23 in a VM on a unrestricted network connection (i.e. not restricted by outbound firewalls or general censorship). I still went for a “complex” setup to get an idea of what it would look/feel like for someone impacted by censorship.

I went for a combination of outbound firewall rules, allowing me to access ports 80 and 443 (the defaults) only, and a requirement to use an obfuscated transport. It was much later, after much repeated manual fingerprint entry, and a lengthy chat with two very supportive developers / community members that I learnt that this combination is not workable. However, the UI neither warns nor prevents such configurations at all. There is also no error message. When you enter any obfs* bridge addresses (a requirement in this scenario) and submit them, the “connect” window just sits there. However, because bridges.torproject.org does not know about the outbound filtering (ports 80,443 only) in this scenario and since the bridges it provides will never connect to ports 80 or 443, none of the bridge addresses you are given will ever work in this scenario.

To reproduce:
After boot, set the keyboard layout on the bottom right corner, but keep the rest on the locale bar as is. Respond “yes” to the “welcome to tails - more options?” prompt and click on “forward” to proceed to the next window.

On this so-called “boot screen”, set the password to “password” twice, keep “Windows camouflage” disabled, disable MAC address spoofing (to prevent the network connectivity issues reported elsewhere), select “This computers’ Internet connection is censored, filtered, or proxied. You need to configure bridge, firewall, or proxy settings” (the alternative option would be “Internet clear of obstacles”).

Click on “login” and the session starts and it does log you in. A warning about virtual machine detection pops up, which can be closed.
When the “Tor network settings” window pops up, click on “configure”, then choose to not require a proxy, but have a restrictive firewall with ports 80 and 443 outbound only, Also choose the option that the ISP blocks or otherwise censors the Tor network. You then reach the step where you need to enter bridge addresses.

Enter any valid obfs* bridge addresses and try to connect. The “Connecting” window will sit in the first stage (progress bar as 0%) and not make any progress, even after 10 minutes. There is no warning about an error, a misconfiguration or impossible choices. There is also no hint on what else to try.

Expected behavior / how to fix:

Do not allow configurations which can not work. If incompatible combinations of configuration options cannot be prevented at this time, please make sure that warnings with references to additional information are displayed both while these are configured and by the time the connection fails. Make the connection fail after a couple minutes programmatically if this is the only way to catch the error, and provide additional information then.

Subtasks

Related issues

Related to Tails - ~~Feature #5479~~: Bridge support	Resolved	2013-07-25
Related to Tails - Bug #8381: Time synchronization displays error with proxy plus bridge	Confirmed	2014-12-03
Blocked by Tails - ~~Bug #8964~~: Tor Launcher has a different set of screens than in TBB 4.0.4	Resolved	2015-02-27

History

#1 Updated by BitingBird 2014-03-28 21:04:47

Category deleted (~~196~~)
Status changed from New to Confirmed

Providing at least warnings seems easy and a very good idea. Could also be in the documentation.

#2 Updated by BitingBird 2014-03-28 21:05:03

Priority changed from High to Elevated

#3 Updated by intrigeri 2014-03-29 09:22:10

related to ~~Feature #5479~~: Bridge support added

#4 Updated by intrigeri 2014-03-29 09:23:09

Assignee set to sajolida
QA Check set to Info Needed

I thinks that’s a bug in upstream Tor Launcher. Reassigning to current frontdesk, so that they can look for a bug in their Trac, and create one if needed.

#5 Updated by sajolida 2014-04-03 14:24:53

Assignee deleted (~~sajolida~~)
Priority changed from Elevated to Normal
QA Check deleted (~~Info Needed~~)
Type of work changed from Code to Upstream

Reported upstream: https://trac.torproject.org/projects/tor/ticket/11395#ticket

#6 Updated by intrigeri 2014-04-03 17:30:51

About the priority downgrade: is this problem a regression? IOW, did Vidalia allow to do just the same, when started in bridge mode, before 0.23?

(If that’s a regression, then it ought to be priority > normal.)

#7 Updated by sajolida 2014-04-04 07:54:40

It’s not a regression, same thing happens to me if I select a restricted
firewall and an obfs3 proxy in Tails 0.22.

#8 Updated by BitingBird 2014-06-21 14:39:01

Category set to Tor configuration

#9 Updated by intrigeri 2014-09-22 11:26:44

Type of work changed from Upstream to Wait

#10 Updated by intrigeri 2014-12-14 17:46:05

related to Bug #8381: Time synchronization displays error with proxy plus bridge added

#11 Updated by BitingBird 2015-01-04 04:37:47

The blocking ticket upstream is fixed, but still not this one.

#12 Updated by intrigeri 2015-03-05 21:35:18

Affected tool set to Tor Launcher

BitingBird wrote:
> The blocking ticket upstream is fixed

It wasn’t, but it was fixed in the version of Tor Launcher shipped with Tor Browser 4.0.4. So this bug will be fixed on our side once ~~Bug #8964~~ is resolved.