Blogs

Tor at the Heart: OnionShare

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!


By Micah Lee


In August 2013, David Miranda was detained for nine hours and searched at Heathrow Airport in London while he was trying to board a plane back home to Rio de Janeiro. Working on a journalism assignment for the Guardian, he was carrying an encrypted USB stick that contained classified government documents. When I first learned about this story, I knew there must be safer ways to move sensitive documents across the world than physically carrying them, one that didn’t involve putting individual people at risk from border agents and draconian “terrorism” laws that are used to stifle award-winning journalism.

Here’s how I would have done it: In Berlin (where the secret files originated), I would set up a local web server on my computer, that isn’t accessible from the internet. The only thing on the website would be a download link to an encrypted file that contained the secret documents. Then I would setup a Tor onion service -- one of the coolest and most under-appreciated technologies on the internet, in my opinion -- to make this simple website accessible from a special “.onion” domain name. I would send my colleague in Rio (in this case, Glenn Greenwald) the URL to the onion service. He would open it in Tor Browser and download the encrypted file. As soon as he finished the download, I would stop the local web server and remove the onion service, so it would no longer be on the internet at all.

Of course, the problem is that while this may be simple for seasoned nerds like myself, it’s not for many journalists, activists, or lawyers who run into similar problems on a regular basis. Inspired by this idea, I developed a simple and user-friendly open source tool called OnionShare that automates this process. You open OnionShare, drag some files into it, and click the “Start Sharing” button. After a moment, OnionShare gives you URL that looks something like http://4a7kqhcc7ko6a5rd.onion/logan-chopin. You send this URL to someone you’d like to share files with, and they load it using Tor Browser and download the files directly from the web server running on your computer. The moment the download is complete, OnionShare shuts down the web service, the URL no longer works, and the files you shared disappear from the internet. (Since OnionShare runs a server directly on your computer, this also means that your computer needs to be online for the URL to work -- if you suspend your laptop, for example, the URL won’t work until you get back online.)



Onionshare server side



Onionshare client side

I’m the developer of OnionShare, but I have no idea how many users it has. I consider this a feature. It’s completely decentralized, anonymous, and private. I don’t run a central service -- instead, every user runs their own short-lived service, often only for a few minutes, and that service disappears as soon as they finish sharing their files.

However, I do know that people use it. I use it on a regular basis myself while working on sensitive journalism projects with my colleagues at The Intercept. Sources use it to send me and other journalists documents. I’ve heard from digital security trainers that OnionShare is used by the Movement for Black Lives in the United States, and by activists in Latin America. A European human rights lawyer told me that their client in Africa used it to send them sensitive files.


What OnionShare protects against:

  • Third parties don't have access to files being shared. The files are hosted directly on the sender's computer and don't get uploaded to any server. Instead, the sender's computer becomes the server. Traditional ways of sending files, like in an email or using a cloud hosting service like Dropbox or Google Drive, require trusting the service with access to the files being shared.

  • Network eavesdroppers can't spy on files in transit. Because connections between Tor onion services and Tor Browser are end-to-end encrypted, no network attackers can eavesdrop on the shared files while the recipient is downloading them. If the eavesdropper is positioned on the sender's end, the recipient's end, or is a malicious Tor node, they will only see Tor encrypted traffic.

  • Anonymity of sender and recipient are protected by Tor. OnionShare and Tor Browser protect the anonymity of the users. As long as the sender anonymously communicates the OnionShare URL with the recipient, the recipient and eavesdroppers can't learn the identity of the sender.

  • If an attacker enumerates the onion service, the shared files remain safe. There have been attacks against the Tor network that can enumerate onion services. If someone discovers the .onion address of an OnionShare onion service, they still cannot download the shared files without knowing the full URL, and OnionShare has rate-limited to protect against attempts to guess the URL.



