Feature #7976

Disable LAN access in Tor Browser

Added by anonym 2014-10-01 05:02:06 . Updated 2015-08-11 10:47:56 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Target version:
Tails_1.5
Start date:
2014-11-05
Due date:
% Done:

100%

Feature Branch:
feature/7976-disallow-lan-in-tor-browser
Type of work:
Code
Blueprint:

Starter:
Affected tool:
Browser
Deliverable for:

Description

Ignoring the as of today still not finished analysis of the full scale of Jake’s FOCI12 paper (Feature #5340) can’t we stay on the safe side for at least the Tor Browser by disabling access to RFC1918 (LAN/Private) IP addresses in it, and direct users to the Unsafe Browser for such access?

Even if we put aside the possibility of blocking some classes of deanonymization attacks (or whatever), this change makes sense for usability. Especially after we have isolated I2P from the Tor Browser (Feature #7725) too we would have three distinct browsers whose names rather clearly define their scope:

  • The Tor Browser deals with Tor stuff only.
  • The I2P Browser deals with I2P stuff only.
  • The Unsafe Browser deals with unsafe stuff, like the LAN, which we consider hostile in our threat model.

Or am I missing something about why we need to have the Tor Browser and Unsafe Browser overlap in functionality in this way?

The only drawback I can see is that users that are used to LAN access in the Tor Browser may get confused. If we consider it more than a documentation issue, perhaps we can add a note about it to the error page that the Tor Browser shows in this situation, i.e. “The Proxy server is refusing connections”? Or perhaps users are too well-trained to ignore browser error pages (except the header) by now?

Subtasks

Feature #8218: Decide if we want a dedicated browser for LAN Resolved

100
Feature #9431: Update docs wrt. disabling LAN access in the Tor Browser Resolved

80

Related issues

Related to Tails - Feature #5340: Analyze "vpwns" FOCI12 paper Confirmed
Related to Tails - Feature #7725: Isolate I2P web browsing from Tor Resolved 2014-08-02
Related to Tails - Bug #7951: Refactor code for task-specific browsers Resolved 2014-09-26
Related to Tails - Feature #7774: Rename the Unsafe Web Browser to express its supported usecase more clearly Confirmed 2014-08-11
Blocks Tails - Feature #5293: Block dangerous LAN traffic Confirmed

History

#1 Updated by anonym 2014-10-01 05:02:27

#2 Updated by anonym 2014-10-01 05:02:37

  • related to Feature #7725: Isolate I2P web browsing from Tor added

#3 Updated by intrigeri 2014-10-01 07:33:22

Yes, please.

#4 Updated by sajolida 2014-10-02 09:47:28

  • blocks Feature #7774: Rename the Unsafe Web Browser to express its supported usecase more clearly added

#5 Updated by sajolida 2014-10-02 09:55:22

I would be quite careful about pushing all LAN usage to the Unsafe Browser as this clearly is a big change to what has always been the only “supported” use case for it: connecting to captive portal.

From the top of my mind:

* Is it ok to have a red scary theme for LAN usage? Do we want people to have the feeling of really being unsafe when browsing on the LAN?
* What would be the security features of this extended Unsafe Browser? For example, in terms of isolating the user’s communication to a captive portal and other more personal service on the LAN.
* What kind of UX isolation would it have, for example when downloading files from the LAN? The current Unsafe Browser doesn’t allow you to download stuff, I think that this might be problematic if it is the official browser to access LAN resources.

For me all this is highly related to Feature #7774: How would this browser be called, and how would we advertise it? That discussion probably needs to be publicized on tails-ux@boum.org at some point.

#6 Updated by intrigeri 2014-10-16 07:09:59

  • related to Bug #7951: Refactor code for task-specific browsers added

#7 Updated by BitingBird 2014-10-17 09:53:17

  • Status changed from New to Confirmed

It’s confirmed that LAN should not be accessible in Tor Browser ; still unclear if in unsafe browser or something else.

#8 Updated by anonym 2014-10-21 00:23:34

sajolida wrote:
> * Is it ok to have a red scary theme for LAN usage? Do we want people to have the feeling of really being unsafe when browsing on the LAN?

IMHO, yes. The local network should be considered hostile by default (imagine WiFi hotspots and similar) which is just what we do with when we enable MAC spoofing by default. I think it’s a bug that this is not made more explicit in our design document; at least I am working with that (apparently implicit) assumption. Or am I just not able to find where we specify this more clearly?

> * What would be the security features of this extended Unsafe Browser? For example, in terms of isolating the user’s communication to a captive portal and other more personal service on the LAN.

None. In fact, since we don’t have Torbutton in the Unsafe Browser, we may end up with less state separation. That’s too bad, but IMHO preventing LAN leaks in the Tor Browser is a greater win than that loss for the Unsafe Browser.

> * What kind of UX isolation would it have, for example when downloading files from the LAN? The current Unsafe Browser doesn’t allow you to download stuff, I think that this might be problematic if it is the official browser to access LAN resources.

The same is the case for the I2P Browser (and any future user-separation for applications). I think we may want the browser scripts to create ~/Unsafe Browser Downloads (and ~/I2P Browser Downloads) for this purpos. But there will be permission/ownership issues though, but that could be solved by setting them at script exit, or (better) with some ownership mask mechanism, if there is such a thing.

#9 Updated by intrigeri 2014-11-02 00:07:08

anonym wrote:
> sajolida wrote:
> > * Is it ok to have a red scary theme for LAN usage? Do we want people to have the feeling of really being unsafe when browsing on the LAN?
>
> IMHO, yes. The local network should be considered hostile by default […]

Agreed.

> I think it’s a bug that this is not made more explicit in our design document; at least I am working with that (apparently implicit) assumption. Or am I just not able to find where we specify this more clearly?

I guess that “Eavesdropping and content injection” in “2.2.2 Capabilities, methods and other means of the attacker” is the closest we have to this. I lack the big picture of the PELD spec right now to have an opinion about whether that’s good enough.

> > * What would be the security features of this extended Unsafe Browser? For example, in terms of isolating the user’s communication to a captive portal and other more personal service on the LAN.
>
> None. In fact, since we don’t have Torbutton in the Unsafe Browser, we may end up with less state separation. That’s too bad, but IMHO preventing LAN leaks in the Tor Browser is a greater win than that loss for the Unsafe Browser.

Agreed.

> > * What kind of UX isolation would it have, for example when downloading files from the LAN? The current Unsafe Browser doesn’t allow you to download stuff, I think that this might be problematic if it is the official browser to access LAN resources.
>
> The same is the case for the I2P Browser (and any future user-separation for applications). I think we may want the browser scripts to create ~/Unsafe Browser Downloads (and ~/I2P Browser Downloads) for this purpos. But there will be permission/ownership issues though, but that could be solved by setting them at script exit, or (better) with some ownership mask mechanism, if there is such a thing.

If ACLs work on all our crazy stacks of FS, they would be the perfect tool — otherwise, oh well, it’ll be ugly.

And anyway, then it becomes a UX problem, really. What I’ve seen in the works in the last years (both in AppArmor and GNOME/SELinux) is to have sandboxed apps use privileged helpers, with some amount of IPC over e.g. D-Bus, to interact with the Outside™. I think the AppArmor folks have a kinda working prototype of GTK file chooser that uses this kind of technology. It would be good to check how SubgraphOS solves this problem. In the meantime, possibly additional “Places” would be good enough.

#10 Updated by sajolida 2014-11-05 10:51:38

  • Subject changed from Disable LAN access in Tor Browser, delegate to Unsafe Browser? to Disable LAN access in Tor Browser

#11 Updated by sajolida 2014-11-05 10:53:09

  • Type of work changed from Discuss to Code

Discussed in the November meeting: https://tails.boum.org/contribute/meetings/201411/.

We agreed on moving LAN browsing from outside Tor Browser. Now we need to decide whether we want it to be included in the Unsafe Browser or have a dedicated browser. We considered one of the following options:

  • Unsafe Browser including LAN
  • Unsafe Browser and separate LAN Browser

That’s a UX decision basically, so sajolida will raise the issue on tails-ux@boum.org.

The proposed solution will help deciding something with respect to ticket Feature #7774 as well. Either maybe “Non-anonymous Browser” if the two features are combined in one browser, or “Captive Portal Browser” and “LAN Browser” if the two browsers are separate. But those names would have to be refined.

#12 Updated by BitingBird 2015-01-04 17:33:26

  • Category deleted (176)
  • Affected tool set to Browser

#13 Updated by intrigeri 2015-01-10 09:20:50

#14 Updated by intrigeri 2015-01-11 14:03:32

The plan is to disable LAN access in Tor Browser, and use the Unsafe Browser for that.

#15 Updated by sajolida 2015-03-03 12:42:14

  • blocked by deleted (Feature #7774: Rename the Unsafe Web Browser to express its supported usecase more clearly)

#16 Updated by sajolida 2015-03-03 12:42:29

  • related to Feature #7774: Rename the Unsafe Web Browser to express its supported usecase more clearly added

#17 Updated by intrigeri 2015-03-06 18:57:16

  • Assignee set to sajolida
  • Type of work changed from Code to User interface design

sajolida wrote:
> That’s a UX decision basically, so sajolida will raise the issue on tails-ux@boum.org.

Reassigning accordingly. A child ticket about deciding where exactly to move the LAN browsing functionality would be better, but ETOOLAZY.

#18 Updated by sajolida 2015-03-10 08:56:17

  • Assignee deleted (sajolida)
  • Type of work changed from User interface design to Code

Sorry for loosing track of this. The discussion happened on https://mailman.boum.org/pipermail/tails-ux/2014-November/000101.html. It didn’t raise a great interest but everybody who did (u, tchou, and me) pronounced in favor of moving LAN to the Unsafe Browser.

Moving this as a Code ticket now.

#19 Updated by intrigeri 2015-03-10 09:56:49

> Sorry for loosing track of this. The discussion happened on
> https://mailman.boum.org/pipermail/tails-ux/2014-November/000101.html. It didn’t
> raise a great interest but everybody who did (u, tchou, and me) pronounced in favor
> of moving LAN to the Unsafe Browser.

Thanks for reporting back! And great that we now know what to do :)

#20 Updated by anonym 2015-04-10 11:23:24

  • Status changed from Confirmed to In Progress

Applied in changeset commit:b684b37e11fc74b2ef7547a83ab869639e9af4c5.

#21 Updated by BitingBird 2015-04-10 14:23:05

It’s not assigned to anyone, the fix is applied but it’s not resolved, and it’s being worked on but has no milestone… what’s the status of this ticket, I’m a bit lost?

#22 Updated by intrigeri 2015-04-11 09:55:17

> It’s not assigned to anyone, the fix is applied but it’s not resolved, and it’s being
> worked on but has no milestone… what’s the status of this ticket, I’m a bit lost?

anonym has been working on it, rightfully added a will-fix pseudo-header in the commit message, so this ticket is “In progress”. I guess anonym isn’t sure yet that this will be done for 1.4, so please just be patient :)

#23 Updated by anonym 2015-05-18 16:37:10

  • Assignee set to anonym
  • Target version set to Tails_1.5
  • Feature Branch set to feature/7976-disallow-lan-in-tor-browser

Let’s aim to have this in Tails 1.5. I’ve done quite some work already.

#24 Updated by anonym 2015-05-19 12:00:21

  • Assignee changed from anonym to kytv
  • Target version changed from Tails_1.5 to Tails_1.4.1
  • QA Check set to Ready for QA

anonym wrote:
> Let’s aim to have this in Tails 1.5. I’ve done quite some work already.

Actually, I had done more work than I thought — it’s done as far as implementation and tests go. Given that this is a security fix, let’s aim for Tails 1.4.1 then.

kytv, would you just have a look at the tests (the fix in Tails is a trivial one line removal)? When done, assign to intrigeri for a code review. However, let’s not merge this before the docs have been written.

#25 Updated by sajolida 2015-05-19 18:41:32

Does this block browsing local files? Say file:///home/amnesia/Persistent/Tor Browser/?

#26 Updated by anonym 2015-05-21 09:09:12

sajolida wrote:
> Does this block browsing local files? Say file:///home/amnesia/Persistent/Tor Browser/?

No. The only change is LAN access.

#27 Updated by kytv 2015-05-21 18:03:33

  • Assignee changed from kytv to intrigeri

It all looks good to me and (several) test runs passed.

#28 Updated by intrigeri 2015-05-22 16:32:02

OK, will do the code review! :)

