Archive

Tor Weekly News — March 26th, 2014

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

Tor 0.2.5.3-alpha is out

Nick Mathewson cut a new release of the Tor development branch on March 23rd: “Tor 0.2.5.3-alpha includes all the fixes from 0.2.4.21. It contains two new anti-DoS features for Tor relays, resolves a bug that kept SOCKS5 support for IPv6 from working, fixes several annoying usability issues for bridge users, and removes more old code for unused directory formats.”

This release also marks the first step toward the stabilization of Tor 0.2.5, as from now on “no feature patches not already written will be considered for inclusion”.

The source is available at the usual location, as are updated binary packages.

Tails 0.23 is out…

…but many Tails users are already running it. Now that incremental upgrades have been turned on by default with the previous release, users of Tails on USB sticks have been able to enjoy the process of a smooth upgrade in three clicks.

As always, the new release fixes several security holes. That alone should make anyone switch, but the new version finally brings with it two long-awaited features and many small improvements.

Tails will now do “MAC spoofing” by default. To hide the hardware address used on the local network, Tails will now use a randomized address by default. This will help prevent the tracking of one’s geographical location across networks. For more information about MAC spoofing, why it matters, and when it might be relevant to turn it off, be sure to read the very well-written documentation.

Another important feature is the integrated support for proxies and Tor bridges. This should be of immense help to users of Tails on censored networks. The integration is done using the Tor Launcher extension, familiar to everyone who has used recent versions of the Tor Browser.

For examples of smaller features and bugfixes: Tor, obfsproxy, I2P, Pidgin and the web browser have been upgraded, a 64-bit kernel is used on most systems to pave the way for UEFI support, documentation is now accessible from the greeter, and the “New identity” option in the browser is available again.

The next Tails release is scheduled for April 29th and will be 1.0. For this important milestone in 5 years of intense work, the Tails team is still looking for a logo.

New Tor Browser releases

The Tor Browser team put out two new releases based on Firefox 24.4.0esr. Version 3.5.3 is meant as a safe upgrade for every Tor Browser user. Among other changes, the new version contains an updated Tor, a fix for a potential freeze, a fix for the Ubuntu keyboard issue and a way to prevent disk leaks when watching videos.

On top of the preceding changes, version 3.6-beta-1 is the culmination of a months-long effort to seamlessly integrate pluggable transports into the Tor Browser. In the network settings, users can now choose “Connect with provided bridges” and select from “obfs3”, “fte” or “flashproxy”. Entering custom bridges is also supported and will work for direct, obfs2 and obfs3 bridges.

Other usability changes include wording improvements in the connection wizard, translatable Tor status messages, and the use of disk image (DMG) instead of ZIP archives for Mac OS X.

Please upgrade, in any case, and consider helping iron out the remaining issues in the 3.6 branch.

Miscellaneous news

Since the 3.5 release, “Tor Browser Bundle is more like a standalone browser and less like a bundle”. This led the Tor Browser team to plan to “rename it to just ‘Tor Browser’ everywhere”.

Thanks to Berkay and to André Schulz for running mirrors of the Tor Project website!

Alex reported an “important case about Tor relay operators” which came to court in Athens, Greece on March 18th. The defendant, a Tor relay operator, was acquitted after proving that the IP address used for criminal activity was in fact a Tor relay.

Connections to Twitter from inside Turkey were blocked by the Turkish government on 20th March, leading to an increase in the number of Tor users there.

Jacob Appelbaum presented a keynote titled “Free software for freedom, surveillance and you” at LibrePlanet 2014. The presentation was done remotely from Berlin using Tor and GStreamer.

James Valleroy wrote to tor-relays asking the best way to configure the FreedomBox as a Tor bridge. Lance Hathaway explained about pluggable transports and Roger Dingledine mentioned the potential issues of relaying a bridge and a hidden service at the same time.

Aymeric Vitte wrote to tor-talk to mention an implementation of the Tor protocol in JavaScript. Sadly, the project is not free software yet.

A Tor exit operator recently held an Ask Me Anything on Reddit, which was quite successful, generating over 800 upvotes, 478 comments, and being read by thousands. The most popular questions were focused on how to improve the use of Tor, the legality of exit nodes, discussions on hidden services, the workings of Tor, and many other topics related to privacy and security.

Tor help desk roundup

Users sometimes want to know how to transfer their bookmarks from an old Tor Browser to an updated one. Mozilla provide instructions on how to do this on their website.

