Relayer security issue - unmasking users, connecting deposits + withdrawals

With the relayer registry proposal well on its way towards being voted on (and probably accepted), I’ve been thinking a bit about how relayers impact security of TC users.

One of the big vulnerability vectors that users face due to how relayers currently work has to do with the fact that the UI connects to relayer servers directly, for obtaining parameters from the relayers, for submitting relay transactions to them, and checking the status of their withdrawal job.

Because users are connecting directly to relayers, any information that is available over that HTTP request can be logged and analyzed by anyone who has access to (or compromises) the relayers. This includes headers sent in the request, which might be highly specific to the user’s browser, and the network connection properties (IP address, IP route, reverse DNS, services on the user’s public IP, etc).

Something very important to note is that the UI doesn’t only connect users to the one relayer that their withdrawal goes through. It connects users to every relayer that’s registered, in order to obtain the /status information for each relayer. This is done the moment that you click the “Withdraw” tab in the app.

The Problem

The implication of this is that the moment that any user clicks the “Withdraw” tab, they disclose a bunch of potentially-identifying information to the entire set of relayers.

What this also means is that every relayer can tell, with some degree of certainty, which withdrawal corresponds to which UI session that connected to them. Because the UI doesn’t continuously poll the relayers for information, but instead only does so when the Withdraw tab is loaded (every time it’s clicked), there is a strong correlation between when a relayer sees a status check from a user, and any withdrawal transactions submitted to the network shortly thereafter.

Additionally, if any user clicks the Withdraw tab either before, or shortly after they make a deposit (exploring the app, checking what happens if they put their note string in), their deposit transaction is similarly able to be correlated to their status check request.

What exacerbates this is that not every user is connecting to Tornado.cash through a VPN or Tor. I would suspect that a minority are - and anyone who runs a relay could probably tell you what the prevalence is. :slight_smile:

If a user makes the deposit and withdrawal transactions from the same IP address (or other header information), then the privacy guarantees of TC are lost.

Lastly, if a user is first opening the app with a non-proxied connection, and then enables their proxy, this vulnerability would affect them as well, since the issue is correlating status connections with deposit/withdrawal transactions in time.

The Solution

The likely best mitigation for this problem would be for relayers to serve their status information over IPFS, instead of directly to users. Each relayer would have an IPNS address associated with it, and could pin their status and job information under that address. The UI would then poll that in the same way that it loads the app resources.

This wouldn’t solve the issue of users connecting directly to relayers to submit transactions, but at least it would limit the connection to the relayer that the user has selected.

If we wanted to go further than that, we would probably want to find a way to enable the UI to submit messages to relayers via IPFS pubsub. However, that becomes something of a “Now you have two problems” situation, since public IPFS gateways are usually read-only, so we’d need to maintain a node that can serve user messages back to relayers.

1 Like

Tornado Cash protocol solves only on-chain privacy. Users still have to take care of network privacy by themselves. TornadoCash team talked about from the beginning How to stay anonymous with Tornado.cash and similar solutions | by Tornado Cash | Medium

Most of this info is also available to users ISP, Infura, TheGraph, and every router in the middle. To mitigate this users have to take care of their IP address and browser fingreprint, for example by using a TOR browser. We can’t solve this just by removing relayer connections, way too many other parties have access to this data. This is why we’ve placed IP address on the front page in the first place - to make it clear for the user that his IP is basically a public info and might be tracked by anyone.

A better way would be to develop a privacy focused wallet that handles network level privacy, like connecting to RPC, Relayers, and other services through TOR, rotating exit nodes, tracking links between users public addresses and other stuff. We’d like to do that, but first want to focus on improving the core protocol, we don’t have enough capacity to do both in parallel.

2 Likes

The ISP, and hops along the user’s network route, have access only to the unencrypted parts of the TCP stream. From their perspective, all that should be visible is that the user is connecting to an IPFS gateway. The connections to relayers are what identifies a user to their ISP as using Tornado.cash, since most other connections could be any dApp.

Infura and TheGraph have this information, yes, and that seriously harms the security of Tornado.cash. Where possible, we should try to obscure the relationship between a user’s UI session and their deposits and withdrawals (e.g. by not making clearly-correlated requests to them right before or after deposits or withdrawals).

We shouldn’t hand-wave away the fact that we’re currently maximizing the number of parties with knowledge of users’ identities. Infura and TheGraph aren’t necessarily trustworthy, but I’m far more inclined to trust them than the random assortment of relayer operators that might specifically be interested in tracking and identifying Tornado.cash users.

This is being removed, isn’t it? That was another point of insecurity that I thought was being fixed - that every user was potentially being logged by ip.tornado.cash.

There is no call to action on the UI that I can see, which says “Hey, we’re making connections to an assortment of untrusted servers, and this is likely to identify you to the world. You shouldn’t use this app unless you’re using Tor. But you’ll have to figure that one out yourself, since it doesn’t work out of the box.”

Solutions that rely upon users ditching their preferred wallet in favour of something that TC builds are not good solutions.

