Evaluate consequences of full Tor circuit/stream state and restrict it as needed

Update: as discussed on #10339-note_21, 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:

• SETEVENTS stream
• GETINFO circuit-status
• GETINFO stream-status
  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:

• netstat will 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 SOCKSPorts with 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))

• More?

Related issues

• Related to #9366 (closed)
• Related to #9001 (closed)
• Related to #10339 (closed)

Original created by @anonym on 9365 (Redmine)