What OnionShare doesn't protect against:

  • Communicating the OnionShare URL might not be secure. The sender is responsible for securely communicating the OnionShare URL with the recipient. If they send it insecurely (such as through an email message, and their email is being monitored by an attacker), the eavesdropper will learn that they're sending files with OnionShare. If the attacker loads the URL in Tor Browser before the legitimate recipient gets to it, they can download the files being shared. If this risk fits the sender's threat model, they must find a more secure way to communicate the URL, such as in an encrypted email, chat, or voice call. This isn't necessary in cases where the files being shared aren't secret.

  • Communicating the OnionShare URL might not be anonymous. While OnionShare and Tor Browser allow for anonymously sending files, if the sender wishes to remain anonymous they must take extra steps to ensure this while communicating the OnionShare URL. For example, they might need to use Tor to create a new anonymous email or chat account, and only access it over Tor, to use for sharing the URL. This isn't necessary in cases where there's no need to protect anonymity, such as coworkers who know each other sharing work documents.



You can find the source code for OnionShare here, and you download it from its website here.

Tor at the Heart: OONI Highlights from 2016

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!

In this post we provide some highlights from OONI, a project under The Tor Project.

The Open Observatory of Network Interference (OONI) is a free software project under The Tor Project that aims to uncover internet censorship around the world. Recently we published an overview of OONI which can be found here.

Today we are providing some OONI highlights from 2016. These include our research findings in collaboration with our partners, and the new features we have developed and released to meet our users’ needs.

Research findings

As part of the OONI Partnership Program we collaborate with various local and international non-profit organizations around the world on the study of internet censorship. Below we provide some highlights from our research findings this year.

Censorship during elections

  • Uganda: Facebook and Twitter blocked during 2016 general elections. In collaboration with DefendDefenders we examined the blocking of social media in Uganda during its 2016 general elections and when the country’s President was inaugurated. View our findings here.
  • Zambia: Internet censorship events during 2016 general elections. OONI monitored internet censorship events during Zambia’s 2016 general election period in collaboration with Strathmore University’s Centre for Intellectual Property and Information Technology Law (CIPIT). A full report of our study can be found here.
  • The Gambia: Internet shutdown during 2016 presidential election. We attempted to examine whether websites were blocked during the Gambia’s 2016 presidential election. Instead, we came across a country-wide internet blackout. View our findings here.
  • Venezuela: Blocking of sites during elections. IPYS conducted a study of internet censorship in Venezuela through the use of ooniprobe. Their full report can be found here.

Censorship during other political events

  • Ethiopia: Deep Packet Inspection (DPI) technology used to block media websites during major political protests. OONI joined forces with Amnesty International to examine internet censorship events during Ethiopia’s wave of protests. We not only detected DPI filtering technology, but we also found numerous sites - including news outlets, torproject.org, LGBTI and human rights sites - to be tampered with. Now Ethiopia is in a state of emergency. Our report can be found here.
  • Turkey: Internet access disruptions during attempted military coup. In collaboration with RIPE Atlas we examined the throttling of social media in Turkey during the attempted military coup in July. View the findings here.
  • Ethiopia: Internet shutdown amidst political protests. Ethiopia’s government pulled the plug on the internet in the middle of heavy protests in August. We examined the internet shutdown in collaboration with Strathmore University’s Centre for Intellectual Property and Information Technology Law (CIPIT) and published our findings here.

Tor blocking

  • Egypt: Tor interference. Our community informed us that certain services were inaccessible in Egypt. We investigated the issue and also found Tor to be tampered with. View our findings here.
  • Belarus: Tor block. An anonymous cypherpunk helped us collect evidence of Tor blocking in Belarus. View the data here.

WhatsApp blocking and DNS censorship

  • Brazil: Blocking of WhatsApp. Thanks to Coding Rights who ran our newly developed WhatsApp test, we were able to detect and collect evidence of the blocking of WhatsApp in Brazil earlier this year. View the data here.
  • Malaysia: DNS blocking of news outlets, medium.com, and sites expressing political criticism. Following the 1MDB scandal, various news outlets were reportedly blocked in Malaysia. OONI joined forces with Sinar Project to examine and collect evidence of internet censorship events in Malaysia. Our report can be found here.

New releases

