Tor 0.3.0.2-alpha fixes a denial-of-service bug where an attacker could cause relays and clients to crash, even if they were not built with the --enable-expensive-hardening option. This bug affects all 0.2.9.x versions, and also affects 0.3.0.1-alpha: all relays running an affected version should upgrade.
Tor 0.3.0.2-alpha also improves how exit relays and clients handle DNS time-to-live values, makes directory authorities enforce the 1-to-1 mapping of relay RSA identity keys to ED25519 identity keys, fixes a client-side onion service reachability bug, does better at selecting the set of fallback directories, and more.
You can download the source code from https://dist.torproject.org/ but most users should wait for the upcoming 7.0a Tor Browser alpha release, or for their upcoming system package updates.
Changes in version 0.3.0.2-alpha - 2017-01-23
- Major bugfixes (security, also in 0.2.9.9):
- Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes--and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.
- Major features (security):
- Change the algorithm used to decide DNS TTLs on client and server side, to better resist DNS-based correlation attacks like the DefecTor attack of Greschbach, Pulls, Roberts, Winter, and Feamster. Now relays only return one of two possible DNS TTL values, and clients are willing to believe DNS TTL values up to 3 hours long. Closes ticket 19769.
Tor 0.2.9.9 fixes a denial-of-service bug where an attacker could cause relays and clients to crash, even if they were not built with the --enable-expensive-hardening option. This bug affects all 0.2.9.x versions, and also affects 0.3.0.1-alpha: all relays running an affected version should upgrade.
This release also resolves a client-side onion service reachability bug, and resolves a pair of small portability issues.
You can download the source code from https://dist.torproject.org/ but most users should wait for the upcoming Tor Browser release, or for their upcoming system package updates.
Changes in version 0.2.9.9 - 2017-01-23
- Major bugfixes (security):
- Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes -- and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.
- Major bugfixes (client, onion service):
- Fix a client-side onion service reachability bug, where multiple socks requests to an onion service (or a single slow request) could cause us to mistakenly mark some of the service's introduction points as failed, and we cache that failure so eventually we run out and can't reach the service. Also resolves a mysterious "Remote server sent bogus reason code 65021" log warning. The bug was introduced in ticket 17218, where we tried to remember the circuit end reason as a uint16_t, which mangled negative values. Partially fixes bug 21056 and fixes bug 20307; bugfix on 0.2.8.1-alpha.
- Minor features (geoip):
- Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2 Country database.
- Minor bugfixes (portability):
- Avoid crashing when Tor is built using headers that contain CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix on 0.2.9.1-alpha.
- Fix Libevent detection on platforms without Libevent 1 headers installed. Fixes bug 21051; bugfix on 0.2.9.1-alpha.
During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom. Donate today!
So far in this blog series we've highlighted mainly software and advocacy projects. Today is a little different: I'm going to explain more about Tor's role in the academic world of privacy and security research.
Part one: Tor matters to the research community
Just about every major security conference these days has a paper analyzing, attacking, or improving Tor. While ten years ago the field of anonymous communications was mostly theoretical, with researchers speculating that a given design should or shouldn't work, Tor now provides an actual deployed testbed. Tor has become the gold standard for anonymous communications research for three main reasons:
First, Tor's source code and specifications are open. Beyond its original design document, Tor provides a clear and published set of RFC-style specifications describing exactly how it is built, why we made each design decision, and what security properties it aims to offer. The Tor developers conduct design discussion in the open, on public development mailing lists, and the public development proposal process provides a clear path by which other researchers can participate.
Second, Tor provides open APIs and maintains a set of tools to help researchers and developers interact with the Tor software. The Tor software's "control port" lets controller programs view and change configuration and status information, as well as influence path selection. We provide easy instructions for setting up separate private Tor networks for testing. This modularity makes Tor more accessible to researchers because they can run their own experiments using Tor without needing to modify the Tor program itself.
Third, real users rely on Tor. Every day hundreds of thousands of people connect to the Tor network and depend on it for a broad variety of security goals. In addition to its emphasis on research and design, The Tor Project has developed a reputation as a non-profit that fosters this community and puts its users first. This real-world relevance motivates researchers to help make sure Tor provides provably good security properties.
I wrote the above paragraphs in 2009 for our first National Science Foundation proposal, and they've become even more true over time. A fourth reason has also emerged: Tor attracts researchers precisely because it brings in so many problems that are at the intersection of "hard to solve" and "matter deeply to the world". How to protect communications metadata is one of the key open research questions of the century, and nobody has all the answers. Our best chance at solving it is for researchers and developers all around the world to team up and all work in the open to build on each other's progress.
Since starting Tor, I've done probably 100 Tor talks to university research groups all around the world, teaching grad students about these open research problems in the areas of censorship circumvention (which led to the explosion of pluggable transport ideas), privacy-preserving measurement, traffic analysis resistance, scalability and performance, and more.
The result of that effort, and of Tor's success in general, is a flood of research papers, plus a dozen research labs who regularly have students who write their thesis on Tor. The original Tor design paper from 2004 now has over 3200 citations, and in 2014 Usenix picked that paper out of all the security papers in 2004 to win their Test of Time award.
Part two: University collaborations
This advocacy and education work has also led to a variety of ongoing collaborations funded by the National Science Foundation, including with Nick Feamster's group at Princeton on measuring censorship, with Nick Hopper's group at University of Minnesota on privacy-preserving measurement, with Micah Sherr's group at Georgetown University on scalability and security against denial of service attacks, and an upcoming one with Matt Wright's group at RIT on defense against website fingerprinting attacks.
All of these collaborations are great, but there are precious few people on the Tor side who are keeping up with them, and those people need to balance their research time with development, advocacy, management, etc. I'm really looking forward to the time where Tor can have an actual research department.
And lastly, I would be remiss in describing our academic collaborations without also including a shout-out to the many universities that are running exit relays to help the network grow. As professor Leo Reyzin from Boston University once explained for why it is appropriate for his research lab to support the Tor network, "If biologists want to study elephants, they get an elephant. I want my elephant." So, special thanks to Boston University, University of Michigan, University of Waterloo, MIT, CMU (their computer science department that is), University of North Carolina, University of Pennsylvania, Universidad Galileo, and Clarkson University. And if you run an exit relay at a university but you're not on this list, please reach out!
Part three: The Privacy Enhancing Technologies Symposium
Another critical part of the privacy research world is the Privacy Enhancing Technologies Symposium (PETS), which is the premiere venue for technical privacy and anonymity research. This yearly gathering started as a workshop in 2000, graduated to being called a symposium in 2008, and in 2015 it became an open-access journal named Proceedings on Privacy Enhancing Technologies.
The editorial board and chairs for PETS over the years overlap greatly with the Tor community, with a lot of names you'll see at both PETS and the Tor twice-yearly meetings, including Nikita Borisov, George Danezis, Claudia Diaz, Roger Dingledine (me), Ian Goldberg, Rachel Greenstadt, Kat Hanna, Nick Hopper, Steven Murdoch, Paul Syverson, and Matt Wright.
But beyond community overlap, The Tor Project is actually the structure underneath PETS. The group of academics who run the PETS gatherings intentionally did not set up corporate governance and all those pieces of bureaucracy that drag things down — so they can focus on having a useful research meeting each year — and Tor stepped in to effectively be the fiscal sponsor, by keeping the bank accounts across years, and by being the "owner" for the journal since De Gruyter's paperwork assumes that some actual organization has to own it. We're proud that we can help provide stability and longevity for PETS.
Speaking of all these papers: we have tracked the most interesting privacy and anonymity papers over the years on the anonymity bibliography (anonbib). But at this point, anonbib is still mostly a two-man show where Nick Mathewson and I update it when we find some spare time, and it's starting to show its age since its launch in 2003, especially with the huge growth in the field, and with other tools like Google Scholar. Probably the best answer is that we need to trim it down so it's more of a "recommended reading list" than a resource of all relevant papers. If you want to help, let us know!
Part four: The Tor Research Safety Board
This post is running long, so I will close by pointing to the Tor Research Safety Board, a group of researchers who study Tor and who want to minimize privacy risks while fostering a better understanding of the Tor network and its users. That page lists a set of guidelines on what to consider when you're thinking about doing research on Tor users or the Tor network, and a process for getting feedback and suggestions on your plan. We did a soft launch of the safety board this past year in the rump session at PETS, and we've fielded four requests for advice so far. We've been taking it slow in turns of publicity, but if you're a researcher and you can help us refine our process, please take a look!
During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom.
apt-transport-tor and Debian onions
Did you know that when you're using Debian, you can configure your operating system package installs and updates to route through Tor?
Doing updates via Tor provides some really compelling security properties. One of the big benefits is that an attacker can't target you for a malicious update: even if they manage to steal some package signing keys and break into the update server and replace packages, they still can't tell that it's you asking for the update. So if they want to be sure you get the malicious update, they're forced to attack everybody who updates, which means a really noisy attack that is much more likely to get noticed. This anonymity goal is one of the main reasons that Tor Browser does its updates over Tor as well.
Another big feature of updating via Tor is that the package repository, or somebody watching it, can't track what programs you've installed. Similarly, somebody spying on your Internet connection will have a tougher time learning which packages you fetch (though this part of the protection is not as strong, since maybe they can count bytes or something and guess).
As Debian's blog puts it:
"The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others. Consequently, we are pleased to announce that we have started making several of the various web services provided by both Debian and Tor available via onion services."
Not showing the world what packages you fetch is good common-sense data hygiene, but it can also provide safety when you're updating a package due to a security vulnerability, and you don't want people to learn that you're running a vulnerable version right now.
How does it work from a technical perspective? The apt-transport-tor deb package introduces a new "tor+http" transport that you can use in your /etc/apt/sources.list file -- so while before you would typically list a Debian package repository as being an "http" address, now you can list it as being a "tor+http" address. Debian has its own official onion addresses for its package repositories, along with onion addresses for many of its other sites and services — and they even use Donncha's OnionBalance tool to provide redundancy and scaling. (Also, since the nice person who helps run Debian's infrastructure also helps to run our infrastructure, that means we now have onion addresses for many of Tor's sites and services too!)
You can configure your Debian system to update via Tor by following the directions at the bottom of the Debian blog post. A growing number of privacy-oriented Debian derivatives, including Tails, use apt-transport-tor as their default way of doing updates, and we think that's a great and important trend.
We’ve been speaking to journalists who are curious about a HotPETS 2016 talk from last week: the HOnions: Towards Detection and Identification of Misbehaving Tor HSDirs research paper conducted by our colleagues at Northeastern University. Here's a short explanation, written by Donncha and Roger.
Internally, Tor has a system for identifying bad relays. When we find a bad relay, we throw it out of the network.
But our techniques for finding bad relays aren't perfect, so it's good that there are other researchers also working on this problem. Acting independently, we had already detected and removed many of the suspicious relays that these researchers have found.
The researchers have sent us a list of the other relays that they found, and we're currently working on confirming that they are bad. (This is tougher than it sounds, since the technique used by the other research group only detects that relays *might* be bad, so we don't know which ones to blame for sure.)
It's especially great to have this other research group working on this topic, since their technique for detecting bad relays is different from our technique, and that means better coverage.
As far as we can tell, the misbehaving relays' goal in this case is just to discover onion addresses that they wouldn't be able to learn other ways—they aren't able to identify the IP addresses of hosts or visitors to Tor hidden services.
The authors here are not trying to discover new onion addresses. They are trying to detect other people who are learning about onion addresses by running bad HSDirs/relays.
This activity only allows attackers to discover new onion addresses. It does not impact the anonymity of hidden services or hidden service clients.
We have known about and been defending against this situation for quite some time. The issue will be resolved more thoroughly with the next-generation hidden services design. Check out our blog post, Mission: Montreal!
Journalists have been asking us for our thoughts about a recent pdf about a judge deciding that a defendant shouldn't get any more details about how the prosecutors decided to prosecute him. Here is the statement we wrote for them:
"We read with dismay the Western Washington District Court's Order on Defendant's Motion to Compel issued on February 23, 2016, in U.S. v. Farrell. The Court held "Tor users clearly lack a reasonable expectation of privacy in their IP addresses while using the Tor network." It is clear that the court does not understand how the Tor network works. The entire purpose of the network is to enable users to communicate privately and securely. While it is true that users "disclose information, including their IP addresses, to unknown individuals running Tor nodes," that information gets stripped from messages as they pass through Tor's private network pathways.
This separation of identity from routing is key to why the court needs to consider how exactly the attackers got this person's IP address. The problem is not simply that the attackers learned the user's IP address. The problem is that they appear to have also intercepted and tampered with the user's traffic elsewhere in the network, at a point where the traffic does not identify the user. They needed to attack both places in order to link the user to his destination. This separation is how Tor provides anonymity, and it is why the previous cases about IP addresses do not apply here.
The Tor network is secure and has only rarely been compromised. The Software Engineering Institute ("SEI") of Carnegie Mellon University (CMU) compromised the network in early 2014 by operating relays and tampering with user traffic. That vulnerability, like all other vulnerabilities, was patched as soon as we learned about it. The Tor network remains the best way for users to protect their privacy and security when communicating online."
Tor's annual revenue in 2014 held steady at about $2.5 million. Tor's budget is modest considering the number of people involved and the impact we have. And it is dwarfed by the budgets that our adversaries are spending to make the world a more dangerous and less free place.
To achieve our goals, which include scaling our user base, we fund about 20 contractors and staff members (some part time, some full time) and rely on thousands of volunteers to do everything from systems administration to outreach. Our relay operators are also volunteers, and in 2014 we grew their number to almost 7,000 — helped along by the Electronic Frontier Foundation's wonderful Tor Challenge, which netted 1,635 relays. Our user base is up to several million people each day.
Transparency doesn't just mean that we show you our source code (though of course we do). The second layer to transparency is publishing specifications to explain what we thought we implemented in the source code. And the layer above that is publishing design documents and research papers to explain why we chose to build it that way, including analyzing the security implications and the tradeoffs of alternate designs. The reason for all these layers is to help people evaluate every level of our system: whether we chose the right design, whether we turned that design into a concrete plan that will keep people safe, and whether we correctly implemented this plan. Tor gets a huge amount of analysis and attention from professors and university research groups down to individual programmers around the world, and this consistent peer review is one of our core strengths over the past decade.
As we look toward the future, we are grateful for our institutional funding, but we want to expand and diversify our funding too. The recent donations campaign is a great example of our vision for future fundraising. We are excited about the future, and we invite you to join us: donate, volunteer, and run a Tor relay.
At long last, I am thrilled to announce that our executive director search is now successful! And what a success it is: we have our good friend Shari Steele, who led EFF for 15 years, coming on board to lead us.
We've known Shari for a long time. She led EFF's choice to fund Tor back in 2004-2005. She is also the one who helped create EFF's technology department, which has brought us HTTPS Everywhere and their various guides and tool assessments.
Tor's technical side is world-class, and I am excited that Shari will help Tor's organizational side become great too. She shares our core values, she brings leadership in managing and coordinating people, she has huge experience in growing a key non-profit in our space, and her work pioneering EFF's community-based funding model will be especially valuable as we continue our campaign to diversify our funding sources.
Tor is part of a larger family of civil liberties organizations, and this move makes it clear that Tor is a main figure in that family. Nick and I will focus short-term on shepherding a smooth transition out of our "interim" roles, and after that we are excited to get back to our old roles actually doing technical work. I'll let Shari pick up the conversation from here, in her upcoming blog post.
Please everybody join me in welcoming Shari!