Evaluate consequences of full Tor circuit/stream state and restrict it as needed
Update: as discussed on #10339 (comment 66117), we need to focus on the non-Vidalia aspects first.
Note: The Tor Browser runs with a quite different set up than Tails, since the same user also runs the Tor process. For them, a browser compromise will always be worse than in Tails for that reason.
With “full Tor circuit/stream state” we mean having access to the following things via Tor control port:
I.e. what’s required by Torbutton for its per-tab circuit view.
First of all, a compromised application will know the end points it communicates with, so the state of its traffic’s Tor circuits isn’t very interesting to an attacker (and does this extend to all processes run by the same user?). Hence the main issue with access to the above commands is that a compromised application will learn everything done with Tor, including processes run under another user.
Also, for contrast, let’s quickly examine what can currently be done to learn stuff about Tor circuits without using the control port:
netstatwill expose the list of guards (or bridges).
whatismyip.com(or similar) can be used for learning the exits of current circuits with some probability, but only when Tor reuses circuits. However, it cannot be done with Tor Browser’s domain isolation, or any
IsolateDestAddr, so this approach is useless in Tails.
- Leveraging Vidalia via X “features” to learn something close to “full Tor circuit/stream state”? (#9366 (closed))