Project

General

Profile

Bug #10339

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

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

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

50%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:
Onion Circuits

Description

In #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!


Related issues

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

History

#1 Updated by anonym about 4 years ago

  • Target version set to Tails_1.8

I'm optimistically "scheduling" this discussion so it happens this year.

#2 Updated by anonym about 4 years ago

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

#3 Updated by themusicgod1 about 4 years ago

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 about 4 years ago

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

It seems to me that #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 about 4 years ago

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

#6 Updated by sajolida about 4 years ago

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

#7 Updated by sajolida about 4 years ago

#8 Updated by kurono almost 4 years ago

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

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

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

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

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

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

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

#15 Updated by intrigeri almost 4 years ago

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

#16 Updated by intrigeri almost 4 years ago

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

#17 Updated by intrigeri over 3 years ago

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

#19 Updated by intrigeri over 3 years ago

#20 Updated by intrigeri over 3 years ago

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

  • Target version deleted (Tails_2.3)

Actually, given #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 #9365 for details) => let's focus on the other weakest links (#9365) for now.

#22 Updated by intrigeri over 3 years ago

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

#23 Updated by intrigeri over 3 years ago

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

#24 Updated by sajolida over 3 years ago

  • Affected tool changed from Vidalia to Onion Circuits

Now we have Onion Circuits instead of Vidalia.

#25 Updated by intrigeri about 2 years ago

#26 Updated by intrigeri about 2 years ago

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

#27 Updated by intrigeri about 2 years ago

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

#28 Updated by intrigeri about 2 years ago

  • Status changed from In Progress to Rejected

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

Also available in: Atom PDF