Tor Weekly News — April 16th, 2014
lunar at torproject.org
Wed Apr 16 12:35:49 UTC 2014
Tor Weekly News April 16th, 2014
Welcome to the fifteenth issue of Tor Weekly News in 2014, the weekly
newsletter that covers what is happening in the Tor community.
New beta version of Tor Browser 3.6
The second beta version of the next major Tor Browser release  is
out. Version 3.6 main highlight is the seamless integration of pluggable
transports  in the browser.
The update is important to users already using version 3.6-beta1 as it
contains an updated OpenSSL to address potential client-side vectors for
CVE-2014-0160  (also known as “Heartbleed”).
The new beta also features “a Turkish language bundle, experimental
a fix for improper update notification while extracting the bundle over
an already existing copy.”
Jump to the release announcement to know more. Enjoy the update  and
report any bug you may find.
Key rotation at every level
The “Heartbleed” issue forces system administrators to consider private
keys of network-facing applications affected by the bug as compromised.
As Tor has no shortage of private keys in its design , a serious
number of new keys has to be generated.
Roger Dingledine prompted  relay operators to get new identity keys,
“especially from the big relays, and we’ll be happier tolerating a
couple of bumpy days while the network recovers”. Switching to a new
relay identity key means that the relay is seen as new  to the
authorities again: they will lose their Guard status and bandwidth
measurement. It seems that a number of operators followed the advice, as
the network lost around 1 Gbit/s of advertised capacity between April
7th and April 10th .
For a brighter future if such massive RSA1024 relay key migration is
ever again in order, Nick Mathewson wrote proposal 230 . The proposal
describes a mechanism for relays to advertise their old identity to
directory authorities and clients.
Directory authorities can currently tie a relay’s nickname to its
identity key with the Named flag. That feature proved to be less helpful
than it seemed, and can subject its users to impersonation attacks. As
relays switch to new identity keys, those who keep the same name will
lose their Named flag for the next six months. So now seems  a good
time to “throw out the Named and Unnamed flags entirely”. Sebastian Hahn
acted on the idea and started a draft proposal .
How should potentially compromised relays which have not switched to a
new key be handled? On April 8th, grarpamp observed  that more than
3000 relays had been restarted — hopefully to use the fixed version of
OpenSSL. It is unknown how many of those relays have switched to a new
key since. Andrea Shepard has been working on a survey  to identify
them. What is known though are relays that are unfortunately still
vulnerable. Sina Rabbani has set up a visible list for guards and
exits . To protect Tor users, directory authority operators have
started to reject descriptors for vulnerable relays .
The identity keys for directory authorities are kept offline. But they
are used to certify medium-term signing keys. Roger Dingledine’s
analysis  reports “two (moria1 and urras) of the directory
authorities were unaffected by the openssl bug, and seven were
At the time of writing, five of the seven affected authorities had new
signing keys. In the meantime, Nick and Andrea have been busy writing
code to prevent the old keys from being accepted by Tor clients .
Changing the relay identity keys of the directory authorities has not
been done so far “because current clients expect them to be at their
current IP:port:fingerprint and would scream in their logs and refuse to
connect if the relay identity key changes”. The specification of the
missing piece of code to allow a smoother transition has been written by
Nick Mathewson in proposal 231 .
Finally, hidden service operators are also generating new keys .
Unfortunately, this forces every user of the service to update the
address in their bookmarks or configuration.
As Roger summarized it: “fun times”.
More monthly status reports for March 2014
The wave of regular monthly reports from Tor project members for the
month of March continued, with submissions from Andrew Lewman ,
Roger Dingledine , and Kelley Misata .
Roger also sent out the report for SponsorF , and the Tails team
reported on its progress .
CVE-2014-0160 prompted Anthony Basile to release version 20140409 
of Tor-ramdisk. OpenSSL has been updated and so has the kernel.
Upgrading is strongly recommended.
David Fifield released new browser bundles configured to use the
meek  transport automatically. These bundles “use a web browser
extension to make the HTTPS requests, so that the TLS layer looks like
Firefox” — because it is Firefox . Meek is a promising censorship
circumvention solution, so please try them!
The Tails developers announced  that Tchou’s proposal is the winner
of the recent Tails logo contest: “in the coming days we will keep on
fine-tuning it and integrating it in time for Tails 1.0. So don’t
hesitate to comment on it.”
Andrew Lewman reported on his week in Stockholm  for the Civil
Rights Defender’s  Defender’s Days where he trained activists and
“learned more about the situation in Moldova, Transnistria, Burma,
Vietnam, and Bahrain”.
Andrew also updated the instructions for mirror operators  wishing
to have their sites listed on the Tor Project website. Thanks to Andreas
Reich , Sebastian M. Bobrecki , and Jeremy L. Gaddis  for
running new mirrors!
Arlo Breault announced  the release of Bulb , a Tor relay web
status dashboard. “There’s not much to it yet, but I thought I’d
share […] Contributions welcome!”
Alan Shreve requested  feedback on “Shroud”, a proposal for “a new
system to provide public hidden services […] whose network location
cannot be determined (like Tor hidden services) but are accessible by
any client on the internet”.
Tor help desk roundup
Users often ask for steps they can take to maximize their anonymity
while using Tor. Tips for staying anonymous when using Tor are visible
on the download page .
News from Tor StackExchange
Jack Gundo uses Windows 7 with the built-in firewall and wants to block
all traffic except Tor traffic . Guest suggested that on a
closed-source system one can never be sure that all traffic really is
blocked, so the original poster might be better off using a router which
does the job. Another possible solution is PeerBlock, which also allows
you to block all traffic from a machine.
Broot uses obfs3 to route OpenVPN traffic and can’t get obfsproxy
running  because the latest version only implements SOCKS4. Yawning
Angel answered that version 0.2.7 of obfsproxy uses SOCKS5 and works
with OpenVPN. However there is a bug that needs to be worked
Apr 16 19:00 UTC | little-t tor development meeting
| #tor-dev, irc.oftc.net
Apr 18 18:00 UTC | Tor Browser online meeting
| #tor-dev, irc.oftc.net
This issue of Tor Weekly News has been assembled by Lunar, harmony,
Matt Pagan, qbi, Roger Dingledine, Karsten Loesing and the Tails team.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the tor-news