[tor-dev] Control-port filtering: can it have a reasonable threat model?
meejah at meejah.ca
Mon Apr 3 20:44:53 UTC 2017
Nick Mathewson <nickm at torproject.org> writes:
> But I could be wrong! Maybe there are subsets that are safer than
So, I guess the "main" use-case for this stuff would be the current
users of control-port filters (like Subgraph and Whonix; others?).
It seems what these things *really* want is a "limited view" of the One
True Tor. So for example, you don't want to filter on the "command" or
"event" level, but a complete coherent "version" of the Tor state.
As in: see "your" STREAM events, or "your" HS_DESC events etc. Probably
the same for BW or similar events. This is really kind of the
"capability system" you don't want, though ;)
Also, I really don't know exactly what the threat-model is, but it does
seem like a good idea to limit what information a random application has
access to. Ideally, it would know precisely the things it *needs* to
know to do its job (or at least has been given explicit permission by a
user to know). That is a user might click "yes, OnionShare may add onion
services to my Tor" but in reality you have to enable: ADD_ONION, (some)
HS_DESC events, DEL_ONION (but only ones you added), etc. If you really
wanted an "on-disk" one (i.e. via HiddenServiceDir not ADD_ONION), then
you have to allow (at least some) access to SETCONF etc.
Or, maybe you're happy to let that cool visualizer-thing have access to
"read only" events like STREAM, CIRC, BW, etc if you know it's sandboxed
to have zero network access.
> 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.
Doesn't this just show "onions that the current control connection has
> * 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?
HS_DESC events include the onion (in args) so could in principle be
filtered by a control-filter to only include events for certain onions
(i.e. those added by "this" control connection). In practice, this is
probably exactly what the application wants anyway.
> E. Your thoughts here....?
Maybe this is a chance to play with a completely different, but ideally
much better "control protocol for Tor"? The general idea would be that
you have some "trusted" software (i.e. like existing control-port
filters) that on the one side connects to the existing control-port of
Tor (and is thus "completely trusted") but then exposes "the Next Great
Control Protocol" to clients.
Nevertheless, there's still the question of what information to expose
(and how) -- i.e. the threat model, and use-cases.
Of course, the same idea as above could be used except it speaks "Tor
Control Protocol" out both sides -- that is, 'just' a slightly fancier
Aww, that's what I want ;)
More information about the tor-dev