anonym: that’s an important change, and although it’s already been discussed during meetings etc., I don’t feel comfortable merging this (especially in a point-release) without an explicit merge request being sent on tails-dev. In particular, on <del><a class='issue tracker-2 status-3 priority-4 priority-default closed child' href='/code/issues/8711' title='Investigate how we could improve the error message when browsing LAN from usual Tor Browser'>Feature #8711</a></del> you're proposing to go ahead without blocking on that sub-task => please make it clear on tails-dev that the proposed changes include this proposal (and, ideally, ask -ux@ or at least sajolida what they think about it).

#29 Updated by intrigeri 2015-05-26 07:54:08

intrigeri wrote:
> […] an explicit merge request being sent on tails-dev@.

Thanks, anonym, for emailing -dev@.

> In particular, on Feature #8711 you’re proposing to go ahead without blocking on that sub-task => please make it clear on tails-dev@ that the proposed changes include this proposal

I just did that myself.

> (and, ideally, ask -ux@ or at least sajolida what they think about it).

sajolida will see the thread on -dev@ and here.

#30 Updated by intrigeri 2015-05-28 10:37:06

  • Assignee changed from intrigeri to sajolida
  • QA Check changed from Ready for QA to Dev Needed

Code review passes. Reassigning to sajolida, since the only work left to be done (Feature #9431) is on his plate.

#31 Updated by intrigeri 2015-06-28 02:13:50

  • Assignee changed from sajolida to intrigeri
  • Target version changed from Tails_1.4.1 to Tails_1.5
  • QA Check changed from Dev Needed to Ready for QA

The freeze was a week ago => too late to merge for 1.4.1 => postponing.

#32 Updated by intrigeri 2015-07-01 11:11:06

  • Assignee changed from intrigeri to anonym

Code review passes except two nitpicks regarding step names, that I’m happy to implement myself before merging if you agree:

  • I open the LAN web server feels unclear to me: one opens a web page, not a web server. I suggest I open a page on the LAN web server instead.
  • no traffic has flowed to the LAN web server actually checks if any traffic has gone out on the LAN; perhaps we can simply rename it to no traffic has flowed to the LAN?

Other than that, I’m building an ISO and will test soonish.

#33 Updated by intrigeri 2015-07-01 11:29:21

intrigeri wrote:
> Other than that, I’m building an ISO and will test soonish.

Builds fine, quick manual test passes. Not run automated tests yet since our stuff is not compatible with Cucumber 2.0 (current sid).

#34 Updated by intrigeri 2015-07-02 04:44:33

  • QA Check changed from Ready for QA to Info Needed

Also, I see that:

    Then I see "TorBrowserUnableToConnect.png" after at most 20 seconds # features/step_definitions/common_steps.rb:445
["217.12.199.190", "46.4.0.156"]
    And no traffic has flowed to the LAN web server                     # features/step_definitions/torified_browsing.rb:1

Note the ["217.12.199.190", "46.4.0.156"] part. Is it on purpose, or should it perhaps be displayed only in debug mode?

#35 Updated by anonym 2015-07-02 07:30:20

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Info Needed to Ready for QA

intrigeri wrote:
> Code review passes except two nitpicks regarding step names, that I’m happy to implement myself before merging if you agree:
>
> * I open the LAN web server feels unclear to me: one opens a web page, not a web server. I suggest I open a page on the LAN web server instead.
> * no traffic has flowed to the LAN web server actually checks if any traffic has gone out on the LAN; perhaps we can simply rename it to no traffic has flowed to the LAN?

Yes, these renames definitely make sense. Fixed in commit:6b13954. Thanks!

> > Other than that, I’m building an ISO and will test soonish.
>
> Builds fine, quick manual test passes. Not run automated tests yet since our stuff is not compatible with Cucumber 2.0 (current sid).

Please try Feature #9667’s branch test/9667-debian-stretch.

> Also, I see that:
>
> […]
>
> Note the ["217.12.199.190", "46.4.0.156"] part. Is it on purpose, or should it perhaps be displayed only in debug mode?

Whoops. Seems like a leftover from when I debugged some issues I had. Removed in commit:27ab670.

#36 Updated by intrigeri 2015-07-04 08:44:38

OK, code looks good now. Running automated tests, will hopefully merged later today :)

#37 Updated by intrigeri 2015-07-04 09:58:13

  • Status changed from In Progress to Fix committed

Applied in changeset commit:4ca1f9389333f1d084375af241a71220d7ed19f8.

#38 Updated by intrigeri 2015-07-04 10:01:21

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#39 Updated by BitingBird 2015-08-11 10:47:56

  • Status changed from Fix committed to Resolved