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

[Michael Rogers]

On 12/09/2024 22:30, Roger Dingledine wrote:
> 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.

Thanks, I'll look into this, although I suspect our options on Android 
will be limited. We may be able to bind to some other address in 
127.x.x.x and restrict SOCKS connections to coming from that address, 
but I don't know if we'll be able to prevent other apps from binding to 
that address too.

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

This is really useful to know, thanks.

I think this tells me that (a) we should start using circuit isolation 
with C-Tor to protect our non-onion-service connections (RSS feed 
fetches), and (b) even with circuit isolation, information can leak to 
an attacker who has access to the SOCKS port (specifically, information 
about which onion service descriptors have been cached, which in Briar's 
case is information about the user's list of contacts). So we do need to 
restrict access to the SOCKS port with C-Tor, and if the HS cache/intro 
point state/etc isn't isolated per session in Arti then we'll need to do 
the same there.

> 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

It does, thanks.

Cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x11044FD19FC527CC.asc
Type: application/pgp-keys
Size: 13413 bytes
Desc: OpenPGP public key
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240916/747ca8cb/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20240916/747ca8cb/attachment.sig>