On August 9th, user “nusenu” published a very interesting article that demonstrates how, in recent months, More than 23% of the Tor network’s exit capacity has been attacking Tor users.
On August 10th, zdnet re-published and summarized the article, making a lot of noise within the Bitcoin community.
This type of attack, in fact, was mainly designed to attack Bitcoin users – more specifically, to attack users who use mixers.
Given the huge correlation between Bitcoin and Tor, the news quickly reached major social media, chat rooms and forums; but there is still a lot of confusion about it.
This article will explain if Wasabi Wallet is affected by the issue and how the technology behind Wasabi guarantees security for its users.
- Bitcoin replacement attacks are not possible due to the architecture of Wasabi.
- Even if they’d be Wasabi stays inside Tor, except in fallbacks.
- Even if fallbacks, Wasabi enforces HTTPS traffic, so exit nodes still cannot read or replace the traffic.
Summary of the attack
The entire operation is an MITM (man-in-the-middle) attack to Tor users. This attack tries to manipulate traffic as it flows through (malicious hacker controlled) Tor exit relays. The attackers selectively remove HTTP-to-HTTPS redirects to gain full access to plain unencrypted HTTP traffic without causing TLS certificate warnings.
Specifically, hackers attacked multiple bitcoin mixers. They replaced bitcoin addresses in HTTP traffic to redirect transactions to their addresses instead of the user provided bitcoin ones. By replacing the destination address at the HTTP traffic level, the attackers hijacked the user’s funds without the users’ or the Bitcoin mixer’s knowledge.
Why Wasabi is safe and how it defends itself against this type of attack
It’s simple: because Wasabi Wallet is a non-custodial privacy-focused Bitcoin wallet that implements trustless CoinJoin, there are no addresses sent to a server when sending money.
Also, unlike many other “traditional” mixers where users must give control of their coins to another party and trust that this party will return the bitcoin to them, Wasabi Wallet does not take custody of assets.
When sending money, there is no network traffic saying something like
send 1 BTC to bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq, so there is no amount or address that can be intercepted and replaced.
In Wasabi Wallet, the user broadcasts Signed transactions. In fact, the wallet broadcasts it to the P2P network using random nodes on the Tor onion network.
- The input coins that you want to register, together with the input proof signature.
- The cleartext change address.
- The cryptographically blinded anonset CoinJoin output.
And subsequently, during the output registration phase, this is the data that is exchanged:
- The cleartext address for the anonset CoinJoin output.
- The coordinator signature over that output.
- The round hash of all the inputs.
But even if an attacker were to carry out an MITM attack by breaking the cryptography that certifies the coordinator signed outputs and replacing an address, the client would not sign the transaction, so no one would be able to hijack the funds.
On the network side, by default and under normal conditions, Wasabi Wallet never leaves Tor onion network and it never uses Tor exit relays.
All Wasabi Wallet’s traffic stays inside the onion network, and most Tor attacks are not possible if exit nodes are not involved.
In Wasabi, exit nodes are only involved in fallback scenarios.
Fallback scenario? What are you talking about?
Let’s give an example: if the Tor onion service of the backend becomes unavailable for the user, the wallet falls back to communicating with the backend’s clearnet endpoint, still over Tor. This allows the user to continue to operate, even in unusual/offline onion backend conditions.
Regarding the website itself, connections are SSL-enforced and HSTS enabled.
Yes, I know, all these acronyms can seem difficult to understand. But just keep reading, and you will see that we will simplify them in the best possible way:
HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should automatically interact with it using only HTTPS connections, which provide Transport Layer Security (TLS/SSL), unlike the insecure HTTP used alone.
Don’t Trust, Verify!
As we mentioned earlier, Wasabi’s fallback servers (Mainnet and Testnet) make use of encrypted connections and enable HTTP Strict Transport Security.
Let’s start Wasabi Wallet, open the config file from the wallet GUI, go to
The first lines should look like this:
TestNetFallbackBackendUri are, respectively, the two clearnet backends for Mainnet and Testnet to which Wasabi Wallet connects in case the two .onion backends are inaccessible.
As you can see, both of them are using secure HTTPS connections.
What about HSTS? For this, we can rely on one of the many tools online that allow you to test if a specific domain/ip has HSTS enabled.
Both of them have HSTS enabled, check for yourself:
Your security, like your privacy, is our top priority
Wasabi Wallet is safe in both, Tor onion network and clearnet.
In addition to this, exit nodes are only involved in fallback scenarios. This type of scenario is extremely rare; and should it happen, we have still adopted all the best practices to ensure the safety of your funds.
Additionally, in a custodial mixer, a passive network attack is really dangerous because the attacker can deanonymize all the users and see all their activity. With Wasabi Wallet, this is not possible because even the Wasabi coordinator cannot deanonymize its users.
Learn more about how Tor works within Wasabi
Using Tor within Wasabi has several facets:
- Wasabi frequently utilizes multiple Tor streams where applicable and registration of CoinJoin inputs and outputs is done through different Tor streams to avoid linking.
- The backend server serves block filters to all the clients over Tor. From those filters, the clients figure out which blocks they are interested in and downloads them [and some false positive blocks] from random peers. One block per peer, and always over a fresh Tor stream.
- Wasabi connects to each peer through a different Tor stream. A new random Bitcoin peer is used for every transaction broadcast.
- Wasabi broadcasts transactions to only one peer over Tor, and immediately after that, the peer is disconnected.
- Every fee query happens over Tor with a new Tor identity.