[tor-bugs] #8369 [Tor]: Option to limit information Tor's control port discloses

[Tor Bug Tracker & Wiki]

#8369: Option to limit information Tor's control port discloses
-----------------------------+--------------------------
     Reporter:  proper       |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.???
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-client
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------

Comment (by pragmatist):

 >I guess if the browser is run in one VM, and the Tor configurer interface
 is run in a different VM, we could have a hope of making this work

 Yes that the way things are at the moment.

 >-- but once you've got the usability issues sorted out there, tell me
 again why the browser VM needs to be the one to click 'new identity'?

 The whole point of the filter was to allow just the features of Torbutton
 that have become solely reliant on Tor's controlport for. In Torbrowser's
 current design, if it was denied access to the controlport, it would
 report that Tor is not working which is annoying at best and at worst
 cause of a panic storm by users who don't know better. If it weren't the
 case we wouldn't have ever considered doing this as we are not interested
 in making Tor do anything fancy, - only to receive traffic from the
 untrusted workstation. When alternative approaches were suggested to TBB
 upstream to ameliorate this, they didn't find any traction, if anything,
 more features are being added in TBB to use Tor in the same way.

 After what you said yesterday, I think it would be easier (and more
 secure) to design the software that uses Tor to be suitable for a 2 vm
 design where it won't break if Tor isn't running on the same machine, than
 to go down the road of having to whitelist anything.

 I'm thinking something along the lines of this proposal:

 "Add a Torbutton pref to disable local tor check"
 https://trac.torproject.org/projects/tor/ticket/11722


 >Before Whonix 6, this also broke Tor Button's New Identity feature, which
 essentially sends "SIGNAL NEWNYM" to Tor's control port. While Tor
 Button's New Identity is still the only feature that was not available
 when using Tor Browser in Whonix, Tor Button in future will get more and
 more dependent on Tor's control port.

 >TBB by default performs its own control port verification.[1] It checks
 using Tor's control port(!), that the socks port Tor reports, is the same
 one as Tor Browser is configured to use. If it fails, and it would fail in
 Whonix 0.5.6, Tor Button would look like disabled and show a failure
 message.

 >In future, Tor Button will likely also use something like "GETINFO
 clockskew".[2] TBB developer rejected[3] the idea of not adding the
 statement "require no access to Tor's control port" to TBB's design.

 source: https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy

 [1] https://trac.torproject.org/projects/tor/ticket/6546#comment:33
 [2] https://trac.torproject.org/projects/tor/ticket/3652
 [3] https://trac.torproject.org/projects/tor/ticket/8032

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8369#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online