Tor Weekly News — May 22nd, 2015
harmony01 at riseup.net
Fri May 22 13:29:20 UTC 2015
Tor Weekly News May 22nd, 2015
Welcome to the twentieth issue in 2015 of Tor Weekly News, the weekly
newsletter that covers what’s happening in the aleatoric  Tor
1. Tor 0.2.6.8 is out
2. Tor Browser 4.5.1 and 5.0a1 are out
3. Fixing the Tor network’s bandwidth measurement system
4. Stopping onion service DoS attacks by limiting connections
5. What is the value of anonymous communication?
6. Miscellaneous news
7. This week in Tor history
8. Upcoming events
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
In addition to those fixes, Tor Browser 5.0a1  includes several new
privacy-preserving features. The automatic window-resizing feature from
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
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
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
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
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
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.
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
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
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.
May 22 16:00 UTC | SponsorO Tor Messenger/Tor Mail meeting
| #tor-project, irc.oftc.net
May 25 18:00 UTC | Tor Browser meeting
| #tor-dev, irc.oftc.net
May 25 18:00 UTC | OONI development meeting
| #ooni, irc.oftc.net
May 26 18:00 UTC | little-t tor patch workshop
| #tor-dev, irc.oftc.net
May 27 02:00 UTC | Pluggable transports/bridges meeting
| #tor-dev, irc.oftc.net
May 27 13:30 UTC | little-t tor development meeting
| #tor-dev, irc.oftc.net
Jun 03 19:00 UTC | Tails contributors meeting
| #tails-dev, irc.oftc.net
Jun 30 - Jul 02 | Many Tor people @ 15th Privacy Enhancing Technologies Symposium
| Philadelphia, USA
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
More information about the tor-news