Bug #10339

Are the security risks introduced by Vidalia-like tools worth it?

Added by anonym 2015-10-06 02:22:18 . Updated 2017-09-18 08:19:24 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2015-10-06
Due date:
% Done:

50%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
Affected tool:
Onion Circuits
Deliverable for:

Description

In Bug #9366 we have concluded that as long as we run Vidalia (or anything similar, like Tor Monitor in the future) we must assume that a compromised amnesia user also means that the attacker has full access to Vidalia and hence Tor’s full circuit/connection state.

It seems we have two options:

  • Prefer security: uninstall Vidalia, scrap the Tor Monitor plans, and never enable the circuit view in the Tor Browser.
  • Prefer usability: keep Vidalia/Tor Monitor, and then we can also enable the circuit view in the Tor Browser.
  • (Secret third option: make this configurable in the Greeter… eh. :S)

Let the battle between security nerds and UX people begin!

Subtasks

Related issues

Related to Tails - Feature #6841: Replace Vidalia Resolved 2015-03-03
Related to Tails - Feature #12213: Wayland in Tails 5.0 (Bullseye) In Progress 2017-09-02
Related to Tails - Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed Confirmed 2015-05-09

History

#1 Updated by anonym 2015-10-06 02:23:16

  • Target version set to Tails_1.8

I’m optimistically “scheduling” this discussion so it happens this year.

#2 Updated by anonym 2015-10-06 02:29:46

  • blocks Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed added

#3 Updated by themusicgod1 2015-10-13 19:48:15

Hard to say, but if you know you’re going from an area you cannot reliably connect to the network as an exit node to one where you can, previously with vidalia you could control which you were without resorting to configuration files. It’s not clear how to do this without rebooting, without it. The question I’d ask is “which is more important: more exit nodes or more security on the end-user side?”

#4 Updated by intrigeri 2015-10-23 09:16:05

  • Assignee set to anonym
  • Type of work changed from Debian to Discuss

It seems to me that Bug #9365 should be blocking this ticket, not the other way round: to decide where we want to set the cursor between security and usability (I hate to write it) we need to know what’s the actual security problem that is at stake, no?

#5 Updated by sajolida 2015-11-08 02:38:16

  • blocked by deleted (Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed)

#6 Updated by sajolida 2015-11-08 02:38:27

  • blocked by Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed added

#7 Updated by sajolida 2015-11-08 02:46:55

#8 Updated by kurono 2015-12-03 09:52:48

May be a naive question, but what about the “Unsafe Browser”?
As described here: https://labs.riseup.net/code/issues/9366,
an attacker with control over the amnesia user could use
“X tools” to open it and go to “whatsmyip” kind of sites,
to get the real IP?

#9 Updated by intrigeri 2015-12-05 13:35:30

  • Target version changed from Tails_1.8 to Tails_2.0

(This month’s monthly meeting was skipped, and the discussion wasn’t started on -dev@ yet, so let’s postpone.)

#10 Updated by themusicgod1 2015-12-08 10:52:23

kurono wrote:
> May be a naive question, but what about the “Unsafe Browser”?
> As described here: https://labs.riseup.net/code/issues/9366,
> an attacker with control over the amnesia user could use
> “X tools” to open it and go to “whatsmyip” kind of sites,
> to get the real IP?

Wouldn’t it make much more sense to remove the “Unsafe Browser” or whatever else than vidalia/TorMonitor, then, if we’re removing things? What is it about the “Unsafe Browser” that warrants inclusion above vidalia/TorMonitor, wrt this security tradeoff?

#11 Updated by kytv 2015-12-08 11:39:05

themusicgod1 wrote:
> kurono wrote:
> > May be a naive question, but what about the “Unsafe Browser”?
> > As described here: https://labs.riseup.net/code/issues/9366,
> > an attacker with control over the amnesia user could use
> > “X tools” to open it and go to “whatsmyip” kind of sites,
> > to get the real IP?
>
> Wouldn’t it make much more sense to remove the “Unsafe Browser” or whatever else than vidalia/TorMonitor, then, if we’re removing things? What is it about the “Unsafe Browser” that warrants inclusion above vidalia/TorMonitor, wrt this security tradeoff?

It’s pretty difficult to logon to captive portals (like is seen at airports, hotels, etc.) without Unsafe-Browser (= non-Torified).

IIRC, one idea floated around elsewhere is that maybe Unsafe Browser should be opt-in, such as at the greeter and unavailable otherwise.

