[tor-dev] Control-port filtering: can it have a reasonable threat model?
meejah at meejah.ca
Mon Apr 10 15:35:24 UTC 2017
anonym <anonym at riseup.net> writes:
>> It allows "GETINFO onions/current", which can expose a list of every
>> onion service locally hosted, even those not launched through
> I think this can be disallowed; in fact, when looking at the
> onionshare and stem sources I don't see why this would ever be used by
I may have said this already, but I think the original comment is wrong:
this only lists ephemeral onions created by the current control
connection so I don't believe there's any information leak here anyway.
> BTW, I guess a `restrict-onion-view` would also make sense for HS_DESC
> events [..]
Yes, I think this would be good. To determine if a control-connection
owns an onion or not, I think you could either use "GETINFO
onions/current" (to ask Tor) or just remember the answers from any
ADD_ONION on "this" connection (and then match against the args in the
If the filter is re-started, all the control connections will be lost
at which point any non-"detached" onions will vanish anyway.
> Imagine that ControlPort can take a "RestrictedView" flag. When set,
> controllers will get a view of Tor's state (streams, circuits, onions
> etc) restricted to what "belongs" to them, e.g. it only sees streams
> for connections itself made via the SocksPort. Tor would then have to
> internally track who these things belong to, which could be done by
> PID, which is pretty weak, but I bet there are more convincing ways.
Obviously as per my other post I agree with fragmented / limited views
given to "real" applications of the control-port. However, personally I
don't see the point of implementing this in 'tor' itself -- existing
control-port filters are "fairly" limited code, typically in "safer than
C" languages anyway. So then you have the situation where there's a
single trusted application (the filter) conencted to the Tor
Ultimately, it would probably be best if there was "a" robust
control-port filter that shipped as part of a Tor release. So if that
means "must implement it in C inside Tor" I guess so be it.
Maybe this would be a good target for "experiment with Rust" if anyone's
excited about writing control-port code in Rust...?
More information about the tor-dev