Tor security advisory: exit relays running sslstrip in May and June 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.


August 14, 2020


Can OONI detect this type of attack? "23% of the total exit capacity"? Wow. At what point could it be a state-level agency? HTTPS-first sounds great, and I hope it isn't easy for intermediaries to degrade it to HTTP. In my experience, the higher levels of the Tor Security Slider interfere with Javascript and WebGL, and HTTPS simply denotes whether Javascript is allowed to run. It's been that way for years.

An automated tool that tests a bunch of things is exactly what you want, yes. But what you really want is more of a "reverse OONI" -- the cool thing about OONI is that you get a bunch of different vantage points around the world, whereas here, you can do tests of all the Tor exit relays from a single Tor client.

One tool that's useful here is exitmap:
and it's designed in a modular way so you can make modules to test each new behavior you're considering.

The public version of exitmap comes with some modules already, and the bad-relays team has some non-public modules that they use for testing as well. You can read my tor-talk post from long ago for more thoughts on the tradeoff of non-public modules (since after all, we're generally fans of free software here):

As for the "https only mode" idea, and "I hope it isn't easy for intermediaries to degrade it to HTTP", yes exactly. The phrase you want to learn about is "downgrade attack":
Protocol downgrade attacks are a real issue, and one of the usability questions here will be how to warn the user that https didn't work, and would they like to try http instead, in a way that leads the user to the right behavior.

Hope that helps!


August 14, 2020


Great post. Wow, 2016? I have been waiting for HTTPS connections only, for a long time. Looking forward to seeing this implemented.

the https:// only options are coming in the next Firefox release. in FF-Nightly(version81), I am using normally, it is working already, you have to change it in config:about though; I think it is already working in FF beta(version 80) also . so once Tor Browser , using the FF-ESR comes to the version 80 it will be possible to use in Tor Browser and I hope it will be default in Tor-Browser.


August 14, 2020


Hang on wait a minute. You mean there are cryptocurrency exchange sites that even *have* a functioning unencrypted http version of their site?? This whole "attack" -- and I say that in air quotes because the basic idea is extremely primitive and not Tor-specific at all, and in fact it goes back to the days of unencrypted WiFi and ARP cache poisoning -- would be impossible if the was a simple page that said "Redirecting you to".

Even if the attacker was preventing the redirect, the user would have been like "wtf is wrong with this thing. Why won't it redirect?" at which point the user might type https:// manually, or restart Tor browser and get a new circuit, or try again 10 minutes later and get a new circuit also. That is, in contrast to displaying a fully functional insecure version of the site, where the user will try to log in and transfer money.

Why would a site ever, *ever* allow cryptocurrency addresses, usernames, passwords, cookies, or any sensitive information to be accessible over http in this day and age?

I feel like I missed something important? Because all I see here is bad security practice on the part of the exchanges' web developers, and an age-old well-known weakness in the way Tor and insecure http have always worked.

Which, if so, is great news because it means Tor is still as strong as ever. I've always appreciated Tor Project's transparency about these things, and I can't express how important Tor is to me! Thank you!

Yeah, there is a catch. The website here behaves just as you described: if you connect to it over http, it gives you a redirect to its https version. It refuses to do anything else over http.

But imagine you're an attacker in the middle. *You* pretend to be the http website, and you run a reverse proxy which sends the traffic to the real website over https. Then the real website sees an https connection, so it's happy to send or receive sensitive information, but that https connection is being made by the attacker. Meanwhile the user is having an http conversation with the attacker, and thinks it's the real site but it isn't.

This is exactly the problem that HTTPS-Everywhere is trying to tackle: it's that first connection, where you use http, that could send you anywhere at all. If you rely on the website to redirect you, then if you never actually reach the website, you never get the redirect.

That said, yes you're right, this is an age-old attack and the answers are the same as they have always been. The reasons to mention it here are (a) the scale of the Sybil attack involved in deploying it this time around, and (b) to highlight some of the longer-term changes that we should make, like the shift to disabling http in Tor Browser, and the idea of partitioning relays into "known" and "unknown" sets and putting a cap on how much traffic the unknown set can get.

Ah, okay. I'm familiar with that kind of attack, I just didn't think it all the way through before posting. Thanks for clarifying and hopefully other readers will find it helpful as well.

The idea of partitioning known and unknown relays is new to me but sounds very interesting. I'll definitely read up on this. Thanks for bringing it to my attention.

The easy answer: .onion domains come with their own end-to-end encryption, so no, it is way less important to use https with them.

The more complex answer: it depends on the set-up for the individual onion service. Specifically, it depends where the Tor process that runs the onion service lives, relative to the website that it forwards its traffic to. In many cases, they will live on the same computer, and then the connection between them is over the local network, and there's no place an attacker can get in to attack. But let's say I run an onion service and point its traffic to http://wikipedia. Now the traffic between the user's Tor Browser and the onion service is protected (encrypted, authenticated) by Tor, but the traffic between the onion service and wikipedia is http (and thus attackable, if somebody is in the right place on the internet). That's one of the reasons why big sites that offer an onion service (Facebook, BBC, etc) offer their onion service over https: there is no single computer which runs Facebook's website, so there will be some traffic somewhere on the internet between the Tor that hosts facebook.onion and the website that hosts, and it's safest for that traffic to be wrapped in its own layer of https encryption. In the future, we're heading toward having Let's Encrypt be able to give out https certs for onion domains for free, and then it will be something that more people do.

The answer to your actual question: onion services were not attacked here, and aren't vulnerable to the attack we're talking about here.

Shameless plug: watch the Defcon talk on onion services and what security properties they do/don't provide :)

Thanks! Should the Tor Project discourage the usage of EV certificates for .onion domains by the likes of DuckDuckGo, Facebook, etc. since the next Tor Browser will almost certainly no longer distinguish them like all modern browsers?

Yay https certificates. I don't think I have an opinion on what kind of https certs people should get. (Ok, I do have an opinion: you should get the free kind.)

The reason these folks got EV certs is because up until February of this year, EV certs were the only kind you could get for onion addresses. In February, thanks to the help of a friendly person from Mozilla (now at Fastly), we managed to get the official policy changed. So now you can get a DV cert for your onion domain:…

Now, it turns out Let's Encrypt isn't ready to issue them yet. They put in a funding proposal to OTF to build the onion verification part, but, see above links about the OTF mess. So we're working to help them get funding from some other route.

HSTS is okay, but only if you solved the problem that the very first request before receiving the HSTS information can still go out unencrypted and unauthenticated. So, alone it is not a means to solve the problem. So, getting on the HTTPS-Everywhere rule list and/or in the browser HTTPS preload list would be the way to go.

> getting on the HTTPS-Everywhere rule list and/or in the browser HTTPS preload list would be the way to go.

I urge Tor Project to maintain situation awareness regarding the experience of Tails users. Currently the rule list you mention loads early in a Tails session, but I fear that at times users in a hurry might arrive at an http site before the list loads.

I'd love to see more guest posts here from Tails Project. It seems that they did not post as they have in the past when a new version came out. I hope cooperation between Tails and Tor remains close.


August 17, 2020


Thank you for this informative post. But I think you should name names.

> (the first group was offering approximately 23% of the total exit capacity, and the replacement group was offering about 19%)

Was this an announced family or a covert family? Earlier this year, posters complained about indications of suspicious activity by a large family in that time frame, and now we are of course wondering if you are talking about the family we think you are talking about.

If so, speaking for myself only, I do not use cryptocurrency so it should raise a red flag that I have observed anomalies while using a Secure Drop journalism site in the time frame, including:

o a huge flow of outbound traffic (dozens of megabytes) through the circuit in question, which seemed excessive to upload one small file (kilobyte size),

o mysterious circuit "freezes" (possibly caused by some kind of interference with the exit node, possibly *not* with the cooperation or knowledge of the person running that node) which resulted in failures to properly log out of a Secure Drop.

The nature of activity suggests that my adversary was likely FBI seeking to deanonymize a would-be whistleblower.

I believe Tor Project should assume that adversaries do run high bandwidth Tor nodes whose sole purpose is to deanonymize or infect a small number of targets. For example, it is said that FBI's high bandwidth Tor exit nodes recently targeted someone who had been abusing Tor for, you guessed it, on-line sexual abuse of minor children. However, while FBI is apparently willing to talk "off the record" about that kind of target, the history of FBI/CIA strongly suggests that troublesome journalists and whistleblowers are more representative of the target list. BTW, one important story which has not been widely covered is the revelation that CIA has begun a program of massive cyberattacks apparently targeting many US citizens (recent rule changes have lent this ugly activity a thin veneer of "legality").

In his book Dark Mirror, Barton Gellman praises Werner Koch for his years of lonely work maintaining GPG (fortunately some years ago others began to contribute which has greatly improved the health of GPG), in addition to praising Secure Drop. Please note that as governments around the world (e.g. Poland, Brazil, Belarus, USA) crack down on citizens who are trying to communicate information in the public interest to journalists, Secure Drop (and privacy/anonymity-enhancing software generally) are more vital than ever. Coverage of the recent election in Belarus has been largely drowned out by coverage of upcoming US election, which is alarming because there is good reason to think Putin's operatives have coached Russian-favored candidates in both Belarus and the USA in the art of fixing an election.

IMO, SD desperately needs some love right now, and I urge TP post here a tutorial on using Secure Drop sites safely. What kind of behavior is expected and what should raise an immediate red flag? How to check that the onion address you have is correct and that the site is running a fully patched SD? Is the list at an onion site allegedly run by FOTP


reliable and up to date? If so, be aware that my attempts to use that directory result in time outs.

SD had serious flaws which have been fixed but apparently many news sites never reinstalled SD and those that did (e.g. The Intercept) failed to publicize the new (much longer) onion address. I hope TP can work with SD, EFF, ACLU, and major news sites to help make sure that people know the correct onion address.

The webpage allegedly owned by The Intercept

says that the current onion address for the Secure Drop operated by The Intercept is


I believe that users should stop expecting orgs to generate a semi-memorable short onion address. Rather, I suspect that best practice may be to keep secure drop sites on a dedicated USB, preferably the kind with a R/O tab.

> the attack described doesn't affect SecureDrop users or other onion sites because onion services does not use exit nodes

Thank you Gus, that is very good to know!

Now I am wondering if my experience has something to do with the DDOS attacks on onion sites...

> As explained in the blog

I can't find any such explanation in the orginal blog post to which I was responding.


August 17, 2020


funny, how you do not mention nusenu who researched this issue A LOT

funny, how you ignore the fact that it was known for weeks that malicious relays around before those relays were removed

you should write a statement on this. maybe, next time, before first news sites start writing about this issue

Could TP please say whether or not the continuing attack mentioned by nusenu in the Medium piece turned out to be the one sslstrip attack described by isabela above?

Alas, I recognize some of the nodes mentioned in the nusenu piece as ones I suspected of bad behavior.

@ Nusenu: The new medium "privacy policy" is quite nasty. Find another place to post. We cannot accept sites which claim that by continuing to use the site we are "accepting" their sharing of information with contractors, advertisers, LEAs, etc. God, the modern internet is disgusting. --> Download Tor Browser --> Download for OS X (macOS). You can choose your language in the top right corner of the page. If that isn't enough, try the white links under the circles. In particular, "Download in another language or platform". Speaking of which...

DEVELOPERS! On Tor Browser's download page, don't you think it's about time to re-word "OS X" into "macOS"? Apple renamed it to macOS in 2016.


August 17, 2020


", the arms race is not in our favor."

"arms race" is a to vaguely term. Mitigate plausible attack experiments would be a better good idea?
For example hardening crypto against Quantum computing not after brokening RSA/Curves/(AES) is in the press, long time after intelligence agencies have build it with billions secretly.


August 20, 2020


PLEASE do not ban plain HTTP.

Let's Encrypt is refusing to issue me a certificate. They are acting as internet censors. PKI should not decide who can publish on the web.

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

9 + 8 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.