#12 Updated by sajolida 2015-12-09 03:13:20

> IIRC, one idea floated around elsewhere is that maybe Unsafe Browser should be opt-in, such as at the greeter and unavailable otherwise.

Note that we’re going slightly off-topic here. But in the redesign of
the workflow for connecting to Tor we might get rid of the full unsafe
browser and instead embed a small clearnet browser “somewhere” in the
connection process to allow connecting through captive portals.

Regarding making the clearnet browser opt-in in the Greeter, I don’t
really like this idea as:

1. While traveling you might not now whether the local network might ask
you for a captive portal and would have to reboot.
2. If having a clearnet browser anywhere accessible by X can deanonymize
you then it’s equally bad whether you need to use a captive portal or
not. We should find a solution that is acceptable if you need a captive
portal as well :)

#13 Updated by intrigeri 2016-01-03 20:33:35

At the January meeting, thanks to kurono’s excellent point above, we concluded that it would not make sense to lock things down wrt. Vidalia (and similar tools), when there’s an equally bad around any way, via the Unsafe Browser that enables the same attack vectors.

Some arguments were also raised in favour of Vidalia-like tools, for usability/functionality reasons (I’ll let someone else sum them up).

#14 Updated by intrigeri 2016-01-03 20:52:35

  • blocks deleted (Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed)

#15 Updated by intrigeri 2016-01-03 20:52:43

  • related to Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed added

#16 Updated by intrigeri 2016-01-03 20:55:16

  • Status changed from Confirmed to Resolved
  • Assignee deleted (anonym)

#17 Updated by intrigeri 2016-02-21 11:06:22

  • Status changed from Resolved to In Progress
  • Target version changed from Tails_2.0 to Tails_2.3
  • % Done changed from 0 to 50

It seems to me that our conclusion was maybe bogus.

Actually, getting “the real IP” is one thing, but it doesn’t really matter in itself: to deanonymize a given TCP connection over Tor, the attacker needs to also learn the Tor circuit it uses, and correlate this information with “the real IP”. Can we do that just by using X weaknesses to leverage the Unsafe Browser?

#18 Updated by intrigeri 2016-02-21 11:06:41

#19 Updated by intrigeri 2016-02-21 11:06:50

#20 Updated by intrigeri 2016-02-21 11:20:36

> the attacker needs to also learn the Tor circuit it uses, and correlate this information with “the real IP”. Can we do that just by using X weaknesses to leverage the Unsafe Browser?

Probably not, but assuming arbitrary code execution as the amnesia user, the attacker can use X tools e.g. to ask the GUI application they want to deanonymize what destination it is connected to. They don’t know what Tor circuit is being used, but still this can be enough e.g. to deanonymize online actions that have public side effects. I don’t know if this can be generalized to a point that can justify our previous conclusion.

#21 Updated by intrigeri 2016-02-21 12:04:16

  • Target version deleted (Tails_2.3)

Actually, given Bug #9365 suggests other ways to conduct similar attacks (at least discovering Entry Guards is trivial), so currently we have at least two weakest links, and breaking any of those is enough for an attacker. So, it would be futile to harden only one of these two weakest links, which we could do e.g. by entirely removing Vidalia-like tools. The weakest link this very ticket is about (Vidalia-like tools) can quite easily be hardened, e.g. by protecting them behind the administration password, while the other weakest links are probably harder to fix (see Bug #9365 for details) => let’s focus on the other weakest links (Bug #9365) for now.

#22 Updated by intrigeri 2016-02-21 12:04:25

  • related to deleted (Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed)

#23 Updated by intrigeri 2016-02-21 12:04:36

  • blocked by Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed added

#24 Updated by sajolida 2016-07-21 09:37:34

  • Affected tool changed from Vidalia to Onion Circuits

Now we have Onion Circuits instead of Vidalia.

#25 Updated by intrigeri 2017-09-18 08:16:41

#26 Updated by intrigeri 2017-09-18 08:18:30

  • blocks deleted (Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed)

#27 Updated by intrigeri 2017-09-18 08:18:46

  • related to Bug #9365: Evaluate consequences of full Tor circuit/stream state and restrict it as needed added

#28 Updated by intrigeri 2017-09-18 08:19:24

  • Status changed from In Progress to Rejected

We’ve added Feature #12213 to our roadmap so I don’t think it’s worth investing any time here.