The new Tor Browser releases were again prevented from working properly by WebRoot Internet Security. The error message is “Couldn’t load XPCOM”. Users need to disable WebRoot, whitelist the appropriate Tor Browser files, and more importantly contact WebRoot support to warn them that their product is breaking the Tor Browser and, to the best of Tor support’s knowledge, Firefox stable releases. Ideally, WebRoot should test new releases before harming Tor users. See #11268 if you want to help.

News from Tor StackExchange

uighur1984 wanted to set up a hidden service for their public-facing website and decided that the HiddenServiceDir should be the same like the DocumentRoot of the website. This led to some problems with access rights. Sam Whited clarified that both directories should be separated: the data in the HiddenServiceDir doesn't contain any actual data from the website, but only the keys and other information from the hidden service.

Gondalse shot a video showing policemen torturing a citizen. The release of the video led to a trial, and Gondalse fears that someone might try to track the owner of the video down. Jens Kubieziel pointed out some OPSEC rules, and showed which problems can lead to deanonymization.


This issue of Tor Weekly News has been assembled by Lunar, Matt Pagan, harmony, qbi, Jesse Victors, and Karsten Loesing.

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!

Tor Browser 3.5.3 is released

The 3.5.3 stable release of the Tor Browser Bundle is now available on the Download page. You can also download the bundles directly from the distribution directory.

This release also includes important security updates to Firefox.

As a reminder, this is the stable series of the Tor Browser Bundle. It does not include the Pluggable Transport support mentioned in the 3.6 release post, and in this release MacOS archives are still in zip format. If you would like those features, we encourage you to use 3.6-beta-1 instead, and report any issues you encounter.

Here is the complete changelog for 3.5.3:

  • All Platforms
    • Update Firefox to 24.4.0esr
    • Update Torbutton to 1.6.7.0:
      • Bug 9901: Fix browser freeze due to content type sniffing
      • Bug 10611: Add Swedish (sv) to extra locales to update
    • Update NoScript to 2.6.8.17
    • Update Tor to 0.2.4.21
    • Bug 10237: Disable the media cache to prevent disk leaks for videos
    • Bug 10703: Force the default charset to avoid locale fingerprinting
    • Bug 10104: Update gitian to fix LXC build issues (for non-KVM/VT builders)
  • Linux:
    • Bug 9353: Fix keyboard input on Ubuntu 13.10
    • Bug 9896: Provide debug symbols for Tor Browser binary
    • Bug 10472: Pass arguments to the browser from Linux startup script

A list of frequently encountered known issues with the Tor Browser can be found on our bugtracker. Please check that list and help us diagnose and arrive at solutions for those issues before contacting support.

Tails 0.23 is out

Tails, The Amnesic Incognito Live System, version 0.23, is out.

All users must upgrade as soon as possible: this release fixes numerous security issues.

Changes

Notable user-visible changes include:

  • Security fixes
    • Upgrade the web browser to 24.4.0esr-0+tails1~bpo60+1 (Firefox
      24.4.0esr + Iceweasel patches + Torbrowser patches).
  • Major new features
  • Bugfixes
    • Additional software: do not crash when persistence is disabled.
    • Upgrade Pidgin to 2.10.9, that fixes some regressions introduced in the 2.10.8 security update.
    • Wait for Tor to have fully bootstrapped, plus a bit more time, before checking for upgrades and unfixed known security issues.
    • Disable the Intel Management Engine Interface driver. We don't need it in Tails, it might be dangerous, and it causes bugs on various hardware such as systems that reboot when asked to shut down.
    • Add a launcher for the Tails documentation. This makes it available in Windows Camouflage mode.
    • Remove the obsolete wikileaks.de account from Pidgin.
  • Minor improvements
    • Upgrade Tor to 0.2.4.21-1~d60.squeeze+1.
    • Upgrade obfsproxy to 0.2.6-2~~squeeze+1.
    • Upgrade I2P to 0.9.11-1deb6u1.
    • Install 64-bit kernel instead of the 686-pae one. This is a necessary first step towards UEFI boot support.
    • Install Monkeysign (in a not-so-functional shape yet).
    • Disable the autologin text consoles. This was one of the blockers before a screen saver can be installed in a meaningful way.
    • Don't localize the text consoles anymore: it is broken on Wheezy, the intended users can as well use loadkeys, and we now do not have to trust setupcon to be safe for being run as root by the desktop user.
    • Make it possible to manually start IBus.
    • Reintroduce the possibility to switch identities in the Tor Browser, using a filtering proxy in front of the Tor ControlPort to avoid giving full control over Tor to the desktop user.
    • Incremental upgrades improvements:
      • Drop the Tails Upgrader launcher, to limit users' confusion.
      • Lock down sudo credentials a bit.
      • Hide debugging information.
      • Include ~/.xsession-errors in WhisperBack bug reports. This captures the Tails Upgrader errors and debugging information.
      • Report more precisely why an incremental upgrade cannot be done.
      • Various user interface and phrasing improvements.
    • Don't install the Cookie Monster browser extension.
    • Add a browser bookmark pointing to Tor's Stack Exchange.
    • Remove the preconfigured #tor channel from the Pidgin: apparently, too many Tails users go ask Tails questions there, without making it clear that they are running Tails, hence creating a user-support nightmare.
    • Use (most of) Tor Browser's mozconfig.
    • Rebase the browser on top of iceweasel 24.3.0esr-1, to get the certificate authorities added by Debian back.
    • Give access to the relevant documentation pages from Tails Greeter.
    • Hide Tails Greeter's password mismatch warning when entry is changed.
    • Persistent Volume Assistant:
      • Take into account our installer is now called Tails Installer.
      • Optimize window height.
      • Display device paths in a more user-friendly way.