If you’ve known OONI for a while, you might be more familiar with ooniprobe as a command line tool. To meet our users’ needs, we developed a variety of features this year, including the following:

  • OONI Explorer: A global map to explore and interact with all of the network measurements that OONI has collected from 2012 to date.
  • Measurement API: Explore and analyze OONI’s data via its new API.
  • OONI web UI: Run censorship tests from your web browser!
  • WhatsApp & Facebook Messenger tests: Examine the reachability of WhatsApp and Facebook Messenger with OONI’s new tests!
  • Web Connectivity test: Examine DNS, TCP/IP, HTTP blocking of sites all in one test!
  • Lepidopter: Run ooniprobe from a Raspberry Pi!
  • OONI mobile: We have developed the beta version of ooniprobe for Android and iOS. Look out for ooniprobe’s mobile app in early 2017!

Over the last year, many non-profit organizations around the world have started running ooniprobe daily. The graph below illustrates the expansion of ooniprobe’s global coverage thanks to our users.


By supporting Tor, you’re also supporting the OONI project. Help us continue to increase transparency around internet censorship by donating to The Tor Project.

Written by Maria Xynou, OONI’s Research and Partnerships Coordinator.

Tor at the Heart: PETS and the Privacy Research Community

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 terms of publicity, but if you're a researcher and you can help us refine our process, please take a look!

Tor at the Heart: Online Collaborative Projects

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!

Research by Andrea Forte, Nazanin Andalibi and Rachel Greenstadt



Wikipedia blocks edits from Tor — how does this affect the quality and coverage of the "encyclopedia that anyone can edit?" How do captchas and blocking of anonymity services affect the experiences of Tor users when they are trying to contribute content? What can projects do to better support contributions from people who value their privacy?

We are a group of researchers from Drexel University studying these questions. Our initial study of privacy in open collaboration projects, entitled Privacy, Anonymity, and Perceived Risk in Open Collaboration: A Study of Tor Users and Wikipedians, was recently published in advance of its presentation at the ACM conference on Computer-Supported Cooperative Work and Social Computing (CSCW) in February. Our findings offer a rare look at why people turn to privacy tools like Tor and how they experience the Internet as a result. This work was inspired by a previous Tor blog post, A call to arms: Helping Internet services accept anonymous users.

We interviewed 23 people from seven countries ranging in age from 18-41; 12 Tor users who participate in online projects and 11 Wikipedia editors who use a variety of privacy tactics. The Tor Project and Wikimedia Foundation are organizations committed to similar ideals — a free global exchange of information in which everyone is able to participate. The study's central finding is that perceived threats from other individuals, groups of people and governments are substantial enough to force users below the radar and curtail their participation in order to protect their reputation, themselves, and their families.

In nearly all interviews, participants described being wary about how aspects of their participation in open collaboration projects would compromise their privacy or safety. Many participants described crisis experiences of their own or of someone they knew as antecedent to their model of threat in online projects.

Their reasons for guarding their privacy online ranged from concerns about providers obtaining and using their browsing history for targeted advertising to actual verbal abuse, harassment and threats of violence. The most common concern voiced by participants was a fear that their online communication or activities may be accessed or logged by parties without their knowledge or consent.

This threat, which became very real for many Americans after Snowden revealed the extent of the National Security Agency's surveillance and monitoring practices, has been ever-present for users in other countries for some time. According to one non-U.S. respondent "in my country there's basically unknown surveillance going on ... and I don't know what providers to use so at some point I decided to use Tor for everything."

For a political activist, dissident, or just someone who has expressed strong political opinions the threat is multiplied. One such participant who uses Tor said "they busted [my friend's] door down and they beat the ever living crap out of him...and told him, "If you and your family want to live, then you're going to stop causing trouble." This person's privacy strategies were quickly transformed after that experience.

Eleven of the study's participants were recruited from the ranks of Wikipedia editors who expressed concerns about maintaining their privacy. In comparison to political dissent, helping to add information to Wikipedia might seem innocuous, but especially editors who work on controversial topics are also being threatened and harassed. Wikipedia allows anonymous posting, but it does not permit users to mask their IP addresses and blocks Tor users — except in special cases. So wading into the controversial territory, even to present a fact-backed, neutral point of view, puts editors at risk. Some Wikipedians described threats of rape, physical assault, and death as reprisals for their contributions to the project.

Administrators of the site, who often spend their time on managerial tasks and enforcing policies, also reported being harassed or threatened with violence. "It's a lot of emotional work," said one study participant. "I remember being like 13 and getting a lot of rape threats and death threats and that was when I was doing administrative work."

