Welcome to the twentieth issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the aleatoric Tor community.

Tor 0.2.6.8 is out

Nick Mathewson announced a new release in the current stable branch of the core Tor software. Tor 0.2.6.8 stops directory authorities from giving the HSDir flag to relays without a DirPort configured, which was causing accessibility problems for some hidden services. It also fixes a bug that could have allowed a Tor client to crash an onion service in a very small number of cases where the service was making use of Tor’s “client authorization” feature.

If you are running one of the Tor network’s nine directory authorities, you should upgrade as soon as possible. If you aren’t one of those people, no urgent action is required.

Tor Browser 4.5.1 and 5.0a1 are out

Mike Perry announced new releases by the Tor Browser team in both the stable and alpha series. Tor Browser 4.5.1 relaxes the “first-party isolation” system slightly, in order to solve some usability issues affecting websites that host their content on several subdomains. In addition, NoScript’s ClearClick anti-clickjacking feature is disabled, as it had been causing frequent false positives, especially on pages serving captchas.

In addition to those fixes, Tor Browser 5.0a1 includes several new privacy-preserving features. The automatic window-resizing feature from 4.5a4 is reintroduced here, and JavaScript’s ability to take precise timings of some activities has been limited, in order to defend against browser fingerprinting attacks.

See Mike’s announcements for full changelogs, download instructions, and advice on reporting any issues you experience. Both releases include important security updates to Firefox, so please upgrade as soon as you can!

Fixing the Tor network’s bandwidth measurement system

When a Tor relay is first set up, it performs a test to estimate its own ability to handle Tor traffic, and then reports this figure to the directory authorities — the so-called “advertised bandwidth”. In the earliest versions of the Tor network, the directory authorities used this advertised value directly when creating the consensus, even though the amount of bandwidth available to relays is sometimes greater or lesser than the reported figure. This led to poor balancing of the traffic load across the Tor network, and to the overwhelming impression that Tor is just “slow”.

In 2009, therefore, Mike Perry introduced the “bandwidth authority” (or “bwauth”) scripts as part of his TorFlow suite of tools. Computers that are configured to run as bwauths regularly scan the relays that make up the Tor network to see if the bandwidth they advertise corresponds to their real capacity. If not, the consensus will adjust the advertised bandwidth up or down to reflect the measurements taken by the bwauths; this adjusted value is the “consensus weight”, and clients using the consensus weight to select their Tor circuits experience much less of the lag that plagued the Tor network in its infancy.

At least, that’s how it should work. For some time, the bwauth scripts have been unmaintained, leading to problems for their operators, and more recently they appear to have broken in a way that is hard to diagnose. As nusenu pointed out, a significant number of Tor relays are now unmeasured, which means that some Tor relay operators are contributing bandwidth which the network is not using in the most efficient way.

In the short term, work is underway to patch up the bwauth scripts so that they can once again scan all the relays in the network: Tom Ritter announced that new bwauths have been brought online to provide the necessary measurements, and the scripts are being investigated to see if differences between consensuses are causing scanners to miss some relays.

A more permanent fix, however, might involve a total rewrite of the bwauth scripts if, as Roger Dingledine suggested, the design itself is flawed. Tor Project contributor Aaron Gibson will hopefully be addressing this issue as part of an upcoming fellowship with OTF, and a number of other research groups are also working towards a more robust design for the bandwidth measurement system.

Be sure to sign up to the tor-relays mailing list for further information. Thanks to all relay operators for their patience while the problem-solving continues!

Stopping onion service DoS attacks by limiting connections

George Kadianakis published an experimental workaround for onion services affected by a newly-discovered denial-of-service attack. “In this attack”, as George explained, “the adversary forces a hidden service to create thousands of connections to its underlying application (e.g. the webserver), which overwhelms both Tor and the underlying application”.

Onion service operators who want to test the fix will need to recompile their Tor from a special git branch, then configure the new settings in their torrc file to set an upper limit on the number of TCP connections a client can make. “Let us know if this works for you, by sending an email to this list, or commenting on the trac ticket. If it works for people, we might incorporate it in a Tor release soon”, wrote George.

What is the value of anonymous communication?

Researchers at Drexel University in Philadelphia are investigating the ways in which Tor users “write blog posts, edit Wikipedia articles, contribute to open source projects on GitHub, post on discussion forums, comment on news articles, Tweet, write reviews, and many other things” as part of their online activity, and whether or not they are inhibited by obstacles such as captchas, IP blacklists, or other blocking mechanisms, as Kate Krauss explained on the Tor blog.

According to Professor Rachael Greenstadt, one of the co-authors: “By understanding the contributions that Tor users make, we can help make a case for the value of anonymity online”.

One of the biggest threats to Tor’s success, as Roger Dingledine wrote last year, is the “siloing” of the Internet caused by the “growing number of websites [that] treat users from anonymity services differently”, so it’s more important than ever to demonstrate the many contributions to online projects made by Tor users. If you are a Tor user and don’t mind sharing your experiences of using Tor to communicate anonymously online, please see Kate’s post for more information on how to participate in the study.

Miscellaneous news

Damian Johnson put out a new release of Stem, the Tor controller library in Python. Stem 1.4 brings another increase in the speed of document parsing (now that descriptors are not validated by default), and includes support for Tor’s new “ephemeral onion service” and descriptor handling features. See Damian’s announcement for the full changelog.

Alec Muffett, the lead engineer behind Facebook’s onion service, contributed some notes on his experiences to a thread about serving the same site as both an onion service and a regular website.

Jesse Victors, one of the students participating in the first-ever Tor Summer of Privacy, explained in greater detail his proposal for “OnioNS”, a method of creating human-memorable yet secure addresses for onion services.

Colin C. sent out the Tor Help Desk report for April.

Thanks to Matt Hoover and spriver for running mirrors of the Tor Project website and software archive!

Micah Lee discovered a bug that is causing OnionShare, the onion service-based file-sharing application, to crash the entire Tor process when run using Tails.

Martin Florian discussed the problems caused by onion services that change their IP address during operation, such as those hosted on mobile devices. “Some logic needs to be included for forgetting about rendevouz points that have failed once…Am I on the right track? Is this a good idea? And how do I forget about RPs?”

This week in Tor history

A year ago this week, Anders Andersson wondered about the problems that Tor would face if the .onion top-level domain (TLD) were to be sold by ICANN for public registration, in the same way as the large number of new “generic” TLDs. This question had already been the subject of a submission to the Internet Engineering Task Force co-authored by the Tor Project’s Jacob Appelbaum, arguing that the .onion suffix should be one of several TLDs set aside for special use by peer-to-peer software.

This week, Jacob and Facebook’s Alec Muffett submitted another Internet-draft to the IETF, specifically requesting the registration of .onion as a special-use TLD now that it is in wide use. If it is approved, the .onion suffix will be reserved for use by Tor, ensuring that no conflicts arise later which might break the onion service naming system or enable attacks on users.

This issue of Tor Weekly News has been assembled by Harmony, Karsten Loesing, and Roger Dingledine.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!