Here’s what you need to know about the recent research study on traffic correlation attacks:
While it’s great to see more research on traffic correlation attacks, this is not a new area of research. This is one study on the subject in a controlled environment using one readily available traffic monitoring technology to analyze Tor traffic. The researcher has clarified in the media that it was only 81.4 percent of their experiments not “81 percent of all Tor traffic” as has been reported elsewhere.
The Tor network provides anonymity by routing the user’s information through multiple servers (usually three) so that it is hard to detect the person’s physical location.
Tor protects users by:
1) encryption to ensure privacy of data within the Tor network,
2) authentication so clients know they're talking to the relays they meant to talk to, and
3) signatures to make sure all clients know the same set of relays.
In theory it may be possible to track Tor users by linking up their entry and exit points on the network but it is generally very difficult to do so. The Tor network design, however, does not protect against a targeted attack by a global passive adversary (such as the NSA) intent on figuring out whom to investigate through watching and measuring Tor traffic going into and out of the network and correlating the information on both sides. We encourage you to learn more about what Tor does provide.
Tor is used by 2.5 million people a day including the general public, journalists, companies, activists, military, and law enforcement and is a very safe, reliable way to protect your privacy on the Internet.
Mozilla announced that the Tor Project and the Center for Democracy & Technology will be part of their new privacy initiative called Polaris, a collaboration to bring even more privacy features into Mozilla’s products. We are honored to be working alongside Mozilla as well as the Center for Democracy & Technology to give Firefox users more options to protect their privacy.
Mozilla is an industry leader in developing features to support the user’s desire for increased privacy online and shares the Tor Project's mission of helping people protect their security online. At the core of Mozilla's values is the belief that individuals’ privacy cannot be treated as optional. We share this belief. Millions of people around the world rely on the protection of the Tor software and network to safeguard their anonymity. We appreciate companies like Mozilla that see the importance of safeguarding privacy. The Tor volunteer network has grown to the point that large companies can usefully contribute without hurting network diversity. The Tor network will get even better with Mozilla's help, and we hope that their participation will encourage even more organizations to join us.
The initial projects with Mozilla will focus on two areas:
The Tor Browser is built on the Firefox platform and we are excited to have the resources of Mozilla’s engineers to help us merge the many Firefox privacy fixes into the Mozilla codebase. The increased attention from Mozilla will give us time to focus on finding and fixing new issues rather than maintaining our fork.
Tor's network size constrains the number of users that can use Tor concurrently. In the short term, Mozilla will help address this by hosting high-capacity Tor middle relays to make Tor’s network more responsive and allow Tor to serve more users.
We believe that the Tor Browser is one of the best ways to protect privacy on the web and this partnership is a huge step in advancing people’s right to freedom of expression online.
Recently it was announced that a coalition of government agencies took control of many Tor hidden services. We were as surprised as most of you. Unfortunately, we have very little information about how this was accomplished, but we do have some thoughts which we want to share.
Over the last few days, we received and read reports saying that several Tor relays were seized by government officials. We do not know why the systems were seized, nor do we know anything about the methods of investigation which were used. Specifically, there are reports that three systems of Torservers.net disappeared and there is another report by an independent relay operator. If anyone has more details, please get in contact with us. If your relay was seized, please also tell us its identity so that we can request that the directory authorities reject it from the network.
But, more to the point, the recent publications call the targeted hidden services seizures "Operation Onymous" and they say it was coordinated by Europol and other government entities. Early reports say 17 people were arrested, and 400 hidden services were seized. Later reports have clarified that it was hundreds of URLs hosted on roughly 27 web sites offering hidden services. We have not been contacted directly or indirectly by Europol nor any other agency involved.
Tor is most interested in understanding how these services were located, and if this indicates a security weakness in Tor hidden services that could be exploited by criminals or secret police repressing dissents. We are also interested in learning why the authorities seized Tor relays even though their operation was targetting hidden services. Were these two events related?
How did they locate the hidden services?
So we are left asking "How did they locate the hidden services?". We don't know. In liberal democracies, we should expect that when the time comes to prosecute some of the seventeen people who have been arrested, the police would have to explain to the judge how the suspects came to be suspects, and that as a side benefit of the operation of justice, Tor could learn if there are security flaws in hidden services or other critical internet-facing services. We know through recent leaks that the US DEA and others have constructed a system of organized and sanctioned perjury which they refer to as "parallel construction."
Unfortunately, the authorities did not specify how they managed to locate the hidden services. Here are some plausible scenarios:
The first and most obvious explanation is that the operators of these hidden services failed to use adequate operational security. For example, there are reports of one of the websites being infiltrated by undercover agents and the affidavit states various operational security errors.
Another explanation is exploitation of common web bugs like SQL injections or RFIs (remote file inclusions). Many of those websites were likely quickly-coded e-shops with a big attack surface. Exploitable bugs in web applications are a common problem.
Apparently, there are ways to link transactions and deanonymize Bitcoin clients even if they use Tor. Maybe the seized hidden services were running Bitcoin clients themselves and were victims of similar attacks.
Attacks on the Tor network
The number of takedowns and the fact that Tor relays were seized could also mean that the Tor network was attacked to reveal the location of those hidden services. We received some interesting information from an operator of a now-seized hidden service which may indicate this, as well. Over the past few years, researchers have discovered various attacks on the Tor network. We've implemented some defenses against these attacks, but these defenses do not solve all known issues and there may even be attacks unknown to us.
For example, some months ago, someone was launching non-targetted deanonymization attacks on the live Tor network. People suspect that those attacks were carried out by CERT researchers. While the bug was fixed and the fix quickly deployed in the network, it's possible that as part of their attack, they managed to deanonymize some of those hidden services.
Another possible Tor attack vector could be the Guard Discovery attack. This attack doesn't reveal the identity of the hidden service, but allows an attacker to discover the guard node of a specific hidden service. The guard node is the only node in the whole network that knows the actual IP address of the hidden service. Hence, if the attacker then manages to compromise the guard node or somehow obtain access to it, she can launch a traffic confirmation attack to learn the identity of the hidden service. We've been
discussing various solutions to the guard discovery attack for the past many months but it's not an easy problem to fix properly. Help and feedback on the proposed designs is appreciated.
*Similarly, there exists the attack where the hidden service selects the attacker's relay as its guard node. This may happen randomly or this could occur if the hidden service selects another relay as its guard and the attacker renders that node unusable, by a denial of service attack or similar. The hidden service will then be forced to select a new guard. Eventually, the hidden service will select the attacker.
Furthermore, denial of service attacks on relays or clients in the Tor network can often be leveraged into full de-anonymization attacks. These techniques go back many years, in research such as "From a Trickle to a Flood", "Denial of Service or Denial of Security?", "Why I'm not an Entropist", and even the more recent Bitcoin attacks above. In the Hidden Service protocol there are more vectors for DoS attacks, such as the set of HSDirs and the Introduction Points of a Hidden Service.
Finally, remote code execution exploits against Tor software are also always a possibility, but we have zero evidence that such exploits exist. Although the Tor source code gets continuously reviewed by our security-minded developers and community members, we would like more focused auditing by experienced bug hunters. Public-interest initiatives like Project Zero could help out a lot here. Funding to launch a bug bounty program of our own could also bring real benefit to our codebase. If you can help, please get in touch.
Advice to concerned hidden service operators
As you can see, we still don't know what happened, and it's hard to give concrete suggestions blindly.
If you are a concerned hidden service operator, we suggest you read the cited resources to get a better understanding of the security that hidden services can offer and of the limitations of the current system. When it comes to anonymity, it's clear that the tighter your threat model is, the more informed you need to be about the technologies you use.
If your hidden service lacks sufficient processor, memory, or network resources the DoS based de-anonymization attacks may be easy to leverage against your service. Be sure to review the Tor performance tuning guide to optimize your relay or client.
*Another possible suggestion we can provide is manually selecting the guard node of a hidden service. By configuring the EntryNodes option in Tor's configuration file you can select a relay in the Tor network you trust. Keep in mind, however, that a determined attacker will still be able to determine this relay is your guard and all other attacks still apply.
The task of hiding the location of low-latency web services is a very hard problem and we still don't know how to do it correctly. It seems that there are various issues that none of the current anonymous publishing designs have really solved.
In a way, it's even surprising that hidden services have survived so far. The attention they have received is minimal compared to their social value and compared to the size and determination of their adversaries.
It would be great if there were more people reviewing our designs and code. For example, we would really appreciate feedback on the upcoming hidden service revamp or help with the research on guard discovery attacks (see links above).
Also, it's important to note that Tor currently doesn't have funding for improving the security of hidden services. If you are interested in funding hidden services research and development, please get in touch with us. We hope to find time to organize a crowdfunding campaign to acquire independent and focused hidden service funding.
Thanks to Griffin, Matt, Adam, Roger, David, George, Karen, and Jake for contributions to this post.
* Added information about guard node DoS and EntryNodes option - 2014/11/09 18:16 UTC
Tor misused by criminals
Several people contacted The Tor Project recently because some software told them to install the Tor Browser to access a website. There is no affiliation between the criminals who wrote this software and Tor.
What happened here?
The computer is probably infected with what's called ransomware. This is a kind of malicious software which restricts access to the files and demands a ransom. In this case the authors of the ransomware CryptoLocker set up a website which is only reachable by using Tor. That is why people are thinking that the software is somehow related to The Tor Project.
In fact, CryptoLocker is unrelated to The Tor Project. We didn't produce it, and we didn't ask to be included in the criminal infection of any computer. We cannot help you with your infection. However, according to the BBC you may be able to decrypt your files for free. If not, Bleeping Computer can provide more information.
We, the people of Tor, are very sorry to hear that some individual misused the anonymity granted by our service. The vast majority of our users use Tor in a responsible way. Thank you for your understanding.
2013 was a great year for Tor. The increasing awareness of the lack of privacy online, increasing Internet censorship around the world, and general interest in encryption has helped continue to keep us in the public mind. As a result, our supporters have increased our funding to keep us on the leading edge of our field, this of course, means you. We're happy to have more developers, advocates, and support volunteers. We're encouraged as the general public talks about Tor to their friends and neighbors. Join us as we continue to fight for your privacy and freedom on the Internet!
After completing the standard audit, our 2013 state and federal tax filings are available. We publish all of our related tax documents because we believe in transparency. All US non-profit organizations are required by law to make their tax filings available to the public on request by US citizens. We want to make them available for all.
Part of our transparency is simply publishing the tax documents for your review. The other part is publishing what we're working on in detail. We hope you'll join us in furthering our mission (a) to develop, improve and distribute free, publicly available tools and programs that promote free speech, free expression, civic engagement and privacy rights online; (b) to conduct scientific research regarding, and to promote the use of and knowledge about, such tools, programs and related issues around the world; (c) to educate the general public around the world about privacy rights and anonymity issues connected to Internet use.
All of this means you can look through our source code, including our design documents, and all open tasks, enhancements, and bugs available on our tracking system. Our research reports are available as well. From a technical perspective, all of this free software, documentation, and code allows you and others to assess the safety and trustworthiness of our research and development. On another level, we have a 10 year track record of doing high quality work, saying what we're going to do, and doing what we said.
Internet privacy and anonymity is more important and rare than ever. Please help keep us going through getting involved, donations, or advocating for a free Internet with privacy, anonymity, and keeping control of your identity.
As posted by Roger on the Tor-Talk mailing list:
Journalists are asking us about the Black Hat talk on attacking Tor that got cancelled. We're still working with CERT to do a coordinated disclosure of the details (hopefully this week), but I figured I should share a few details with you earlier than that.
1) We did not ask Black Hat or CERT to cancel the talk. We did (and still do) have questions for the presenter and for CERT about some aspects of the research, but we had no idea the talk would be pulled before the announcement was made.
2) In response to our questions, we were informally shown some materials. We never received slides or any description of what would be presented in the talk itself beyond what was available on the Black Hat Webpage.
3) We encourage research on the Tor network along with responsible disclosure of all new and interesting attacks. Researchers who have told us about bugs in the past have found us pretty helpful in fixing issues, and generally positive to work with.
[Edit 30 July 2014: here is the security advisory we posted.]
As quoted in the original article on Das Erste:
We've been thinking of state surveillance for years because of our work in places where journalists are threatened. Tor's anonymity is based on distributed trust, so observing traffic at one place in the Tor network, even a directory authority, isn't enough to break it. Tor has gone mainstream in the past few years, and its wide diversity of users -- from civic-minded individuals and ordinary consumers to activists, law enforcement, and companies -- is part of its security. Just learning that somebody visited the Tor or Tails website doesn't tell you whether that person is a journalist source, someone concerned that her Internet Service Provider will learn about her health conditions, or just someone irked that cat videos are blocked in her location.
Trying to make a list of Tor's millions of daily users certainly counts as widescale collection. Their attack on the bridge address distribution service shows their "collect all the things" mentality -- it's worth emphasizing that we designed bridges for users in countries like China and Iran, and here we are finding out about attacks by our own country. Does reading the contents of those mails violate the wiretap act? Now I understand how the Google engineers felt when they learned about the attacks on their infrastructure.
We’re making the Internet more secure, by taking part in #ResetTheNet https://resetthenet.org