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 instance.

Besides that, 'makes the control port read-only' is a pretty straight forward, simple to understand capability for a torrc option to have.

Cheers! -Damian

On Mon, Apr 3, 2017 at 11:41 AM, Nick Mathewson nickm@torproject.org wrote:

Hi!

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... :

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....?

signing-off-before-this-turns-into-a-capabilities-based-system,

Nick _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev