Version 50 (modified by harmony, 6 years ago) (diff)

some other fixes

59th issue of Tor Weekly News. Covering what's happening from August 12th, 2014 to August 19th, 2014. To be released on August 20th, 2014.

Editor: harmony

Subject: Tor Weekly News — August 20th, 2014

Status: Frozen. Only technical and language fixes are welcome. New items should go in next week's edition

Tor Weekly News                                        August 20th, 2014

Welcome to the thirty-third issue of Tor Weekly News in 2014, the weekly
newsletter that covers what is happening in the community around Tor,
the anonymity network preferred by Aphex Twin [1].


Tor Browser 3.6.4 and 4.0-alpha-1 are out

Erinn Clark took to the Tor Blog [2] to announce two new releases by the
Tor Browser team. The stable version (3.6.4) contains fixes for several
new OpenSSL bugs, although since Tor should only be vulnerable to one of
them, and “as this issue is only a DoS”, it is not considered a critical
security update. This release also brings Tor Browser users the fixes
that give log warnings about the RELAY_EARLY traffic confirmation attack
explained last month [3]. Please be sure to upgrade as soon as possible.

Alongside this stable release, the first alpha version of Tor Browser
4.0 is now available. Among the most exciting new features of this
series is the inclusion of the meek [4] pluggable transport. In contrast
to the bridge-based transports already available in Tor Browser, meek
relies on a principle of “too big to block”, as its creator David
Fifield explained: “instead of going through a bridge with a secret
address, you go through a known domain ( for example) that
the censor will be reluctant to block. You don’t need to look up any
bridge addresses before you get started” [5]. meek currently supports
two “front domains”, Google and Amazon Web Services; it may therefore be
especially useful for users behind extremely restrictive national or
local firewalls. David posted a fuller explanation of meek, and how to
configure it, in a separate blog post [6].

This alpha release also “paves the way to [the] upcoming autoupdater by
reorganizing the directory structure of the browser”, as Erinn wrote.
This means that users upgrading from any previous Tor Browser series
cannot extract the new version over their existing Tor Browser folder,
or it will not work.

You can consult the full list of changes and bugfixes for both versions
in Erinn’s post, and download the new releases themselves from the Tor
website [7].


The Tor network no longer supports designating relays by name

Since the very first versions of Tor [8], relay operators have been able
to specify “nicknames” for their relays. Such nicknames were initially
meant to be unique across the network, and operators of directory
authorities would manually “bind” a relay identity key after verifying
the nickname. The process became formalized with the “Named” flag
introduced in the 0.1.1 series [9], and later automated with the 0.2.0
series. If a relay held a unique nickname for long enough, the authority
would recognize the binding, and subsequently reserve the name for half
a year.

Nicknames are useful because it appears humans are not very good at
thinking using long strings of random bits. Initially, they made it
possible to understand what was happening in the network more easily,
and to designate a specific relay in an abbreviated way. Having two
relays in the network with the same nickname is not really problematic
when one is looking at nodes, or a list in Globe [10], as relays can
always be differentiated by their IP addresses or identity keys.

But complications arise when nicknames are used to specify one relay to
the exclusion of another. If the wrong relay gets selected, it can
become a security risk. Even though real efforts [11] have been made to
improve the situation, properly enforcing uniqueness has always been
problematic, and a burden for the few directory authorities that handle

Back in April, the “Heartbleed” bug [12] forced many relays to switch to
a new identity key, thus losing their “Named” flag. Because this meant
that anyone designating relays by their nickname would now have a hard
time continuing to do so, Sebastian Hahn decided to use the opportunity
to get rid of the idea entirely [13].

This week, Sebastian wrote [14]: “Code review down to 0.2.3.x has shown
that the naming-related code hasn’t changed much at all, and no issues
were found which would mean a Named-flag free consensus would cause any
problems. gabelmoo and tor26 have stopped acting as Naming Directory
Authorities, and — pending any issues — will stay that way.”

This means that although you can still give your relay a nickname in its
configuration file, designating relays by nickname for any other purpose
(such as telling Tor to avoid using certain nodes) has now stopped
working.  “If you — in your Tor configuration file — refer to any relay
by name and not by identity hash, please change that immediately. Future
versions of Tor will not support using names in the configuration at
all”, warns Sebastian [15].