Our analysis suggests that Wikipedia and other collaborative projects are losing valuable contributions to privacy concerns. If certain voices are systematically dampened by the threat of harassment, intimidation, violence, or opportunity and reputation loss, projects like Wikipedia cannot hope to attract the diversity of contributors required to produce "the sum of all human knowledge."

In response to this problem, our research agenda aims to support communities like Wikipedia in developing tools and norms that value and welcome anonymous contributions.

For more:

Andrea Forte will be speaking at the next WikiResearch showcase which will be live-streamed this Wednesday 12/21 at 11:30am PT / 7:30pm UTC.

Read the paper: "Privacy, Anonymity, and Perceived Risk in Open Collaboration: A Study of Tor Users and Wikipedians"

Watch the video from the 32c2 talk: What is the value of anonymous communication?

Tor At The Heart: Cryptocurrencies

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!





The topic for today is electronic money. The blockchain is pretty hot right now! Bitcoin, dogecoin, ethereum, zcash you name it... Cryptocurencies have grown from e-toys to globally recognized systems by facilitating free and borderless trade, no bank fees and improved privacy.

You are reading the Tor blog, so let's focus on the privacy and anonymity part. Could cryptocurrencies claim that they provide privacy if Tor was not around to give strong transport-layer anonymity?

To visualize this, let's go through just a few ways Tor is used around the cryptocurrency ecosystem. We will mainly focus on Bitcoin, but the same applies to most blockchain-based cryptocurrencies:

Tor provides privacy to cryptocurrency transactions!

Let's imagine that Alice wants to buy a ticket for Torconf, the best (fictional) conference on computer anonymity. She wants to buy the ticket with Bitcoin so that she does not reveal her interests to her bank or her identity to the conference organizers. To buy the ticket with Bitcoin, she needs to perform a Bitcoin transaction.

Bitcoin transactions work by Alice broadcasting her transaction to a few Bitcoin supernodes. Those nodes then propagate the transaction further to the rest of the Bitcoin network until it becomes recognized. If Alice did not use Tor to conduct her transaction, those initial supernodes trivially learn the IP address of Alice. Furthermore, since the Bitcoin blockchain is a public log of transactions, analysts could match her newest transaction with her previous transactions and just follow the money trail. These are just some of the many well known privacy risks of Bitcoin, and companies have been collecting and selling social graph analytics of the Bitcoin blockchain for years now...

Given the above threats, it should be no surprise that most Bitcoin clients give the option to their users to perform transactions over the Tor network. By routing traffic over Tor, no one learns the origin IP address of Alice when she buys her Torconf ticket.

Furthermore, even the hottest and newest cryptocurrencies (like Zcash) that provide transaction anonymity as a fundamental security property still benefit from Tor's transport-layer anonymity to actually anonymize the networking part of the Zcash transaction.

We feel that Tor has tremendously helped the cryptocurrency community to grow just by providing transport-layer anonymity to transactions! Also, please remember that maintaining anonymity is not an easy task, so always be up-to-date on the latest security news depending on your threat model.

Tor secures cryptocurrency networks!

Apart from users performing anonymous Bitcoin transactions, the Bitcoin network itself uses Tor to increase its defenses. Since last year, the Bitcoin core project has integrated Tor onion services to their core network daemon. If Tor is installed in the system, Bitcoin will automatically create an onion service and act as a Bitcoin node over Tor to avoid leaking the real IP address of the node. This provides greater network resilience and protection against targeted attacks to Bitcoin nodes. You can see that there are hundreds of Tor bitcoin nodes. Zcash and other cryptocurrencies have followed the same path.

Furthermore, many mining pools advertise onion service support for their miners. Bitcoin infrastructure has been a target of hackers for a while, and virgin blocks are more and more valuable, so having anonymity as a miner is a desirable security property.

Tor protects the wider cryptocurrency ecosystem!

If you take a look around the Bitcoin world, you will notice that Tor support is advertised by all sorts of websites and services! Most bitcoin-related websites have onion sites that people can visit over Tor: for example, blockchain.info has been running a popular Tor onion service for its users. Most Bitcoin tumbler services also work over Tor onion services. Same goes for websites and forums offering help with Bitcoin. This is obviously done because the Bitcoin community has a great appreciation and need for privacy.

