Welcome to the twenty-fourth issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor 0.2.6.9 is out

Nick Mathewson announced a new release in Tor’s current stable series. Version 0.2.6.9 stops relays without the Stable flag from serving as onion service directories, and raises the uptime requirement for the Stable flag itself, which means that any Sybil attacks launched against the network will not become effective for at least a week. This change only affects the Tor network’s nine directory authorities, most of whom have already upgraded.

The other significant fix in this release concerns port-based isolation of client requests, which now functions properly; if you make use of this feature in your standalone Tor client, then please upgrade as soon as possible. For other users, writes Nick, this “is not a high-urgency item”.

Tor Browser 4.5.2 and 5.0a2 are out

The Tor Browser team put out new stable and alpha releases of the privacy-preserving browser. As well as updates to key software components, versions 4.5.2 and 5.0a2 both contain fixes for the “Logjam” attack on TLS security - as Nick Mathewson wrote at the time of this vulnerability’s disclosure, the connections between Tor clients and relays were unlikely to have been affected by this attack, but the bug is now fixed in the browser component of Tor Browser as well.

These new releases also fix a possible crash in Linux, and stop the Add-ons page from breaking if Torbutton is disabled. The new alpha further improves meek’s compatibility with the automatic update process on Windows machines.

All users should upgrade their Tor Browser as soon as possible. Your browser might already have prompted you to do this — if not, you can always upgrade by downloading a fresh copy from the Tor website.

The future of GetTor and uncensorable software distribution

The GetTor service offers users who are unable to reach the Tor website an alternative method of downloading Tor Browser: any email sent to gettor@torproject.org will receive an automated reply containing links to file-hosting services (such as Dropbox) for the latest Tor Browser package and its signature.

Israel Leiva, lead developer on the revamped GetTor project since last year’s Google Summer of Code, is back for the first-ever Tor Summer of Privacy to continue expanding the feature set of this tool. As Israel wrote to the tor-dev mailing list, current plans for the summer include the addition of other file-hosting services, Tor Browser localizations, and other distribution methods (including instant messaging and Twitter).

However, it might also be time for a more radical change in the way GetTor works. An official distributor application or browser add-on, available through channels like the OS X or Google Chrome app stores, could automate Tor Browser downloads, as well as the vital but unintuitive process of verifying the signature to ensure the software has not been tampered with. Israel offered two suggestions for the inner workings of such a distributor: one involving a fixed (but potentially blockable) backend API with which the distributor communicates, and one in which a more complex distributor is capable of helping the user download the required software from several different sources.

Some related projects are already underway: the Tails team is discussing the possibility of its own browser add-on for ISO download and verification, while Griffin Boyce pointed to his own Satori project, a distributor application that offers torrent files and content-delivery network (CDN) links. The discussion over the possible GetTor distributor’s relationship with these projects is still to be had.

“I would really love to hear your comments about this idea, my work at Summer of Privacy might change depending on this discussion”, writes Israel. It’s clear that forcing users to depend on “single points of failure” for their software is bad news all round, so if you have worthwhile ideas to add to this discussion, feel free to take them to the tor-dev mailing list thread.

Great progress on Orfox browser

Nathan Freitas, of mobile device security specialists the Guardian Project, reported on the status of Orfox, the Android-compatible Tor Browser build. “The goal is to get as close to the ‘real Tor Browser’ while taking into account the new, unique issues we face on Android”, he wrote. Amogh Pradeep, former Google Summer of Code student and now intern at the Guardian Project, has made significant progress getting the software to build, and you can follow his regular updates on the Orfox development blog. “We expect to have an alpha out this week”, wrote Nathan, “but feel free to jump in on testing of the posted builds, and file bugs or feature requests as you find them”.

A persistent Tor state for Tails?

The Tails team is discussing the possibility of making Tor’s state persist across sessions in the anonymous live operating system. As the team writes on the relevant blueprint page, such a change would have several benefits: not only would Tor’s bootstrap process be faster and more efficient, but it would enable Tails to take advantage of the “entry guards” concept, without which Tails users are more likely to select a malicious entry node at some point over the course of their activity. Moreover, the fact that Tails selects a new entry node on every boot, while Tor Browser does not, allows an adversary to determine whether a user who remains on one network (their home or place of work, for example) is using Tails or not. This would also be solved by a persistent Tor state.

However, this change does of course have some drawbacks. For one thing, although entry guards in Tails would help defend against end-to-end correlation attacks, they enable a certain kind of fingerprinting: if a user makes a connection to an entry guard from their home, and an adversary later observes a connection to the same guard from an event or meeting-place that the user is suspected of attending, the adversary can draw a conclusion about the user’s geographical movement. This violates one of Tails’ threat model principles, which the team calls “AdvGoalTracking”. There are ways that Tails could request location information from the user in order to maintain different entry guards for different locations, but too many requests for information might bamboozle Tails users into accidentally worsening their own security, especially if they do not understand the threat model behind the requests, or it does not apply to them.

What is needed, then, is a balance between “defaults that suit the vast majority of use-cases […] for Tails’ target audience” and helping “users with different needs to avoid becoming less safe ‘thanks’ to this new feature”. The discussion continues on the tails-dev mailing list.

Miscellaneous news

Nick Mathewson recommended that all relay operators upgrade their copies of OpenSSL to fix several issues that could enable remote denial-of-service attacks. As Nick makes clear, this is an “upgrade when you can”-level announcement, rather than a “run in circles freaking out”. Nick also requests that people still using OpenSSL’s 0.9.8 series upgrade to one of the more recent versions, as 0.9.8 contains several security flaws and will not be supported by Tor 0.2.7.2-alpha or later.

Sherief Alaa reported on his activities in May.

This issue of Tor Weekly News has been assembled by Harmony.

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!