See the online Changelog for technical details.

Known issues

I want to try it or to upgrade!

Go to the download page.

As no software is ever perfect, we maintain a list of problems that affects the last release of Tails.

What's coming up?

The next Tails release is scheduled for April 29.

Have a look to our roadmap to see where we are heading to.

Would you want to help? There are many ways you can contribute to Tails. If you want to help, come talk to us!

Support and feedback

For support and feedback, visit the Support section on the Tails website.

Tor Weekly News — March 19th, 2014

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

Accessing the Tor network from China

In a new blog post How to read our China usage graphs, Roger Dingledine looks at the current situation of how Tor is able to circumvent censorship on Chinese Internet accesses. Indeed, if one only looks at the current bridge users graph, one might believe that Tor is not a solution for users in China.

“The correct interpretation of the graph is ‘obfs3 bridges have not been deployed enough to keep up with the demand in China’. So it isn’t that Tor is blocked — it’s that we haven’t done much of a deployment for obfs3 bridges or ScrambleSuit bridges, which are the latest steps in the arms race” writes Roger.

The upcoming version — currently in QA phase — of the Tor Browser will include support for the pluggable transports obfs3, FTE and Flashproxy. Having these transports ready to be used in a couple of clicks should help Chinese users.

The “obfs3” protocol is still vulnerable to active probing attacks. The deployment of its replacement, ScrambleSuit, is on-going. As Roger highlighted, “we need to get more addresses”. Several ways have been thoughts in the past, but until there is more cooperation from ISP and network operators, your can make a difference by running a bridge if you can!

On another front, work is currently on-going on the bridge distributor to improve how censored users can get a hand on bridge addresses. Yawning Angel also just released the first version of obfsclient which should help making ScrambleSuit available on Android devices. All in all, the Tor community can hope to welcome back more users from China in a near future.

Circumventing censorship through “too-big-too-block” websites

Late January, David Fifield introduced a new pluggable transport called meek. It can be described as “a transport that uses HTTP for carrying bytes and TLS for obfuscation. Traffic is relayed through a third-party server (Google App Engine). It uses a trick to talk to the third party so that it looks like it is talking to an unblocked server.” The approach is close to the GoAgent proxy that has a certain popularity in China.

With the current version, using Google App Engine, the transport requires no additional configuration. But David also mentioned that a PHP script could also be a good candidate to relay the traffic. Combined to ScrambleSuit, it could allow “a real web site with real pages and everything” to be used as a bridge if a user can provide the shared secret.

David has made available experimental versions of the Tor Browser for anyone to try. The source code has recently moved to the Tor Project’s infrastructure, and is ready for more eyes and fingers to play with it.

Switching to a single guard node?

Last October, Roger Dingledine called for research on improving Tor’s anonymity by changing guard parameters . One of these parameters is the number of guard nodes used simultaneously by a Tor client.

Following up on the paper written by Tariq Elahi et al., Roger’s blog post, and recent discussions during the winter dev. meeting, George Kadianakis made a detailed analysis of the implications of switching to a single guard node . He studied the performance implications of switching to a single guard, the performance implications of raising the minimum guard bandwidth for both clients and the overall network, and how the change would affect the overall anonymity and fingerprintability of Tor users.

