Tor Weekly News — June 25th, 2014
Tor 0.2.5.5-alpha is out
Tor 0.2.5.5-alpha was released, fixing “a wide variety of remaining issues in the Tor 0.2.5.x release series, including a couple of DoS issues, some performance regressions, a large number of bugs affecting the Linux seccomp2 sandbox code, and various other bugfixes”, in Nick Mathewson’s words. Among the major security improvements is an adjustment to the way Tor decides when to close TLS connections, which “should improve Tor’s resistance against some kinds of traffic analysis, and lower some overhead from needlessly closed connections”.
Debian Wheezy’s tor version to be updated
Following a suggestion by Peter Palfrader, Debian developers are preparing to update the version of tor found in the Debian stable repositories from 0.2.3.25 to 0.2.4.22. Among the chief motives for doing so is that “about a quarter of the Tor network (just considering the relays, not any clients), is on 0.2.3.25, presumably because they run Debian stable. If they all upgraded to the 0.2.4.x tree, the network as a whole would become a lot more secure as 0.2.4.x allows clients to use stronger crypto for connections built through these nodes.” Other benefits, including the various measures taken to defend against OpenSSL vulnerabilities discovered earlier this year, make this an attractive proposal.
The update will be shipped in the forthcoming point release (7.6) of Debian Wheezy, on July 12th.
Building on the May release of experimental Tor Browsers hardened with AddressSanitizer (ASan), Georg Koppen announced a new set of experimental Linux builds that include both AddressSanitizer and Undefined Behaviour Sanitizer (UBSan), asking for testing and feedback. See Georg’s message for download and build instructions, as well as a couple of known issues.
Nick Mathewson reminded Tor users, relay operators, and especially hidden service administrators that tor’s 0.2.2 series is no longer supported, and many features will soon stop working entirely; if you are affected, then please upgrade!
Several of Tor’s Google Summer of Code students submitted their regular progress reports: Daniel Martí on the implementation of consensus diffs, Mikhail Belous on the multicore tor daemon, Juha Nurmi on the ahmia.fi project, Zack Mullaly on the HTTPS Everywhere secure ruleset update mechanism, Amogh Pradeep on the Orbot+Orfox project, Sreenatha Bhatlapenumarthi on the Tor Weather rewrite, Marc Juarez on the link-padding pluggable transport development, Israel Leiva on the GetTor revamp, Quinn Jarrell on the pluggable transport combiner, Kostas Jakeliunas on the BridgeDB Twitter Distributor, and Noah Rahman on Stegotorus security enhancement.
Researchers from the Internet Geographies project at the Oxford Internet Institute produced a cartogram of Tor users by country, using archived data freely available from the Tor Project’s own Metrics portal, along with an analysis of the resulting image. “As ever more governments seek to control and censor online activities, users face a choice to either perform their connected activities in ways that adhere to official policies, or to use anonymity to bring about a freer and more open Internet”, they conclude.
fr33tux shared the slides for a French-language presentation on Tor, delivered at Université de technologie Belfort-Montbéliard. The source code (in the LaTeX markup language) is also available: “feel free to borrow whatever you want from it!”
A couple of weeks ago, Roger Dingledine wondered “how many relays are firewalling certain outbound ports (and thus messing with connectivity inside the Tor network)”. ra has just published the results of a three-week-long test of the interconnectivity between 6730 relays. Contacting the operators of problematic relays is probably the next step for those who wish to keep the network at its best.
George Kadianakis slipped on his storyteller costume to guide us through layers of the Tor core, motivated by the quest for knowledge. That accursed riddle, “Why does Roger have so many guards?”, now has an answer. Be prepared for a “beautiful stalagmite” and the “truly amazing” nature of Tor!
Tor help desk roundup
If the Tor Browser stalls while “loading the network status”, please double-check that the system clock is accurate; the same goes for the timezone and daylight saving time settings. Tor needs an accurate clock in order to prevent several classes of attacks on its protocol. It won’t work properly when the local time does not match the one used by other network participants.
Easy development tasks to get involved with
When the tor daemon is configured to open a SOCKS port on a public address, it warns about this possible configuration problem twice: once when it reads the configuration file, and a second time when it opens the listener. One warning should be enough. We had a friendly volunteer two years ago who sketched out possible fixes and even wrote a patch, but then concluded that his patch had a problem and went away. If you’re up to some digging into tor’s configuration file handling, and want to clean up a two-year-old patch potentially to be included in tor 0.2.6, please find the details in the ticket. It’s tagged as easy, so how hard can it be?
This issue of Tor Weekly News has been assembled by harmony, Lunar, Matt Pagan, Karsten Loesing, and Roger Dingledine.
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!