[tor-dev] Restricting SOCKS access now and later (was Re: Proposal 351: Making SOCKS5 authentication extensions extensible)

[Roger Dingledine]

On Wed, Sep 11, 2024 at 09:12:26AM -0400, Nick Mathewson wrote:
> > It would be useful to have a way of controlling access to the SOCKS port
> > so that untrusted applications running on the same device as a Tor
> > client can't use the Tor client's SOCKS proxy. This is something that
> > people auditing Briar have raised as a security concern.

For those wondering about how to control access to the SocksPort for
applications on *different* addresses, there is the SocksPolicy torrc
option -- basically it lets you tell Tor to hang up on connections from
some hosts but not others.

So maybe you could use it here if you set up different internal addresses
for the different applications (and also take care that routing actually
communicates the right addresses even over localhost, e.g. I find on my
Linux that connections come "from" 127.0.0.1 even when that's not the
address of the piece of my computer that initiated the connection). Not
a great solution but one to add to the list of possibilities.

> I guess that we might worry about side-channel attacks, where a
> hostile application is sending traffic through the Tor proxy in order
> to introduce a timing signal into your traffic?  But any application
> with network access could do that, whether it has Tor access or not.

Right, I thought about this too and went through the same logic. I
agree. I also don't have any good real examples of attacks that somebody
could do if they could access your socksport, so long as you are using
circuit isolation properly -- and it would be great to hear some if they
do exist.

But that said, Michael, you said you *aren't* using circuit isolation
yet? For that case here's my attack: as a neighboring application, I make
a connection through that socksport, also not using circuit isolation,
and I take note of what exit relay my stream pops out of, because it's
probably the same exit relay that the other application is using.

I'm not sure how to adapt that attack to the onion service context though.

> [^1]: Actually, wait.  There's a possible problem here when you're
> making lots of onion service connections, since IIRC in C Tor onion
> service circuits aren't affected by isolation.  But in Arti, they are.
> So at least that problem will go away as Arti moves to the fore.

Clarification here: I believe C-Tor does circuit isolation correctly
for the onion service circuits themselves (including the introduction
circuit), but it does not do isolation for other pieces of the rendezvous
process, such as onion descriptor downloads or storage.

So if you visited a cloudflare onion service using two different domains
in Tor Browser, you would end up with separate circuits to the service,
one per domain, but you would reuse the cached onion descriptor rather
than fetching a new one. And there are other edge cases that can leak
info, like the intro point failure cache: you would skip trying an intro
point when connecting to the second one if you had recently failed to
reach that intro point while connecting to the first one.

In part this tradeoff was about the complexity of making the changes,
but in part we also justified it because the whole rendezvous process is
heavyweight enough as it is, and we needed to draw the line somewhere
(e.g. we don't fetch new directory documents for each new isolated
circuit).

I do think doing more pieces of the isolation in Arti makes sense. And
for completeness, in irc discussion Nick reminds us that there is some
other state we still share between isolated circuits (in both C-Tor and
Arti), for example guards including vanguards.

Hope this helps,
--Roger