Jumping to conclusions: “It seems that the performance implications of switching to 1 guard are not terrible. […] A guard bandwidth threshold of 2MB/s […] seems like it would considerably improve client performance without screwing terribly with the security or the total performance of the network. The fingerprinting problem will be improved in some cases, but still remains unsolved for many of the users […] A proper solution might involve guard node buckets”.

For a better understanding, be sure to look at George’s work which includes graphs and proper explanations.

Miscellaneous news

George Kadianakis announced obfsproxy version 0.2.7. The new release fixes an important bug “where scramblesuit would basically reject clients if they try to connect a second time after a short amount of time has passed.” Bridge operators are strongly advised to upgrade from source, pip, or the upcoming Debian packages.

The submission deadline for this year’s Google Summer of Code is the 21st: this Friday. Several students already showed up on the tor-dev mailing list, but as Damian Johnson says: “If you’re procrastinating until the last minute then please don’t!”

Tails logo contest is happily on-going. Several submissions have already been received and can be seen on the relevant blueprint.

Kelley Misata and Karen Reilly attended the South by Southwest (SXSW) Interactive festival in Austin, Texas.

Relay and bridge operators might be interested in Ramo’s first release of a Tor plugin for Nagios. It can currently check for a page fetch through the SOCKS proxy port, the hibernation state, the current bandwidth, ORPort reachability, DirPort reachability, and the bytes remaining until hibernation.

Nicolas Vigier sent his monthly report for February.

Tails won the 2014 Endpoint Security prize from Access. The prize recognizes Tails “unique positive impact on the endpoint security of at-risk users in need”. Congrats!

The Format-Transforming Encryption project at Portland State University received an unexpected 100,000 USD grant from Eric Schmidt.

Tor help desk roundup

The help desk has seen an increase in Russian language support requests amidst news that the Russian Federation began censoring a number of websites. Unfortunately, the help desk is not able to provide support in Russian for now. Changes in the number of Tor users by country can be observed on the project’s metrics page.


This issue of Tor Weekly News has been assembled by Lunar, Matt Pagan and Karsten Loesing.

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!

Tor Browser 3.6-beta-1 is released

The Tor Browser team is proud to release the first beta in the 3.6 series. Packages are available from the Tor Browser Project page and also from our distribution directory.

This beta features fully integrated Pluggable Transport support, including an improved Tor Launcher UI for configuring Pluggable Transport bridges. The Pluggable Transport code is also fully disabled for users who do not configure them.

We believe that this approach will allow us to quickly turn 3.6 into a stable release, perhaps as soon as the next point release of TBB.

This release also changes the MacOS archive format from zip to DMG, which should improve installation usability for Mac users.

This release also includes important security updates to Firefox.

Please see the TBB FAQ listing for any issues you may have before contacting support or filing tickets. In particular, the TBB 3.x section lists common issues specific to the Tor Browser 3.x series.

Here is the complete changelog:

  • All Platforms

    • Update Firefox to 24.4.0esr
    • Include Pluggable Transports by default:
    • Obfsproxy3 0.2.4, Flashproxy 1.6, and FTE 0.2.6 are now included
    • Update Tor Launcher to 0.2.5.1
      • Bug 10418: Provide UI configuration for Pluggable Transports
      • Bug 10604: Allow Tor status & error messages to be translated
      • Bug 10894: Make bridge UI clear that helpdesk is a last resort for bridges
      • Bug 10610: Clarify wizard UI text describing obstacles/blocking
      • Bug 11074: Support Tails use case (XULRunner and optional customizations)
    • Update Torbutton to 1.6.7.0:
      • Bug 9901: Fix browser freeze due to content type sniffing
      • Bug 10611: Add Swedish (sv) to extra locales to update
    • Update NoScript to 2.6.8.17
    • Update Tor to 0.2.4.21
    • Backport Pending Tor Patches:
      • Bug 5018: Don't launch Pluggable Transport helpers if not in use
      • Bug 9229: Eliminate 60 second stall during bootstrap with some PTs
      • Bug 11069: Detect and report Pluggable Transport bootstrap failures
      • Bug 11156: Prevent spurious warning about missing pluggable transports
    • Bug 10237: Disable the media cache to prevent disk leaks for videos
    • Bug 10703: Force the default charset to avoid locale fingerprinting
    • Bug 10104: Update gitian to fix LXC build issues (for non-KVM/VT builders)
  • Mac:

    • Bug 4261: Use DMG instead of ZIP for Mac packages
  • Linux:

    • Bug 9353: Fix keyboard input on Ubuntu 13.10
    • Bug 9896: Provide debug symbols for Tor Browser binary
    • Bug 10472: Pass arguments to the browser from Linux startup script

