Option to limit information Tor's control port discloses
Currently getinfo address spills the external IP address, which could jeopardize the user's anonymity in certain use cases.
Please add add an option to torrc (ControlLockdown or so) to leave such requests unanswered if activated.
Use cases:
- One goal of a Transparent Proxy (Isolating Middlebox) or an Isolating Proxy is to strengthen proxy obedience. In essence the idea of is, that the operating system is not aware of it's own external IP address and can therefore not spill it, because Tor is running on a separate machine. At the moment such setups have the disadvantage, that they must forbid access to Tor's control port - because the control port could spill the IP. Users can therefore not use the "New identity" feature of TorButton and will in future be unable to use other improvements such as #3059 (moved) ("Adapt browser time based on tor's notion of clock skew...").
- Building a Bridge Firewall is impossible because of lack of this lock down feature.
There may be other features similar to "getinfo address" in the Tor control protocol, which could be potentially harmful. I haven't looked yet. If this feature get's accepted (as in "we could imagine to add such an option"), we (and I of course as well) could look for other things in the control protocol, which are potentially harmful for anonymity.
Activity
changed milestone to %Tor: unspecified
The appropriate question should be, does clients (TBB, TorBirdy, etc.) have the same functionality and control over the tor process as relays. Can tor control be hardened for client users?
For example, if "getinfo address" isn't necessary for Tor Browser, TorBirdy, etc, ship hardened client binaries by default. Sorry if I'm wrong.
Same question another way, let's say I set up my operating system as to only let Tor Browser connect to internet, and NSA used an exploit on my browser like the one on Freedom Hosting, they couldn't directly phone-home but thanks to "getinfo address" (if this ticket is valid) they could get my ip and upload it over tor.
But if that was not possible, they would need to use harder techniques to trace my IP.
And this is the workaround at Whonix: https://www.whonix.org/wiki/Dev/Control_Port_Filter_Proxy And Tails: https://labs.riseup.net/code/issues/6384
We talked more about this ticket on #tor today.
An adversary who can talk to the control port can learn who the user is, via not just getinfo address, but also setconf'ing a proxy or alternate directory authorities or bridges or the like, or by listening to events (including log events) that say details. And if setconf is dangerous, don't skip over loadconf. In short, I don't think a "blacklist these dangerous controller commands" approach will work -- there are too many of them.
We could imagine whitelisting a small set, like the ones that Whonix and Tails both use.
But that whitelist won't be something that Tor Browser would want to apply, since Tor Launcher does want to be able to setconf proxies or bridges, and listen for events.
Developers who use the control port would of course like a fully expressive language to describe exactly which features in the control protocol should be handled in what ways. But I think it would be unwise to build such a thing into Tor, because it would be a lot of code, which would be a lot of room for bugs, and approximately none of the code would be used by most users, so many bugs would lurk for a long time.
And since the various users here will want to be able to configure which commands are allowed or disallowed (I hear some Whonix users will want to be able to configure hidden services, whereas others will want their Tor to prevent them from configuring hidden services), it seems to me that the current "run a script that is the gatekeeper for what commands can actually get passed through to the Control interface, and then users can configure the script as needed to allow whatever features they're enabling" approach is not horrible.
The push-back against that approach is that the current script is written in bash, and maybe there are sneaky ways to trick it into passing along commands you wanted to block. Which, while true, doesn't really convince me that putting that stuff, in a sufficiently configurable way, inside Tor will make things any better.
At the same time, I still don't have a good handle on the threat model that we're considering here. The Tor process knows sensitive information, after all, so you need to somehow prevent the adversary, who in this scenario has broken into some of the computer but not all of it, from interacting with the Tor process, but you do want to allow the user to change things, including what interactions are allowed with the Tor process? 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 -- 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'? I guess the broader answer is that I'm not yet convinced that this ticket, "option to limit information Tor's control port discloses", is addressing the right underlying issue.
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
Fleshed out details about the situation:
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
Trac:
Username: pragmatist-
Replying to pragmatist:
In light of the discussion and issues above, My proposal on this is to have Torbutton configurable as to disable certain checks. What do you think?
Sounds great to me!
Maybe these checks are already in place by now?
If not, do they have tickets?
This is partially solved by the various filtering proxies that different people have written to sit on top of the control port. I think a full solution would involve a really careful control-port design analysis. See the thread starting at https://lists.torproject.org/pipermail/tor-dev/2017-April/012141.html for some good discussion.
I'm closing this one as "wontfix", but that doesn't mean the effort is doomed, or that there's no further work to do -- just that it's much bigger than a matter of "limiting getinfo replies".
Trac:
Status: new to closed
Keywords: tor-client deleted, tor-client tor-control added
Resolution: N/A to fixedmentioned in issue #11376 (moved)
mentioned in issue #18156 (moved)
moved to tpo/core/tor#8369 (closed)
