Tor Weekly News — April 23rd, 2014

harmony harmony01 at
Wed Apr 23 12:04:03 UTC 2014

Tor Weekly News                                         April 23rd, 2014

Welcome to the sixteenth issue of Tor Weekly News in 2014, the weekly
newsletter that covers what is happening in the Tor community.

Cutting out relays running version 0.2.2.x

Tor relays running the now ancient Tor 0.2.2.x are scheduled to be
removed from the consensus [1]. The change has already been merged in
the master branch and will be out with the next Tor 0.2.5 alpha.

Even if most relay operators have been warned, the change has not yet
been widely announced. But as three directory authorities are already
not voting for the deprecated versions, the downtime of two others while
cleaning up after the OpenSSL “Heartbleed” issue was sufficient to get
these relays removed from the consensus [2] for a couple of days, as
Roger Dingledine explained [3].

Eventually relays running versions prior to might also be
removed from the consensus. “I think’s fix of #6033 makes
that one a plausible ’not below this one’ cutoff”, Roger writes in the
relevant Trac entry [4].

Relay operators should always make sure to run a recommended Tor
version [5]. The Tor Weather service [6] can be used by relay operators
to get email notifications if an outdated version is detected.


Miscellaneous news

Nathan Freitas announced [7] the third (and probably final) release
candidate for Orbot 13.0.6: “The big improvements in this build are a
fix for the disconnected UI/activity (Tor is on, but UI shows off), and
improvements to the transparent proxying iptables scripts”.


The Tails developers put out two calls for testing: the first [8] is for
the first release candidate of Tails 1.0; while the second [9] is for
UEFI support, which “allows you to start Tails using a USB stick on
recent hardware, and especially on Mac”. “Test wildly”, and report any
bugs you find!


Andrea Shepard sent [10] a list of 1777 fingerprints for relays “which
have ever turned up as potentially exposed by Heartbleed”. It appears
that enough directory authority operators now reject relays known to be
problematic [11]: sssheep reported [12] that the still-vulnerable
section of the network was down to 0.01% of the consensus weight.


Mick drew attention [13] to the fact that in its current state, arm [14]
— the command-line relay status monitor — wrongly advises relay
operators to run it with the same user as Tor, in order to access
information about the relay’s connections. This is in fact a very bad
idea, and a ticket [15] is already open to address this issue. Lunar
detailed [16] the correct method of doing this, which is also explained
in the ticket.


On the tor-relays mailing list, David Stainton mentioned [17] his Tor
role [18] for the Ansible [19] automation tool. David hoped that “relay
operators will find this useful for deploying and maintaining large
numbers of Tor relays and bridges”. The documentation specifies that it
currently works with Debian and Ubuntu systems, and contains several
configuration examples.


David Fifield continued his progress on meek [20], a pluggable transport
“that routes your traffic through a third-party web service in a way
that should be difficult to block”. David sent a call for wider
testing [21] of experimental Tor Browser builds and a call for reviews
of the code [22]. “There are a lot of components that make up the meek
transport […] This is your chance to get in on the ground floor of a
new transport!”


Ximin Luo raised [23] several points regarding how “indirect” pluggable
transports like flashproxy [24] or meek are currently handled by Tor.
Whereas obfs3 or ScrambleSuit connect directly to the specified peer,
transforming the data flow along the way, Ximin describes meek and
flashproxy as providing “the metaphor of connecting to a global
homogeneous service”.  The latter being “incompatible with the metaphor
of connecting to a specific endpoint”.  Solutions on how to make the
design, code, and configuration better are up for discussion.


Nicolas Vigier submitted his status report for March [25].


Philipp Winter relayed [26] the call for papers for the 4th USENIX
Workshop on Free and Open Communications on the Internet [27]. The
workshop will be held on August 18th, and should bring together the
wider community of researchers and practitioners interested in Tor and
other ways to study, detect, or circumvent censorship. Papers have to be
submitted before May 13th.


Fabio Pietrosanti wondered [28] whether anyone had “ever tried to start
Tor from a Python application using Ctypes”, making it possible to
“sandbox the Python application using AppArmor without enabling any kind
of execve() call”.


Tor help desk roundup

Many people email the Tor Help Desk from behind restrictive university
firewalls that require them to connect using a proxy. Often these
firewalls, Cyberoam and Fortiguard are two examples, use Deep Packet
Inspection and block Tor traffic. Unfortunately Tor Browser users can’t
use a proxy to connect to the internet and also use a pluggable
transport. The Tor Browser team plans to include this capability in a
future release [29].


Upcoming events

Apr 23 19:00 UTC | little-t tor development meeting
                 | #tor-dev,
Apr 25 17:00 UTC | Pluggable transports online meeting
                 | #tor-dev,
Apr 25 18:00 UTC | Tor Browser online meeting
                 | #tor-dev,

This issue of Tor Weekly News has been assembled by Lunar, harmony, Matt
Pagan, and an anonymous contributor.

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


More information about the tor-news mailing list