A list of frequently encountered known issues with the Tor Browser can be found on our bugtracker. Please check that list and help us diagnose and arrive at solutions for those issues before contacting support.

How to read our China usage graphs

Recently somebody asked me why our usage numbers in China are so low. More precisely, his question was "How do I read this graph in any way other than 'Tor is effectively blocked in China'?" After writing up an answer for him, I realized I should share it with the rest of the Tor community too.

The correct interpretation of the graph is "obfs3 bridges have not been deployed enough to keep up with the demand in China". So it isn't that Tor is blocked — it's that we haven't done much of a deployment for obfs3 bridges or ScrambleSuit bridges, which are the latest steps in the arms race.

The short explanation is that the old vanilla SSL Tor transport doesn't work in China anymore due to their active probing infrastructure. The obfs2 transport doesn't work anymore either, for the same reason. The obfs3 transport works great for now, and thousands of people are happily using it — and some of those people aren't reflected in the graphs you see (I'll explain that more below).

The medium-length explanation is that we've been leading and coordinating the international research effort at understanding how to design and analyze transports that resist both DPI and active probing, and approximately none of these approaches have been deployed at a large scale yet. So it doesn't make sense to say that Tor is blocked in China, because it mischaracterizes Tor as a static protocol. "Tor" when it comes to censorship circumvention is a toolbox of options — some of them work in China, some don't. The ones that work (i.e. that should resist both DPI and active probing) haven't been rolled out very widely, in large part because we have funders who care about the research side but we have nobody who funds the operations, deployment, or scale-up side.

The long explanation is that it comes down to three issues:

First, there are some technical steps we haven't finished deploying in terms of collecting statistics about users of bridges + pluggable transports. The reason is that the server side of the pluggable transport needs to inform the Tor bridge what country the user was from, so the Tor bridge can include that in its (aggregated, anonymized) stats that it publishes to the metrics portal. We've now built most of the pieces, but most of the deployed bridges aren't running the new code yet. So the older bridges that are reporting their user statistics aren't seeing very many users from China, while the bridges that *aren't* reporting their user statistics, which are the ones that offer the newer pluggable transports, aren't well-represented in the graph. We have some nice volunteers looking into what fraction of deployed obfs3 bridges don't have this new 'extended ORPort' feature. But (and you might notice the trend here) we don't have any funders currently who care about counting bridge users in China.

Second, we need to get more addresses. One approach is to get them from volunteers who sign up their computer as a bridge. That provides great sustainability in terms of community involvement (we did a similar push for obfs2 bridges back when Iran was messing with SSL, and got enough to make a real difference at the time), but one address per volunteer doesn't scale very well. The intuition is that the primary resource that relays volunteer is bandwidth, whereas the primary resource that bridges volunteer is their address — and while bandwidth is an ongoing contribution, once your IP address gets blocked then your contribution has ended, at least for the country that blocked it, or until you get another address via DHCP, etc. The more scalable approaches to getting bridge addresses involve coordinating with ISPs and network operators, and/or designs like Flashproxy to make it really easy for users to sign up their address. I describe these ideas more in "approach four" and "approach five" of the Strategies for getting more bridge addresses blog post. But broad deployment of those approaches is again an operational thing, and we don't have any funded projects currently for doing it.

Third, we need ways of letting people learn about bridges and use them without getting them noticed. We used to think the arms race here was "how do you give out addresses such that the good guys can learn a few while the bad guys can't learn all of them", a la the bridges.torproject.org question. But it's increasingly clear that scanning resistance will be the name of the game in China: your transport has to not only blend in with many other flows (to drive up the number of scans they have to launch), but also when they connect to that endpoint and speak your protocol, your service needs to look unobjectionable there as well. Some combination of ScrambleSuit and FTE are great starts here, but it sure is a good thing that the research world has been working on so many prototype designs lately.

So where does that leave us? It would be neat to think about a broad deployment and operations plan here. I would want to do it in conjunction with some other groups, like Team Cymru on the technical platform side and some on-the-ground partner groups for distributing bridge addresses more effectively among social networks. We've made some good progress on the underlying technologies that would increase the success chances of such a deployment — though we've mostly been doing it using volunteers in our spare time on the side, so it's slower going than it could be. And several other groups (e.g. torservers.net) have recently gotten funding for deploying Tor bridges, so maybe we could combine well with them.