Tor is proud to have helped the cryptocurrency community grow over the years. We believe that electronic currencies can be a powerful tool for social change, but also a great scientific research area with results that can benefit other areas, like secure electronic voting, consensus algorithms, append-only data structures and secure name systems.

Help Tor grow the cypherpunk ecosystem by donating today!! We also accept Bitcoin!

Have a good day :)

What's new in Tor 0.2.9.8?

Today, we've released the first stable version of the 0.2.9.x series, bringing exciting new features to Tor. The series has seen 1406 commits from 32 different contributors. Please, see the ChangeLog for more details about what has been done.

This post will outline three features (among many other things) that we are quite proud of and want to describe in more detail.

Single Onion Service

Over the past several years, we've collaborated with many large scale service providers such as Facebook and Riseup, organizations that deployed Onion Services to improve their performance.

Onion services are great because they offer both anonymity on the service and the client side. However, there are cases where the onion service does not require anonymity. The main example of this is when the service provider does not need to hide the location of its servers.

As a reminder to the reader, an onion service connection between a client and a service goes through 6 hops, while a regular connection with Tor is 3 hops. Onion services are much slower than regular Tor connections because of this.

Today, we are introducing Single Onion Services! With this new feature, a service can now specify in its configuration file that it does not need anonymity, thus cutting the 3 hops between the service and its Rendezvous Point and speeding up the connection.

For security reasons, if this option is enabled, only single onion service can be configured. They can't coexist with a regular onion service. Because this removes the anonymity aspect of the service, we took extra precautions so that it's very difficult to enable a single onion by mistake. In your torrc file, here is how you do it:


HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1


Please read about these options before you enable them in the manual page.

Shared Randomness

We've talked about this before but now it is a reality. At midnight UTC every day, directory authorities collectively generate a global random value that cannot be predicted in advance. This daily fresh random value is the foundation of our next generation onion service work coming soon to a Tor near you.

In the consensus file, they will look like this; if all goes well, at 00:00 UTC, consensus will have a new one:


shared-rand-current-value Hq+hGlzwAVetJ2zkO70riH/SEMNri+c7Ps8xERZ3a0o=
shared-rand-previous-value CY5TncVAltDpkBKZUBYT1canvqmVoNuweiKVZIilHfs=


Thanks to atagar, the Stem Library version 1.5.0 supports parsing the shared random values from the consensus. See here for more information!

