This is what a Tor Supporter looks like: Laura Poitras

The first thing that Laura Poitras has to say about Tor is that she couldn’t have made Citizenfour without it.

“There’s no way I would have been able to protect the initial source without using Tor,” she says. “Fundamentally, without Tor and other free software tools I wouldn’t have been able to do the reporting, and the story would not have been broken.”

Laura also recalls her own learning process around encryption that allowed her to communicate easily with Snowden when he first contacted her. “I’ve been on a government watch list since 2006,” she says. “In 2010, I was interested in reaching out to Jake Appelbaum around the work he was doing with Tor. I got up to speed on encryption just to contact him, and he taught me far more. Then Snowden came along and taught me even more. So I’ve had good teachers.”

She references her first exchange with Snowden that dramatically shifted her methods of communication.

“He contacted me through Micah Lee initially,” she recalls. “And of course Micah sent the encrypted email to me. The problem was that my key was still attached to my actual identity at the time and Ed quickly encouraged me to change that. By my third email from him, I was communicating on Tails with a computer that I bought with cash, checking it only from public places. I was using the Tor Browser for all of my research, and to verify the information I was hearing. It was essential in moving the whole story forward.”

Laura is heartened by feedback she has received that Citizenfour, by so compellingly telling Snowden’s story, has helped make mass surveillance a topic for public debate.

“Before Snowden, as a journalist, I knew that I had to be careful, but didn’t quite know how to protect myself,” she remembers. “I knew I needed anonymity, but didn’t know what tools to use.”

And she encourages everyone to use, and to support Tor.

“There are so many reasons…that we want to protect our privacy and not broadcast every move we make online. Tor is an essential tool that is needed by people to do what they do. It fosters free speech and independent voices.”

Donate to Tor Today!

Tor is released and stable

The Tor 0.2.7 release series is dedicated to the memory of Tor user and privacy advocate Caspar Bowden (1961-2015). Caspar worked tirelessly to advocate human rights regardless of national borders, and oppose the encroachments of mass surveillance. He opposed national exceptionalism, he brought clarity to legal and policy debates, he understood and predicted the impact of mass surveillance on the world, and he laid the groundwork for resisting it. While serving on the Tor Project's board of directors, he brought us his uncompromising focus on technical excellence in the service of humankind. Caspar was an inimitable force for good and a wonderful friend. He was kind, humorous, generous, gallant, and believed we should protect one another without exception. We honor him here for his ideals, his efforts, and his accomplishments. Please honor his memory with works that would make him proud.

Tor is the first stable release in the Tor 0.2.7 series. It makes no changes beyond those in; the summary below lists all changes in the 0.2.7 series.

You can download the source from the usual place on the website.
Packages should be up in a few days.

The 0.2.7 series adds a more secure identity key type for relays, improves cryptography performance, resolves several longstanding hidden-service performance issues, improves controller support for hidden services, and includes small bugfixes and performance improvements throughout the program. This release series also includes more tests than before, and significant simplifications to which parts of Tor invoke which others. For a full list of changes, see below.

Changes in version - 2015-11-20
  • New system requirements:
    • Tor no longer includes workarounds to support Libevent versions before 1.3e. Libevent 2.0 or later is recommended. Closes ticket 15248.
    • Tor no longer supports copies of OpenSSL that are missing support for Elliptic Curve Cryptography. (We began using ECC when available in, for more safe and efficient key negotiation.) In particular, support for at least one of P256 or P224 is now required, with manual configuration needed if only P224 is available. Resolves ticket 16140.
    • Tor no longer supports versions of OpenSSL before 1.0. (If you are on an operating system that has not upgraded to OpenSSL 1.0 or later, and you compile Tor from source, you will need to install a more recent OpenSSL to link Tor against.) These versions of OpenSSL are still supported by the OpenSSL, but the numerous cryptographic improvements in later OpenSSL releases makes them a clear choice. Resolves ticket 16034.
  • Major features (controller):
    • Add the ADD_ONION and DEL_ONION commands that allow the creation and management of hidden services via the controller. Closes ticket 6411.
    • New "GETINFO onions/current" and "GETINFO onions/detached" commands to get information about hidden services created via the controller. Part of ticket 6411.
    • New HSFETCH command to launch a request for a hidden service descriptor. Closes ticket 14847.
    • New HSPOST command to upload a hidden service descriptor. Closes ticket 3523. Patch by "DonnchaC".

  read more »

