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.”
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 0.2.7.5 is the first stable release in the Tor 0.2.7 series. It makes no changes beyond those in 0.2.7.4-rc; 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 0.2.7.5 - 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 0.2.4.8-alpha, 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".
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.