The essence of what happened
In May 2020, a group of exit nodes was discovered interfering with outgoing connections. In particular, they left almost all connections intact, but intercepted connections to a small number of cryptocurrency exchanges. If users visited the HTTP version of the site (i.e. unencrypted and unauthenticated), malicious hosts prevented redirection to the HTTPS version (i.e. encrypted and authenticated). If the user did not notice the substitution (for example, the absence of a padlock icon in the browser) and started sending important information, this information could be intercepted by the attacker.
The Tor project excluded these nodes from the network in May 2020. In July 2020, another group of relays was discovered that carried out a similar attack, after which they were also excluded. It is still not clear if any users were successfully attacked, but based on the scale of the attack and the fact that the attacker tried again (the first case affected 23% of the total throughput of exit nodes, the second about 19%), it is reasonable to assume that that the attacker considered the cost of the attack justified.
This incident is a good reminder that HTTP requests are unencrypted and unauthenticated and therefore still vulnerable. Tor Browser has an HTTPS-Everywhere extension specifically designed to prevent such attacks, but its effectiveness is limited to a list that does not cover every website in the world. Users visiting HTTP versions of sites will always be at risk.
Prevent similar attacks in the future
The ways to prevent attacks are divided into two parts: the first includes measures that users and site administrators can take to increase their security, while the second concerns the identification and timely detection of malicious network nodes.
Recommended actions by sites:
1. Enable HTTPS (free certificates are provided by Let's Encrypt)
2. Adding redirect rules to the HTTPS-Everywhere list so that users can proactively establish a secure connection rather than relying on a redirect after an insecure connection is established. In addition, if the web services administration wishes to completely avoid interaction with exit nodes, it may provide an onion version of the site.
The Tor Project is currently considering disabling insecure HTTP entirely in the Tor Browser. A few years ago, such a measure was unthinkable (too many resources hosted only insecure HTTP), but HTTPS-Everywhere and the upcoming version of Firefox have an experimental ability to use HTTPS by default for the first connection, with the ability to fall back to HTTP if necessary. It is still unclear how this approach will affect Tor Browser users, so it will be tested first at higher browser security levels (shield icon).
On the side of the Tor network, there are volunteers who monitor the behavior of relays and report on incidents, so that malicious nodes can be excluded by root directory servers. Although such reports are usually dealt with quickly and malicious hosts are shut down as soon as they are discovered, there are not enough resources to continuously monitor the network. If you managed to detect a malicious relay, you can report it to the project, instructions available at this link.
The current approach has two fundamental problems:
1. When considering an unknown repeater, it is difficult to prove its harmfulness. If there were no attacks from his side, should he be left in place? Bulk attacks that affect many users are easier to detect, but if attacks affect only a small number of sites and users, the attacker can act preemptively. The Tor network itself consists of thousands of relays located around the world, and this diversity (and the resulting decentralization) is one of its strengths.
2. When considering a group of unknown relays, it is difficult to prove their interconnectedness (that is, whether they conduct sibyl attack). Many voluntary relay operators choose the same cheap networks to host such as Hetzner, OVH, Online, Frantech, Leaseweb, etc., and if several new relay operators are discovered, it will not be easy to definitively assume whether there are several new operators or only one, managing all new repeaters.
Source: linux.org.ru