In any case it won't be a quick and simple job, since all these pieces have to come together. It's increasingly clear that just getting addresses should be the easy part of this. It's how you give them out, and what you run on the server side to defeat China's scanning, that still look like the two tough challenges for somebody trying to scale up their circumvention tool design.

Tor Weekly News — March 12th, 2014

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

New release of tor-ramdisk

On March 9th, Anthony G. Basile released a new version of tor-ramdisk. Tor-ramdisk is a “micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. Security is enhanced by hardening the kernel and binaries, and privacy is enhanced by forcing logging to be off at all levels so that even the Tor operator only has access to minimal information. Finally, since everything runs in ephemeral memory, no information survives a reboot […].”

The new version contains Tor 0.2.4.21 and an updated kernel. The main change is the addition of “haveged, a daemon to help generate entropy on diskless systems, for a more cryptographically sound system”.

Tails launches a logo contest

Do you want to design a piece of artwork that might be seen by hundreds of thousands of people every day? A drawing that will appear on websites, t-shirts, stickers, and software that protects anonymity and privacy?

Tails is starting a logo contest to “give Tails the visual impact it deserves”. Designers have a precise list of requirements to follow that was drawn from past discussions amongst Tails developers. Participants should submit a version of the logo that incorporates the word “Tails” as well as one without text; there is also a list of suggestions for complementary material that would be welcome.

As the Tails team wants to have the logo ready for its upcoming 1.0 release, designers have until March 31st to send their submission. Be quick!

More status reports for February 2014

The wave of regular monthly reports from Tor project members for the month of February continued, with Isis Lovecruft, Andrew Lewman, Matt Pagan, and Kevin P. Dyer releasing their reports this week.

The Tails developers also reported on their recent progress, and Roger Dingledine sent out the report for SponsorF.

Miscellaneous news

Tails issued the call for testing for its 0.23 release. At the very least, the long awaited features that are MAC spoofing and bridge integration would benefit from wider testing. Enthusiasts are encouraged to report their findings on the newly-created tails-tester mailing list.

Nick Mathewson called on anyone who wants to make Tor relays 3% to 10% faster to review his patches. Have a look at #9683 and #9841 if you want to help out.

Testing of the upcoming Tor Browser Bundle 3.6 with pluggable transports included has started.

Many thanks to Samuel D. Leslie and MacLemon for running mirrors of the Tor Project website!

Karsten Loesing sent out the minutes of the March 5th Weather rewrite online meeting.

Alex reported on an effort to use ScrambleSuit with OpenVPN. Ultimately, Yawning Angel identified a flaw in OpenVPN implementation of the SOCKS protocol and even wrote a patch for it.

Sebastian Urbach announced that Trying Trusted Tor Traceroutes has “reached 100 completed runs from different ip’s (not to mention the multiple runs).” To all participating relay operators, he added: “Thank you very much for your support, you officially rock!”

Tails reported on their 2013 bounty program which led to several changes useful for Tails in upstream software.

Erinn Clark discovered another fake OpenPGP key with her name and email address. Watch out! The canonical list of keys used for Tor signatures is still available on the Tor Project’s website. Also consider verifying all signatures for the reproducible Tor Browser Bundles.

Tor help desk roundup

Users have asked us why “About TorBrowser” in the Tor Browser’s Help menu displays the Firefox Logo instead of the Tor logo. This has been a known issue for some time, and fixing it is not as easy it would seem. Relevant bug tickets here are #2176, #5194, #5698, and #10888.

News from Tor StackExchange

The last few weeks have seen several vulnerabilities in the GnuTLS library and the SSL protocol in general. Ivar wanted to know if the GnuTLS bug affected Tor somehow; as Tor uses OpenSSL instead of GnuTLS, the answer is no.

tor_user found the option “Socks5Proxy” in the Tor manual, and wanted to know what OR connections are and if this option allows running a Tor node over a SOCKS proxy. Jens Kubieziel explained that OR connections are those between two relays or between a client and a relay. While this config option can be used to proxy outgoing OR connections from a relay, it won’t proxy exit streams, and also the relay still needs to be reachable on its advertised ORPort, so it is simplest to say that no, it can’t be used to run a relay over a SOCKS proxy.


This issue of Tor Weekly News has been assembled by Lunar, harmony, Matt Pagan, qbi 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!

Tor Weekly News — March 5th, 2014

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

Tor 0.2.4.21 is out