Miscellaneous news

meejah announced [16] the release of version 0.11.0 of txtorcon, a
Twisted-based Python controller library for Tor. This release brings
several API improvements; see meejah’s message for full release notes
and instructions on how to download it.


Mike Perry posted an overview [17] of a recent report put together by
iSEC Partners and commissioned by the Open Technology Fund to explore
“current and future hardening options for the Tor Browser”. Among other
things, Mike’s post addresses the report’s immediate hardening
recommendations, latest thoughts on the proposed Tor Browser “security
slider”, and longer-term security development measures, as well as ways
in which the development of Google Chrome could inform Tor Browser’s own
security engineering.


Nick Mathewson asked for comments [18] on Trunnel, “a little tool to
automatically generate binary encoding and parsing code based on C-like
structure descriptions” intended to prevent “Heartbleed”-style
vulnerabilities from creeping into Tor’s binary-parsing code in C. “My
open questions are: Is this a good idea? Is it a good idea to use this
in Tor? Are there any tricky bugs left in the generated code? What am I
forgetting to think of?”, wrote Nick.


George Kadianakis followed up his journey to the core [19] of what Tor
does when trying to connect to entry guards in the absence of a network
connection with another post [20] running through some possible
improvements to Tor’s behavior in these situations: “I’m looking forward
to some feedback on the proposed algorithms as well as improvements and


Arturo Filastò requested feedback [21] on some proposed changes to the
format of the “test deck” used by ooni-probe, the main project of the
Open Observatory of Network Interference. “A test deck is basically a
way of telling it ‘Run this list of OONI tests with these inputs and by
the way be sure you also set these options properly when doing so’…This
new format is supposed to overcome some of the limitations of the old
design and we hope that a major redesign will not be needed in the near
future”, wrote Arturo.


Tor’s importance to users who are at risk, for a variety of reasons,
makes it an attractive target for creators of malware, who distribute
fake or modified versions of Tor software for malicious purposes.
Following a recent report of a fake Tor Browser in circulation, Julien
Voisin carried out an investigation of the compromised software, and
posted a detailed analysis [22] of the results. To ensure you are
protected against this sort of attack, make sure you verify any Tor
software you download [23] before running it!


Arlo Breault submitted a status report for July [24].


As the annual Google Summer of Code season draws to a close, Tor’s GSoC
students are submitting their final reports. Israel Leiva reported on
the revamp of GetTor [25], Marc Juarez on the framework for website
fingerprinting countermeasures [26], Juha Nurmi on [27], Noah
Rahman on Stegotorus enhancement [28], Amogh Pradeep on
Orbot+Orfox [29], Daniel Martí on consensus diffs [30], Mikhail Belous
on the multicore tor daemon work [31], Zack Mullaly on the secure
ruleset updater for HTTPS Everywhere [32], and Quinn Jarrell on Fog, the
pluggable transport combiner [33].


Tor help desk roundup

The help desk has been asked if it is possible to set up an anonymous
blog using Tor. The Hyde project [34], developed by Karsten Loesing,
documents the step-by-step process of using Tor, Jekyll, and Nginx to
host an anonymous blog as a hidden service.


News from Tor StackExchange

The Tor StackExchange site is looking for another friendly and helpful
moderator [35]. Moderators need to take care of flagged items (spam,
me-too comments, etc.), and are liaisons between the community and
StackExchange’s community team. So, if you’re interested, have a look at
the theory of moderation [36] and post an answer to the question at the
Tor StackExchange Meta site.


Upcoming events

 Aug 20-22        | Roger @ USENIX Security Symposium ’14
                  | San Diego, California, USA
 Aug 20 13:30 UTC | little-t tor development meeting
                  | #tor-dev,
 Aug 22 15:00 UTC | OONI development meeting
                  | #ooni,
 Aug 25 18:00 UTC | Tor Browser online meeting
                  | #tor-dev,
 Sep 03 19:00 UTC | Tails contributors meeting
                  | #tails-dev, / h7gf2ha3hefoj5ls.onion

This issue of Tor Weekly News has been assembled by Lunar, harmony,
David Fifield, qbi, Matt Pagan, Sebastian Hahn, Ximin Luo, and dope457. 

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 [37], write down your
name and subscribe to the team mailing list [38] if you want to
get involved!