Nine Questions about Hidden Services

This is an interview with a Tor developer who works on hidden services. Please note that Tor Browser and hidden services are two different things. Tor Browser (downloadable at allows you to browse, or surf, the web, anonymously. A hidden service is a site you visit or a service you use that uses Tor technology to stay secure and, if the owner wishes, anonymous. The secure messaging app ricochet is an example of a hidden service. Tor developers use the terms "hidden services" and "onion services" interchangeably.
1. What are your priorities for onion services development?
Personally I think it’s very important to work on the security of hidden services; that’s a big priority.
The plan for the next generation of onion services includes enhanced security as well as improved performance. We’ve broken the development down into smaller modules and we’re already starting to build the foundation. The whole thing is a pretty insane engineering job.

2. What don't people know about onion Services?
Until earlier this year, hidden services were a labor of love that Tor developers did in their spare time. Now we have a very small group of developers, but in 2016 we want to move the engineering capacity a bit farther out. There is a lot of enthusiasm within Tor for hidden services but we need funding and more high level developers to build the next generation.
3. What are some of Tor's plans for mitigating attacks?
The CMU attack was fundamentally a "guard node" attack; guard nodes are the first hop of a Tor circuit and hence the only part of the network that can see the real IP address of a hidden service. Last July we fixed the attack vector that CMU was using (it was called the RELAY_EARLY confirmation attack) and since then we've been divising improved designs for guard node security.
For example, in the past, each onion service would have three guard nodes assigned to it. Since last September, each onion service only uses one guard node—-it exposes itself to fewer relays. This change alone makes an attack against an onion service much less likely.
Several of our developers are thinking about how to do better guard node selection. One of us is writing code on this right now.
We are modeling how onion services pick guard nodes currently, and we're simulating other ways to do it to see which one exposes itself to fewer relays—the fewer relays you are exposed to, the safer you are.
We’ve also been working on other security things as well. For instance, a series of papers and talks have abused the directory system of hidden services to try to estimate the activity of particular hidden services, or to launch denial-of-service attacks against hidden services.

We’re going to fix this by making it much harder for the attacker's nodes to become the responsible relay of a hidden service (say, catfacts) and be able to track uptime and usage information. We will use a "distributed random number generator"--many computers teaming up to generate a single, fresh unpredictable random number. 

Another important thing we're doing is to make it impossible for a directory service to harvest addresses in the new design. If you don't know a hidden service address, then under the new system, you won't find it out just by hosting its HSDir entry.

There are also interesting performance things: We want to make .onion services scalable in large infrastructures like Facebook--we want high availability and better load balancing; we want to make it serious.

[Load balancing distributes the traffic load of a website to multiple servers so that no one server gets overloaded with all the users. Overloaded servers stop responding and create other problems. An attack that purposely overloads a website to cause it to stop responding is called a Denial of Service (DoS) attack.  - Kate]
There are also onion services that don’t care to stay hidden, like Blockchain or Facebook; we can make those much faster, which is quite exciting.
Meanwhile Nick is working on a new encryption design--magic circuit crypto that will make it harder to do active confirmation attacks. [Nick Mathewson is the co-founder of the Tor Project and the chief architect of our software.] Active confirmation attacks are much more powerful than passive attacks, and we can do a better job at defending against them.
A particular type of confirmation attack that Nick's new crypto is going to solve is a "tagging attack"—Roger wrote a blog post about them years ago called, "One Cell Is Enough"—it was about how they work and how they are powerful.
4. Do you run an onion service yourself?  
Yes, I do run onion services; I run an onion services on every box I have.  I connect to the PC in my house from anywhere in the world through SSH—I connect to my onion service instead of my house IP. People can see my laptop accessing Tor but don’t know who I am or where I go. 
Also, onion services have a property called NAT-punching; (NAT=Network Address Translation). NAT blocks incoming connections;it builds walls around you. Onion services have NAT punching and can penetrate a firewall. In my university campus, the firewall does not allow incoming connections to my SSH server, but with an onion service the firewall is irrelevant.
5. What is your favorite onion service that a nontechnical person might use? 
I use ricochet for my peer to peer chatting--It has a very nice UI and works well.
6. Do you think it’s safe to run an onion service? 
It depends on your adversary. I think onion services provide adequate security against most real life adversaries.

However, if a serious and highly motivated adversary were after me, I would not rely solely on the security of onion services. If your adversary can wiretap the whole Western Internet, or has a million dollar budget, and you only depend on hidden services for your anonymity then you should probably up your game. You can add more layers of anonymity by buying the servers you host your hidden service on anonymously (e.g. with bitcoin) so that even if they deanonymize you, they can't get your identity from the server. Also studying and actually understanding the Tor protocol and its threat model is essential practice if you are defending against motivated adversaries.

7. What onion services don’t exist yet that you would like to see? 
Onion services right now are super-volatile; they may appear for three months and then they disappear. For example, there was a Twitter clone, Tor statusnet; it was quite fun--small but cozy. The guy or girl who was running it couldn’t do it any longer. So, goodbye! It would be very nice to have a Twitter clone in onion services. Everyone would be anonymous. Short messages by anonymous people would be an interesting thing.
I would like to see apps for mobile phones using onion services more—SnapChat over Tor, Tinder over Tor—using Orbot or whatever. 
A good search engine for onion services. This volatility comes down to not having a search engine—you could have a great service, but only 500 sketchoids on the Internet might know about it.
Right now, hidden services are misty and hard to see, with the fog of war all around. A sophisticated search engine could highlight the nice things and the nice communities; those would get far more traffic and users and would stay up longer.

The second question is how you make things. For many people, it’s not easy to set up an onion service. You have to open Tor, hack some configuration files, and there's more.

We need a system where you double click, and bam, you have an onion service serving your blog. Griffin Boyce is developing a tool for this named Stormy. If we have a good search engine and a way for people to start up onion services easily, we will have a much nicer and more normal Internet in the onion space. 
8. What is the biggest misconception about onion services?
People don't realize how many use cases there are for onion services or the inventive ways that people are using them already. Only a few onion services ever become well known and usually for the wrong reasons.
I think it ties back to the previous discussion--—the onion services we all enjoy have no way of getting to us. Right now, they are marooned on their island of hiddenness. 
9. What is the biggest misconception about onion services development?
It’s a big and complex project—it’s building a network inside a network; building a thing inside a thing. But we are a tiny team. We need the resources and person power to do it.

(Interview conducted by Kate Krauss)

Did the FBI Pay a University to Attack Tor Users?

The Tor Project has learned more about last year's attack by Carnegie Mellon researchers on the hidden service subsystem. Apparently these researchers were paid by the FBI to attack hidden services users in a broad sweep, and then sift through their data to find people whom they could accuse of crimes. We publicized the attack last year, along with the steps we took to slow down or stop such an attack in the future:

Here is the link to their (since withdrawn) submission to the Black Hat conference:
along with Ed Felten's analysis at the time:

We have been told that the payment to CMU was at least $1 million.

There is no indication yet that they had a warrant or any institutional oversight by Carnegie Mellon's Institutional Review Board. We think it's unlikely they could have gotten a valid warrant for CMU's attack as conducted, since it was not narrowly tailored to target criminals or criminal activity, but instead appears to have indiscriminately targeted many users at once.

Such action is a violation of our trust and basic guidelines for ethical research. We strongly support independent research on our software and network, but this attack crosses the crucial line between research and endangering innocent users.

This attack also sets a troubling precedent: Civil liberties are under attack if law enforcement believes it can circumvent the rules of evidence by outsourcing police work to universities. If academia uses "research" as a stalking horse for privacy invasion, the entire enterprise of security research will fall into disrepute. Legitimate privacy researchers study many online systems, including social networks — If this kind of FBI attack by university proxy is accepted, no one will have meaningful 4th Amendment protections online and everyone is at risk.

When we learned of this vulnerability last year, we patched it and published the information we had on our blog:

We teach law enforcement agents that they can use Tor to do their investigations ethically, and we support such use of Tor — but the mere veneer of a law enforcement investigation cannot justify wholesale invasion of people's privacy, and certainly cannot give it the color of "legitimate research".

Whatever academic security research should be in the 21st century, it certainly does not include "experiments" for pay that indiscriminately endanger strangers without their knowledge or consent.

Ethical Tor Research: Guidelines

Draft 1.1

1. Goals of this document.

  • In general, to describe how to conduct responsible research on Tor and similar privacy tools.
  • To develop guidelines for research activity that researchers can use to evaluate their proposed plan.
  • Produce a (non-exhaustive) list of specific types of unacceptable activity.
  • Develop a “due diligence” process for research that falls in the scope of “potentially dangerous” activities. This process can require some notification and feedback from the Tor network or other third parties.

2. General principles

Experimentation does not justify endangering people. Just as in medicine, there are experiments in privacy that can only be performed by creating an unacceptable degree of human harm. These experiments are not justified, any more than the gains to human knowledge would justify unethical medical research on human subjects.

Research on humans' data is human research. Over the last century, we have made enormous strides in what research we consider ethical to perform on people in other domains. For example, we have generally decided that it's ethically dubious to experiment on human subjects without their informed consent. We should make sure that privacy research is at least as ethical as research in other fields.

We should use our domain knowledge concerning privacy when assessing risks. Privacy researchers know that information which other fields consider non-invasive can be used to identify people, and we should take this knowledge into account when designing our research.

Finally, users and implementors must remember that "should not" does not imply "can not." Guidelines like these can serve to guide researchers who are genuinely concerned with doing the right thing and behaving ethically; they cannot restrain the unscrupulous or unethical. Against invasions like these, other mechanisms (like improved privacy software) are necessary.

3. Guidelines for research

  1. Only collect data that is acceptable to publish. If it would be inappropriate to share it with the world, it is invasive to collect it. In the case of encrypted or secret-shared data, it can be acceptable to assume that the keys or some shares are not published.
  2. Only collect as much data as is needed: practice data minimization.
    1. Whenever possible, use analysis techniques that do not require sensitive data, but which work on anonymized aggregates.
  3. Limit the granularity of the data. For example, "noise" (added data inaccuracies) should almost certainly be added. This will require a working statistical background, but helps to avoid harm to users.
  4. Make an explicit description of benefits and risks, and argue that the benefits outweigh the risks.
    1. In order to be sure that risks have been correctly identified, seek external review from domain experts. Frequently there are non-obvious risks.
    2. Consider auxiliary data when assessing the risk of your research. Data which is not damaging on its own can become dangerous when other data is also available. For example, data from exit traffic can be combined with entry traffic to deanonymize users.
    3. Respect people's own judgments concerning their privacy interests in their own data.
    4. It's a warning sign if you can't disclose details of your data collection in advance. If knowing about your study would cause your subjects to object to it, that's a good sign that you're doing something dubious.
  5. Use a test network when at all possible.
    1. If you can experiment either on a test network without real users, or on a live network, use the test network.
    2. If you can experiment either on your own traffic or on the traffic of strangers, use your own traffic.
    3. "It was easier that way" is not justification for using live user traffic over test network traffic.

4. Examples of unacceptable research activity

  • It is not acceptable to run an HSDir, harvest onion addresses, and publish or connect to those onion addresses.
  • Don't set up exit relays to sniff, or tamper with exit traffic. Some broad measurements (relative frequency of ports; large-grained volume) may be acceptable depending on risk/benefit tradeoffs; fine-grained measures are not.
  • Don't set up relays that are deliberately dysfunctional (e.g., terminate connections to specific sites).

Tor Browser 5.5a4-hardened is released

We are pleased to announce the first release in our new hardened Tor Browser series. The download can be found in the 5.5a4-hardened distribution directory and on the download page for hardened builds.

For now this is for Linux 64bit systems only but we are thinking about supporting OS X and Windows in the future as well. As always, these builds are fully bit-for-bit reproducible.

The hardened series is built on top of the regular alpha series: it contains all the changes of the latter and further hardening, mainly against exploitation of memory corruption bugs. To this end Tor and Firefox are compiled with Address Sanitizer enabled (Tor even ships with another checker, the Undefined Behavior Sanitizer).

This additional hardening helps in two ways:

  • It gives users an even more secure Tor Browser (especially at higher security levels where Javascript is partially or completely disabled).
  • It helps identifying issues earlier allowing us to develop and backport fixes to the regular alpha and stable series.

This hardening comes with some downsides: these builds are slower than regular builds, and consume more memory. And, above all, they are considerably larger than alpha or release builds. That's why we decided to make another big change for this new series: there will only be one bundle shipped supporting all the languages found in alpha builds. Tor Launcher should help selecting the desired locale during the first start taking the operating system locale into account.

We should also point out that the hardening provided by Address Sanitizer is not perfect. In particular, if an adversary is able to determine that Address Sanitizer is in use, they may be able to use JavaScript to take advantage of this information and retain their ability to still exploit some classes of bugs. We are especially interested to learn if there are any clear ways to fingerprint our Address Sanitizer builds with a high degree of certainty for this reason. (Fair warning: performance-only fingerprinting may not be convincing without a lot of rigorous analysis, especially given that variables such as the JIT being enabled or disabled on many different types of hardware need to be taken into account).

Our initial hope was to use SoftBounds+CETS (or SafeCode), which do not have the weaknesses of Address Sanitizer, but these projects are not mature enough to compile Tor Browser (or Firefox, for that matter). We are actively exploring other hardening options, as well, and are happy to hear more suggestions.

We're especially eager to hear reports and stack traces from any crashes experienced in these builds, as they may be evidence of potentially exploitable memory issues that have not been detected in our normal builds! Advanced users may find these GDB instructions useful for this, but even the plain Address Sanitizer crash output should still be helpful.

Tor Browser 5.5a4 is released

A new alpha Tor Browser release is available for download in the 5.5a4 distribution directory and on the alpha download page.

This release features important security updates to Firefox.

Moreover, it comes with Tor and a number of other improvements. Most notably, we included Yan Zhu's fix for not leaking the Referer header when leaving a .onion domain and finally sorted out the HTTPS-Everywhere build problems allowing us to ship its latest version in our bundles again.

We fixed usability issues caused by our font fingerprinting patches and included a new defense against figerprinting users via available MIME types and plugins. Finally, besides additional minor bug fixes and clean-ups, we included an updated NoScript version.

Here is the complete changelog since 5.5a3:

  • All Platforms
    • Update Firefox to 38.4.0esr
    • Update Tor to
    • Update NoScript to
    • Update HTTPS-Everywhere to 5.1.1
    • Update Torbutton to
      • Bug 9623: Spoof Referer when leaving a .onion domain
      • Bug 16620: Remove old handling code
      • Bug 17164: Don't show text-select cursor on circuit display
      • Bug 17351: Remove unused code
      • Translation updates
    • Bug 17207: Hide MIME types and plugins from websites
    • Bug 16909+17383: Adapt to HTTPS-Everywhere build changes
    • Bug 16620: Move handling into a Firefox patch
    • Bug 17220: Support math symbols in font whitelist
    • Bug 10599+17305: Include updater and build patches needed for hardened builds
    • Bug 17318: Remove dead ScrambleSuit bridge
    • Bug 17428: Remove default Flashproxy bridges
    • Bug 17473: Update meek-amazon fingerprint
  • Windows
    • Bug 17250: Add localized font names to font whitelist
  • OS X
    • Bug 17122: Rename Japanese OS X bundle
  • Linux
    • Bug 17329: Ensure that non-ASCII characters can be typed (fixup of #5926)

Tor Browser 5.0.4 is released

A new stable release for Tor Browser is available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox.

Additionally, we included Yan Zhu's fix for not leaking the Referer header when leaving a .onion domain and are shipping an updated NoScript version.

These and all the other changes (minor bug fixes and clean-ups) can be found in the complete changelog since 5.0.3:

  • All Platforms
    • Update Firefox to 38.4.0esr
    • Update NoScript to
    • Update Torbutton to
      • Bug 9623: Spoof Referer when leaving a .onion domain
      • Bug 16735: about:tor should accommodate different fonts/font sizes
      • Bug 16937: Don't translate the homepage/spellchecker dictionary string
      • Bug 17164: Don't show text-select cursor on circuit display
      • Bug 17351: Remove unused code
      • Translation updates
    • Bug 16937: Remove the en-US dictionary from non en-US Tor Browser bundles
    • Bug 17318: Remove dead ScrambleSuit bridge
    • Bug 17473: Update meek-amazon fingerprint
    • Bug 16983: Isolate favicon requests caused by the tab list dropdown
    • Bug 17102: Don't crash while opening a second Tor Browser
  • Windows
    • Bug 16906: Don't depend on Windows crypto DLLs
  • Linux
    • Bug 17329: Ensure that non-ASCII characters can be typed (fixup of #5926)
Syndicate content Syndicate content