[tor-dev] Control-port filtering: can it have a reasonable threat model?
atagar at torproject.org
Tue Apr 4 15:46:41 UTC 2017
Hi Nick. Just a quick note that something I've wanted from time to
time is a 'make the control port read-only' option so only GETINFO,
GETCONF, events, etc would work. Yes, these could be used to
deanonymize a user, but it could provide assurance the controller
doesn't tamper with tor. This has been of interest to me since nyx
(aka arm) is primarily a read-only monitor and this could provide
users with an assurance that it's not doing anything to their tor
Besides that, 'makes the control port read-only' is a pretty straight
forward, simple to understand capability for a torrc option to have.
On Mon, Apr 3, 2017 at 11:41 AM, Nick Mathewson <nickm at torproject.org> wrote:
> As you may know, the Tor control port assumes that if you can
> authenticate to it, you are completely trusted with respect to the Tor
> instance you have authenticated to. But there are a few programs and
> tools that filter access to the Tor control port, in an attempt to
> provide more restricted access.
> When I've been asked to think about including such a feature in Tor in
> the past, I've pointed out that while filtering commands is fairly
> easy, defining a safe subset of the Tor control protocol is not. The
> problem is that many subsets of the control port protocol are
> sufficient for a hostile application to deanonymize users in
> surprising ways.
> But I could be wrong! Maybe there are subsets that are safer than others.
> Let me try to illustrate. I'll be looking at a few filter sets for example.
> Filters from https://github.com/subgraph/roflcoptor/filters :
> 1. gnome-shell.json
> This filter allows "SIGNAL NEWNYM", which can potentially be used to
> deanonymize a user who is on a single site for a long time by causing
> that user to rebuild new circuits with a given timing pattern.
> 2. onioncircuits.json
> Allows "GETINFO circuit-status" and "GETINFO stream-status", which
> expose to the application a complete list of where the user is
> visiting and how they are getting there.
> 3. onionshare-gui.json
> Allows "SETEVENTS HS_DESC", which is exposes to the application every
> hidden service which the user is visiting.
> 4. ricochet.json
> Allows "SETEVENTS HS_DESC", for which see "onionshare-gui" above.
> 5. tbb.json
> Allows "SETEVENTS STREAM" and "GETINFO circuit-status", for which see
> "onioncircuits" above.
> Filters from https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/tor-controlport-filter.d
> 1. onioncircuits.yml
> See onioncircuits.json above; it allows the same GETINFO stuff.
> 2. onionshare.yml
> As above, appears to allow HS_DESC events. It allows "GETINFO
> onions/current", which can expose a list of every onion service
> locally hosted, even those not launched through onionshare.
> 3. tor-browser.yml
> As "tbb.json" above.
> 4. tor-launcher.yml
> Allows setconf of bridges, which allows the app to pick a hostile
> bridge on purpose. Similar issues with Socks*Proxy. The app can also
> use ReachableAddresses to restrict guards on the .
> Allows SAVECONF, which lets the application make the above changes
> permanent (for as long as the torrc file is persisted)
> So above, I see a few common patterns:
> * Many restrictive filters still let the application learn enough
> about the user's behavior to deanonymize them. If the threat model is
> intended to resist a hostile application, then that application can't
> be allowed to communicate with the outside world, even over Tor.
> * Many restrictive filters block SETCONF and SAVECONF. These two
> changes together should be enough to make sure that a hostile
> application can only deanonymize _current_ traffic, not future Tor
> traffic. Is that the threat model? It's coherent, at least.
> * Some applications that care about their own onion services
> inadvertantly find themselves informed about everyone else's onion
> services. I wonder if there's a way around that?
> * The NEWNYM-based side-channel above is a little scary.
> And where do we go forward from here?
> The filters above seem to have been created by granting the
> applications only the commands that they actually need, and by
> filtering all the other commands. But if we'd like filters that
> actually provide some security against hostile applications using the
> control port, we'll need to take a different tactic: we'll need to
> define the threat models that we're trying to work within, and see
> what we can safely expose under those models.
> Here are a few _possible_ models we could think about, but I'd like to
> hear from app developers and filter authors and distributors more
> about what they think:
> A. Completely trusted controller. (What we have now)
> B. Controller is untrusted, but is blocked from exfiltrating information.
> B.1. Controller can't connect to the network at all.
> B.2. Controller can't connect to the network except over tor.
> C. Controller is trusted wrt all current private information, but
> future private information must remain secure.
> D. Controller is trusted wrt a fraction of the requests that the
> clients are handling. (For example, all requests going over a single
> SOCKSPort, or all ADD_ONION requests that it makes itself.)
> E. Your thoughts here....?
> tor-dev mailing list
> tor-dev at lists.torproject.org
More information about the tor-dev