Roger Dingledine announced the release of Tor 0.2.4.21, whose major new feature is the forced inclusion of at least one NTor-capable relay in any given three-hop circuit as a defence against adversaries who might be able to break 1024-bit encryption; this feature was first seen in the latest alpha release (0.2.5.2-alpha) three weeks ago, but is here incorporated into the current stable series.

You can find full details of this release’s other features and bugfixes in Roger’s announcement.

Tor in Google Summer of Code 2014

As has been the case over the past several years, Tor will once again be participating in Google’s annual Summer of Code program — aspiring software developers have the chance to work on a Tor-related project with financial assistance from Google and expert guidance from a core Tor Project member. Several prospective students have already contacted the community with questions about the program, and Damian Johnson took to the Tor Blog to give a brief summary of what students can expect from the Summer of Code, and what the Tor Project expects from its students.

In particular, Damian encouraged potential applicants to discuss their ideas with the community on the tor-dev mailing list or IRC channel before submitting an application: “Communication is essential to success in the summer of code, and we’re unlikely to accept students we haven’t heard from before reading their application.”

If you are hoping to contribute to Tor as part of the Summer of Code program, please have a look through Damian’s advice and then, as he says, “come to the list or IRC channel and talk to us!”

Two ways to help with Tails development

One of the most interesting upcoming additions to the Tails operating system is the ability to thwart attempts at tracking the movements of network-enabled devices by spoofing the MAC address on each boot. As part of the testing process for this new feature, the Tails developers have released an experimental disk image which turns it on by default, alongside a step-by-step guide to trying it out and reporting any issues encountered. However, as the developers state, “this is a test image. Do not use it for anything other than testing this feature.” If you are willing to take note of this caveat, please feel free to download the test image and let the community know what you find.

Turning to the longer-term development of the project, the team also published a detailed set of guidelines for anyone who wants to help improve Tails itself by contributing to the development of Debian, the operating system on which Tails is based. They include advice on the relationship between the two distributions, tasks in need of attention, and channels for discussing issues with the Tails community; if you are keen on the idea of helping two free-software projects at one stroke, please have a look!

Monthly status reports for February 2014

The wave of regular monthly reports from Tor project members for the month of February has begun. Georg Koppen released his report first, followed by reports from Sherief Alaa, Pearl Crescent, Nick Mathewson, Colin C., Lunar, Kelley Misata, Damian Johnson, George Kadianakis, Philipp Winter, and Karsten Loesing.

Lunar also reported on behalf of the help desk, while Mike Perry did the same on behalf of the Tor Browser team , and Arturo Filastò for the OONI team.

Miscellaneous news

Members of the Prosecco research team released a new attack on the TLS protocol — dubbed “Triple Handshake” — allowing impersonation of a given client when client authentication is in use together with session resumption and renegotiation. Nick Mathewson published a detailed analysis of why Tor is not affected, and also outlines future changes to make Tor resistant to even more potential TLS issues.

Mike Perry announced the start of a weekly Tor Browser developer’s meeting, to be held on #tor-dev on irc.oftc.net. These meetings are tentatively scheduled for 19:00 UTC on Wednesdays. Details on the format and flow of the meetings can be found on the tor-dev and tbb-dev mailing lists.

Roger Dingledine and Nick Mathewson were among the signatories of an open letter published by the EFF which offers ten principles for technology companies to follow in protecting users from illegal surveillance.

Nick Mathewson also detailed a change in the way that the core Tor development team will use the bugtracker’s “milestone” feature to separate tickets marked for resolution in a given Tor version from those that can be deferred to a later release.

Nick then sent out the latest in his irregular series of Tor proposal status updates, containing summaries of each open proposal, guidance for reviewers, and notes for further work. If you'd like to help Tor’s development by working on one of these proposals, start here!

On the subject of proposals, two new ones were sent to the tor-dev list for review: proposal 228, which offers a way for relays to prove ownership of their onion keys as well as their identity key, and proposal 229 based on Yawning Angel’s unnumbered submission from last week, which concerns improvements to the SOCKS5 protocol for communication between clients, Tor, and pluggable transports.

Nicholas Merrill wrote to the Liberationtech list to announce that xmpp.net now lists XMPP servers that are reachable over hidden services, and that xmpp.net’s server scanner works with these as well.

Patrick Schleizer announced the release of version 8 of Whonix — an operating system focused on anonymity, privacy and security based on the Tor anonymity network, Debian and security by isolation. The curious should take a look at the long changelog.