Voluntarily, we haven't exposed those values to the control port yet and will wait for a full stable release cycle in order to make sure it's stable enough for a third party application to use them (https://trac.torproject.org/19925).

Mandatory ntor handshake

This is another important security feature introduced in the new release. Authorities, relays and clients now require ntor keys in all descriptors, for all hops, for all circuits, and for all other roles.

In other words, except for onion services (and this will be addressed with the next generation), only ntor is used--now finally dropping the TAP handshake.

This results in better security for the overall network and users.


Enjoy this new release!

Tor 0.3.0.1-alpha: A new alpha series begins

Now that Tor 0.2.9.8 is stable, it's time to release a new alpha series for testing and bug-hunting!

Tor 0.3.0.1-alpha is the first alpha release in the 0.3.0 development series. It strengthens Tor's link and circuit handshakes by identifying relays by their Ed25519 keys, improves the algorithm that clients use to choose and maintain their list of guards, and includes additional backend support for the next-generation hidden service design. It also contains numerous other small features and improvements to security, correctness, and performance.

You can download the source from the usual place on the website. Packages should be available over the next weeks, including an alpha TorBrowser release some time in January.

Please note: This is an alpha release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Below are the changes since 0.2.9.8.

Changes in version 0.3.0.1-alpha - 2016-12-19

  • Major features (guard selection algorithm):
    • Tor's guard selection algorithm has been redesigned from the ground up, to better support unreliable networks and restrictive sets of entry nodes, and to better resist guard-capture attacks by hostile local networks. Implements proposal 271; closes ticket 19877.
  • Major features (next-generation hidden services):
    • Relays can now handle v3 ESTABLISH_INTRO cells as specified by prop224 aka "Next Generation Hidden Services". Service and clients don't use this functionality yet. Closes ticket 19043. Based on initial code by Alec Heifetz.
    • Relays now support the HSDir version 3 protocol, so that they can can store and serve v3 descriptors. This is part of the next- generation onion service work detailled in proposal 224. Closes ticket 17238.
  • Major features (protocol, ed25519 identity keys):
    • Relays now use Ed25519 to prove their Ed25519 identities and to one another, and to clients. This algorithm is faster and more secure than the RSA-based handshake we've been doing until now. Implements the second big part of proposal 220; Closes ticket 15055.
    • Clients now support including Ed25519 identity keys in the EXTEND2 cells they generate. By default, this is controlled by a consensus parameter, currently disabled. You can turn this feature on for testing by setting ExtendByEd25519ID in your configuration. This might make your traffic appear different than the traffic generated by other users, however. Implements part of ticket 15056; part of proposal 220.
    • Relays now understand requests to extend to other relays by their Ed25519 identity keys. When an Ed25519 identity key is included in an EXTEND2 cell, the relay will only extend the circuit if the other relay can prove ownership of that identity. Implements part of ticket 15056; part of proposal 220.

  read more »

Tor 0.2.9.8 is released: finally, a new stable series!

Tor 0.2.9.8 is the first stable release of the Tor 0.2.9 series.

The Tor 0.2.9 series makes mandatory a number of security features that were formerly optional. It includes support for a new shared- randomness protocol that will form the basis for next generation hidden services, includes a single-hop hidden service mode for optimizing .onion services that don't actually want to be hidden, tries harder not to overload the directory authorities with excessive downloads, and supports a better protocol versioning scheme for improved compatibility with other implementations of the Tor protocol.

And of course, there are numerous other bugfixes and improvements.

This release also includes a fix for a medium-severity issue (bug 21018 below) where Tor clients could crash when attempting to visit a hostile hidden service. Clients are recommended to upgrade as packages become available for their systems.

You can download the source code from the usual place on the website. Packages should be up within the next few days, with a
TorBrowser release planned for early January.

Below are listed the changes since Tor 0.2.8.11. For a list of changes since 0.2.9.7-rc, see the ChangeLog file.

Changes in version 0.2.9.8 - 2016-12-19

  • New system requirements:
    • When building with OpenSSL, Tor now requires version 1.0.1 or later. OpenSSL 1.0.0 and earlier are no longer supported by the OpenSSL team, and should not be used. Closes ticket 20303.
    • Tor now requires Libevent version 2.0.10-stable or later. Older versions of Libevent have less efficient backends for several platforms, and lack the DNS code that we use for our server-side DNS support. This implements ticket 19554.
    • Tor now requires zlib version 1.2 or later, for security, efficiency, and (eventually) gzip support. (Back when we started, zlib 1.1 and zlib 1.0 were still found in the wild. 1.2 was released in 2003. We recommend the latest version.)
  • Deprecated features:
    • A number of DNS-cache-related sub-options for client ports are now deprecated for security reasons, and may be removed in a future version of Tor. (We believe that client-side DNS caching is a bad idea for anonymity, and you should not turn it on.) The options are: CacheDNS, CacheIPv4DNS, CacheIPv6DNS, UseDNSCache, UseIPv4Cache, and UseIPv6Cache.
    • A number of options are deprecated for security reasons, and may be removed in a future version of Tor. The options are: AllowDotExit, AllowInvalidNodes, AllowSingleHopCircuits, AllowSingleHopExits, ClientDNSRejectInternalAddresses, CloseHSClientCircuitsImmediatelyOnTimeout, CloseHSServiceRendCircuitsImmediatelyOnTimeout, ExcludeSingleHopRelays, FastFirstHopPK, TLSECGroup, UseNTorHandshake, and WarnUnsafeSocks.
    • The *ListenAddress options are now deprecated as unnecessary: the corresponding *Port options should be used instead. These options may someday be removed. The affected options are: ControlListenAddress, DNSListenAddress, DirListenAddress, NATDListenAddress, ORListenAddress, SocksListenAddress, and TransListenAddress.

  read more »

Syndicate content Syndicate content