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