Kelley Misata wrote up an account of her talk “Journalists — Staying Safe in a Digital World”, which she delivered at the Computer-Assisted Reporting Conference in Baltimore.

Having co-authored a paper in 2012 on usability issues connected with
the Tor Browser Bundle
, Greg Norcie drew attention to a follow-up study named Why Johnny Can’t Blow the Whistle,  which focuses on verifying the conclusions of the earlier tests while exploring a number of other possible usability improvements. The study was, however, carried out before the release of Tor Browser version 3, which improved the bundle’s usability based on earlier suggestions.

Mac OS X users will be thrilled to learn that the next Tor Browser Bundle will be shipped as a DMG (disk image) instead of the previous unusual .ZIP archive.

David Rajchenbach-Teller from Mozilla reached out to the Tor Browser developers about their overhaul of the Firefox Session Restore mechanism. This is another milestone in the growing collaboration between the Tor Project and Mozilla.

On the “anonymity is hard” front, David Fifield reported a fingerprinting issue on the Tor Browser. Fallback charsets can be used to learn the user locale as they vary from one to another. The next release of the Tor Browser will use “windows-1252” for all locales, as this matches the impersonated “User-Agent” string (Firefox — English version — on Windows) that it already sends in its HTTP headers.

Yawning Angel called for help in testing and reviewing obfsclient-0.0.1rc2, the second obfsclient release candidate this week: “assuming nothing is broken, this will most likely become v0.0.1, though I may end up disabling Session Ticket handshakes.”

David Fifield published a guide to patching meek, an HTTP pluggable transport, so that it can be used to send traffic via Lantern, a censorship circumvention system which “acts as an HTTP proxy and proxies your traffic through trusted friends.”

Fortasse started a discussion on tor-talk about using HTTPS Everywhere to redirect Tor Browser users to .onion addresses when available. Several people commented regarding the procedure, its security, or how it could turn the Tor Project or the EFF into some kind of registrar.

anonym has been busy adapting the configuration interface from the Tor Browser — called “Tor Launcher” — to Tails’ needs. Preliminary results can already be seen in the images built from the experimental branch.

Ramo wrote to announce their Nagios plugin project to the relay operator community. Lunar pointed out a complementary probe named
check_tor.py.

Virgil Griffith sent a draft proposal for changes to improve the latency of hidden services when using the “Tor2web” mode. Roger Dingledine commented that one of the proposed changes actually opened a new research question regarding the actual latency benefits.

David Goulet released the fourth candidate of his Torsocks rewrite. This new version comes after “a big code review from Nick and help from a lot of people contributing and testing”. But more reviews and testing are now welcome!

Tor help desk roundup

Often users email the help desk when the Tor Browser’s Tor client fails somehow. There are many ways for the Tor Browser to fail in such a way that the Tor log is inaccessible. Since antivirus programs, firewalls, system clock skew, proxied internet connections, and internet censorship have all been known to cause Tor failures, it is not always easy to determine the source of the problem. Thankfully, the Tor Browser team is working on making the logs easier to access in case of failures (#10059, #10603).

News from Tor StackExchange

Janice needs to be able to connect from an IP address in a specific city and wanted to know if Tor can be used to do so. Several users suggested that this is not possible with Tor. For city-level IP addresses, it might better to use other services like a proxy or a tunnel, provided one does not require anonymity.

The Tor Browser Bundle sets the default font to Times New Roman 16pt and allows pages to use their own fonts. User joeb likes to change the settings and wondered how this increases the possibility to fingerprint a user. gacar suggested that this will facilitate fingerprinting attacks. Several important sites use font probing to fingerprint their users, and changing the default fonts is likely to make a user stand out from the common anonymity set.

Kristopher Ives wondered if Tor uses some kind of compression. Several users searched the source code archives for “gzip” and found code which deals with directory information. Jens Kubieziel argued that Tor operates on encrypted data and compressing encrypted data usually results in a increase in size, so it makes no sense to compress this data.

Stackexchange uses bounties to award higher reputations to answers. By using this one can attract attention and get better answers or an answer at all. The question about using DNSSEC and DNScrypt over Tor is probably the first to receive a bounty: an answer to this question would be rewarded with 50 points. However, they have not been earned yet, so if you know an answer, please enlighten the rest of the community.


This issue of Tor Weekly News has been assembled by harmony, Lunar, qbi, Matt Pagan, Karsten Loesing, Mike Perry, dope457, and Philipp Winter.

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!

Syndicate content