Instead, we should identify ways to eliminate identifying network connections and other forms of PII leakage from the app. Security bugfixes.

The core protocol includes the UI. It’s not just the assets on-chain that we should be concerned with the security of.

There would be more capacity to make such improvements if more people were involved in development. The fact that nobody has access to the UI is a real problem that should harm users’ trust in the project.

1 Like

Seriously? Some people like to trust the banks cause they are honest. So you draw your decisions based on who you like to trust?

why don’t you build your own Proof of concept UI and provide a guideline how it should be?
https://github.com/tornadocash/tornado-cli - is good way to start a new UI

Lots of talk, less action. Let your code speak for itself.

2 Likes

Yes? Insofar as trust is required, I factor risk based on how trustworthy people are. Infura has a lot more to lose if they’re found shipping logs off to governments and law enforcement than Tornado.cash relayers do. They might still be doing it anyways, and we should assume that they are, but the more pressing issue is relayers, in this instance.

I try not to waste my time, and in this case I’m avoiding doing so by trying to contribute to the UI that will be used. If I build a UI for TC on my own, without any buy-in from the project, then there’s little to no chance that it’ll be used by anyone.

My time is better spent contributing to a codebase that will be deployed.

Let’s let Tornado.cash’s code speak for itself, by making it available for all to see and fix. This way, anyone can judge whether or not it’s secure.

Blockquote
Yes? Insofar as trust is required, I factor risk based on how trustworthy people are. Infura has a lot more to lose if they’re found shipping logs off to governments and law enforcement than Tornado.cash relayers do. They might still be doing it anyways, and we should assume that they are, but the more pressing issue is relayers, in this instance.

pretty vague and invalid assumptions. Once again, TC is not aimed to solve offchain privacy. Hence, it’s upon a user to take care of it.
Your solution is flaky and won’t solve a problem.

Blockquote
I try not to waste my time, and in this case I’m avoiding doing so by trying to contribute to the UI that will be used. If I build a UI for TC on my own, without any buy-in from the project, then there’s little to no chance that it’ll be used by anyone.

PoC is needed to understand you better. PoC is not finished product and much easier to write than to contribute to larger code base.

Blockquote
Let’s let Tornado.cash’s code speak for itself, by making it available for all to see and fix. This way, anyone can judge whether or not it’s secure.

No one is forced to use the UI, there is cli tool. Also, there is minified version that it is easily analyzable for security issues by 3rd party tools. https://github.com/tornadocash/ui-minified

1 Like

TC should aim to provide secure solutions, including providing a secure UI. The UI shouldn’t be knowingly insecure, as it seems we’re agreeing that it is.

Are you able to back that up with any coherent argument? You seem to be simply dismissing concerns, versus acknowledging them or disputing them coherently.

Do you need to understand me in particular better? Is this an interview? :slight_smile:

The CLI tool implements a subset of the protocol, and provides a very lacking user experience. Also, we’re not talking about what people are forced to use. We’re talking about what people do use, which is the UI. The UI having major security issues should be concerning to users, and to the project’s governance.

You and I have seriously different definitions of “easily analyzable”. The point of obfuscated minification is to make it very difficult to understand what’s going on. I’ve sifted through the minified sources to understand things like how note backups work. It is a tedious process that barely illuminates anything.

I have to agree with @FrozenFire on this one. How am I supposed to use tornado if I have to go through two potentially dangerous channels: MetaMask, whose company owns Infura, and Tornado’s relays, which use Infura or Alchemy and others.

A VPN or Tor is okay but does not solve the whole problem. Metadata is also important. The smart contracts are good, but people do not interact directly with them. They go through tornado’s web interface. So the privacy problem is not solved entirely.

I would support more work being done on the CLI tool. Maybe separating the transaction generation process like calls, etc + actually sending the transaction would be an interesting idea. Users could run their own light node and form the transaction, sign offline, then broadcast it to the network on a public transaction broadcast service, over Tor. Of course UX would take a hit but give people the option because the anonymity is vastly improved, far more than the present state.

Edit: I see that my suggestion has already been implemented (separate sign from submit). Thank you for pulling in the recent work on the CLI tool @rstormsf

agree or disagree. what do you want from a project with 0 funding? so many expectations. apply yourself to be useful please.

Would it help if I found funding? I can absolutely do that. You tell me what needs funding, I’ll get it for you.

3 Likes

I think it would. feel free to express your ideas on what could be possible

1 Like

I’m on the Ethereum Foundation’s Privacy and Scalability Explorations team, which is part of the Ecosystem Support Program. My interest is in improving privacy and security, especially for projects like Tornado.cash, which is one of the first projects to make ZKPs useful for many people.

I think that I could absolutely find grant funding for anything that improves transparency and decentralization from Tornado.cash, or which improves privacy and security guarantees for its users.

I’m also a very capable developer, myself. I was a Principal Engineer in my last role, overseeing platform and network architecture, security, and software engineering best practices for a major US telecom. I can do much of the work myself on the improvements that I’m suggesting - I just need access to do so, and buy-in that my contributions are likely to be used.

6 Likes