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 Javascript hardening options, fixes for pluggable transport issues, and 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 affected”.

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.

Miscellaneous news

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 around.

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 get involved!