Tor security advisory: exit relays running sslstrip in May and June 2020

Tor security advisory: exit relays running sslstrip in May and June 2020

Tor security advisory: exit relays running sslstrip in May and June 2020 Tor security advisory: exit relays running sslstrip in May and June 2020 png base64 iVBORw0KGgoAAAANSUhEUgAAAAEAAAABAQMAAAAl21bKAAAAA1BMVEUAAP KeNJXAAAAAXRSTlMAQObYZgAAAAlwSFlzAAAOxAAADsQBlSsOGwAAAApJREFUCNdjYAAAAAIAAeIhvDMAAAAASUVORK5CYII

August 14, 2020

What happened

In May 2020 we found a group of Tor exit relays that were messing with exit traffic. Specifically, they left almost all exit traffic alone, and they intercepted connections to a small number of cryptocurrency exchange websites. If a user visited the HTTP version (i.e. the unencrypted, unauthenticated version) of one of these sites, they would prevent the site from redirecting the user to the HTTPS version (i.e. the encrypted, authenticated version) of the site. If the user didn’t notice that they hadn’t ended up on the HTTPS version of the site (no lock icon in the browser) and proceeded to send or receive sensitive information, this information could be intercepted by the attacker.

We removed these attacking relays from the Tor network in May 2020. In June 2020 we found another group of relays doing a similar attack, and we removed those relays too. We don’t know whether any users were successfully attacked, but from the size of the relays involved, and the fact that the attacker tried again (the first group was offering approximately 23% of the total exit capacity, and the replacement group was offering about 19%), it’s reasonable to assume that the attacker thought it was a good use of their resources to sustain the attack.

This situation is a good reminder that HTTP requests are unencrypted and unauthenticated, and thus are still prone to attack. Tor Browser includes HTTPS-Everywhere to mitigate that risk, but it is only partially successful because it doesn’t list every website on the internet. Users who visit the HTTP version of a site will always be at higher risk.

Mitigating this kind of attack going forward

There are two pieces to mitigating this particular attack: the first piece involves steps that users and websites can do to make themselves safer, and the second piece is about identifying and protecting against relays that try to undermine the security of the Tor network.

For the website side, we would like to take the opportunity to raise the importance for website admins to always 1. Enable HTTPS for their sites (folks can get free certificates with Let’s Encrypt), and to 2. Make sure they have a redirect rule for their site added to HTTPS-Everywhere, so their users use a safe connection preemptively, rather than relying on getting redirected after making an unsafe connection. Additionally, for web services interested in avoiding exit nodes entirely, we’re asking companies and organizations to deploy onion sites.

One of the more comprehensive fixes we’re exploring from the user side is to disable plain HTTP in Tor Browser. Some years ago this step would have been unthinkable (too much of the web used only HTTP), but both HTTPS-Everywhere and an upcoming version of Firefox have experimental features that try HTTPS first by default and then have a way to fall back to HTTP if needed. It’s still unclear quite how such a feature would impact the Tor user experience, so we should try it out first at the higher levels of the Tor Security Slider to build more intuition. More details in ticket #19850.

In terms of making the Tor network more robust, we have contributors watching the network and reporting malicious relays to be rejected by our Directory Authorities. Although our “bad relays” team generally responds quickly to such reports, and we kick out malicious relays as soon as we discover them, we are still under capacity to be able to monitor the network and to identify malicious relays. If you’ve found a bad relay, you can report it by following the instructions on the bad-relays page. We will talk more about how you can help here at the end of this post.

Fundamentally, there are two hard problems here: (1) Given an unknown relay, it’s hard to know if it’s malicious. If we haven’t observed an attack from it, should we leave it in place? Attacks that impact many users are easier to spot, but when we get into the longer tail of attacks that only affect a few sites or users, the arms race is not in our favor. At the same time, the Tor network is made up of many thousands of relays all around the world, and that diversity (and the resulting decentralization) is one of its strengths. (2) Given a group of unknown relays, it’s hard to know if they’re related (that is, whether they are part of a Sybil attack). Many volunteer relay operators look to the same cheap hosting providers like Hetzner, OVH, Online, Frantech, Leaseweb, etc, and when ten new relays show up, it’s not straightforward to distinguish whether we just got ten new volunteers or one big one.

We have a design proposal for how to improve the situation in a more fundamental way by limiting the total influence from relays we don’t “know” to some fraction of the network. Then we would be able to say that by definition we trust at least 50% (or 75%, or whatever threshold we pick) of the network. More details in ticket 40001 and on the tor-relays mailing list thread: here and here.

The Tor Project’s capacity

In 2019, we created a Network Health team dedicated to keeping track of our network. This team, in part, would help us more quickly and comprehensively identify malicious relays. Creating this team was an important step for the Tor Project. Unfortunately, in April 2020 we had to lay off 1/3 of our organization due to the fundraising impacts of COVID-19. This led us to reorganize our teams internally, moving Network Health team staff to other parts of the organization. Now all of us at Tor are wearing multiple hats to cover everything that needs to be done.

Because of this limited capacity, it takes longer than we would like to tackle certain things. Our goal is to recover our funds to be able to get that Network Health team back in shape. We also know we owe our volunteers more attention and support, and we are discussing internally how to improve that given our limited capacity at the moment.

These are not easy goals. We are still in a global crisis that is affecting many economically, including our donors and sponsors. Simultaneously, one of the main sponsors of the Internet Freedom community has been hit, funding has ceased, and we are helping in the fight to restore it.

We would like to invite people to support Tor in any way they can. There are millions of people who use Tor everyday, and your support can make a big difference. Making a donation will help us increase our capacity. Raising awareness about Tor, holding Tor trainings, running an onion service, localizing Tor tools, conducting user research, and running your own relay are also impactful ways to help. There are several Relay Associations around the world that run stable Tor exit relays and you can help by donating to them, too.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts