Project

General

Profile

Feature #7976

Disable LAN access in Tor Browser

Added by anonym about 3 years ago. Updated about 2 years ago.

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

100%

QA Check:
Pass
Feature Branch:
feature/7976-disallow-lan-in-tor-browser
Type of work:
Code
Blueprint:
Easy:
Affected tool:
Browser

Description

Ignoring the as of today still not finished analysis of the full scale of Jake's FOCI12 paper (#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 (#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 LANResolved

Feature #9431: Update docs wrt. disabling LAN access in the Tor BrowserResolved


Related issues

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

Associated revisions

Revision b684b37e (diff)
Added by anonym over 2 years ago

Disable LAN access in the Tor Browser (Will-fix: #7976).

Revision 4ca1f938
Added by intrigeri over 2 years ago

Merge remote-tracking branch 'origin/feature/7976-disallow-lan-in-tor-browser' into devel

Fix-committed: #7976

History

#1 Updated by anonym about 3 years ago

#2 Updated by anonym about 3 years ago

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

#3 Updated by intrigeri about 3 years ago

Yes, please.

#4 Updated by sajolida about 3 years ago

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

#5 Updated by sajolida about 3 years ago

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 #7774: How would this browser be called, and how would we advertise it? That discussion probably needs to be publicized on at some point.

#6 Updated by intrigeri about 3 years ago

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

#7 Updated by BitingBird about 3 years ago

  • 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 almost 3 years ago

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 almost 3 years ago

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 almost 3 years ago

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

#11 Updated by sajolida almost 3 years ago

  • 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 .

The proposed solution will help deciding something with respect to ticket #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 almost 3 years ago

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

#13 Updated by intrigeri almost 3 years ago

#14 Updated by intrigeri almost 3 years ago

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

#15 Updated by sajolida over 2 years ago

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

#16 Updated by sajolida over 2 years ago

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

#17 Updated by intrigeri over 2 years ago

  • 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 .

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

#18 Updated by sajolida over 2 years ago

  • 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 over 2 years ago

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 over 2 years ago

  • Status changed from Confirmed to In Progress

#21 Updated by BitingBird over 2 years ago

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 over 2 years ago

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 over 2 years ago

  • 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 over 2 years ago

  • 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 over 2 years ago

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

#26 Updated by anonym over 2 years ago

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 over 2 years ago

  • Assignee changed from kytv to intrigeri

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

#28 Updated by intrigeri over 2 years ago

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 #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 (and, ideally, ask -ux@ or at least sajolida what they think about it).

#29 Updated by intrigeri over 2 years ago

intrigeri wrote:

[...] an explicit merge request being sent on tails-dev@.

Thanks, anonym, for emailing -dev@.

In particular, on #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 over 2 years ago

  • 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 (#9431) is on his plate.

#31 Updated by intrigeri over 2 years ago

  • 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 over 2 years ago

  • 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 over 2 years ago

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 over 2 years ago

  • 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 over 2 years ago

  • 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 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 #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 27ab670.

#36 Updated by intrigeri over 2 years ago

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

#37 Updated by intrigeri over 2 years ago

  • Status changed from In Progress to Fix committed

#38 Updated by intrigeri over 2 years ago

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

#39 Updated by BitingBird about 2 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF