Feature #9298
How much do we want Tor Browser's per-tab circuit view?
0%
Description
As mentioned in Feature #9031#note-12 it doesn’t come for free:
1. We will have to completely rewrite our tor-controlport-filter; the filter must handle concurrent connections (i.e. multiple clients), and it must deal with asynchronous control port commands, like setevents, without blocking (e.g. after a setevents you can issue other commands over the same connection and get their responses). Writing such a filter using stem seems like the way to go. (Note that Whonix fork of tor-controlport-filter only supports concurrency, not asynchronous connections.)
2. Worse, this will expose stream/circuit-level Tor state to the browser, and the user running the browser (i.e. the amnesia user) which is worse than we have it now.
1 is “just” a dev time issue, but 2 is pretty bad. Of course, with Vidalia (soon Tor Monitor) we have something kinda similar but it will run as under a dedicated user, so the control port exposing that will not be directly available to the amnesia user, which reduces exploitability.
Subtasks
Related issues
|
Related to Tails - |
Resolved | 2015-05-13 |
History
#1 Updated by intrigeri 2015-04-30 00:53:02
- Assignee set to anonym
- Target version set to Tails_1.4.1
Assigning to anonym the task of leading this discussion to a conclusion, as IMO it’s part of upgrading to Tor Browser 4.5.
#2 Updated by anonym 2015-04-30 07:38:09
I’ve proposed to discuss this on our monthly meeting in May (currently 2015-05-03): https://mailman.boum.org/pipermail/tails-dev/2015-April/008699.html
#3 Updated by intrigeri 2015-04-30 07:53:54
> I’ve proposed to discuss this on our monthly meeting in May
Please add it to the meeting agenda, then.
It would be good if someone (you?) prepared this discussion by digging the Vidalia / Tor Monitor / green onion threads for relevant info, otherwise we’ll spend too much time re-discovering and re-discussing things.
#4 Updated by intrigeri 2015-04-30 08:12:07
anonym wrote:
> this will expose stream/circuit-level Tor state to the browser, and the user running the browser (i.e. the amnesia user) which is worse than we have it now.
Indeed, it may open the system to new attacks. Which ones would that be, in practice?
#5 Updated by intrigeri 2015-05-04 04:39:19
- Status changed from Confirmed to Resolved
Monthly meeting report:
For most applications (e.g. Pidgin, but not Claws Mail), Vidalia currently displays DOMAIN:PORT information for each circuit. But according to the screenshots on Feature #6842, once we replace Vidalia with Tor Monitor, we’ll only have IP:PORT information, that most users won’t be able to correlate with their web browsing activity.
But we’re not there yet. So, for the moment we’ll simply keep Tor Browser’s per-tab circuit view disabled, on the grounds that this info is already available in Vidalia.
And later, some of us will argue that when we replace Vidalia with Tor Monitor, in order to avoid a UX regression, either we ship Tor Browser’s per-tab circuit view (and go through a complicated security analysis thereof), or we have Tor Monitor display the DOMAIN:PORT information like Vidalia does.
Also note that the security analysis isn’t only about Tor Browser’s per-tab circuit view. It’s also about Tor Monitor, Vidalia, retrieving info via the X protocol, and what practical attacks one can conduct with the full circuits/streams info in hand.
#6 Updated by BitingBird 2015-05-11 15:00:14
- Target version changed from Tails_1.4.1 to Tails_1.4
Resolved before 1.4 is out -> assigning right milestone :)
#7 Updated by BitingBird 2015-05-13 04:55:02
- related to
Bug #9391: Document why we disabled the new circuit view of Tor Browser 4.5 added