Blogs

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!

Tor in Google Summer of Code 2014

in

Interested in coding on Tor and getting paid for it by Google? If you are a student, we have good news for you: We have been accepted as a mentoring organisation for Google Summer of Code 2014 together with The Electronic Frontier Foundation!

Here are the facts: The summer of code gives you the opportunity to work on your own Tor-related coding project with one of the Tor developers as your mentor. You can apply for a coding project related to Tor itself or to one of its many supplemental projects. Your mentor will help you when you're stuck with your project and guide you in becoming part of the Tor community. Google pays you 5,500 USD for the three months of your project, so that you can focus on coding and don't have to worry about how to pay your bills.

Did we catch your attention? These are your next steps: Go look at the Google Summer of Code FAQ to make sure you are eligible to participate. Have a look at our ideas list to see if one of those projects matches your interests. If there is no project on that list that you'd want to work on, read the documentation on our website and make up your own project idea! Come to the tor-dev@ list or #tor-dev on OFTC and let us know about your project idea. 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. So really, come to the list or IRC channel and talk to us!

Finally, write down your project idea using our template and submit your application to Google before March 21.

We are looking forward to discussing your project idea with you!

Tor Weekly News — February 26th, 2014

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

News from the 2014 Winter Developers’ Meeting in Reykjavík

Since 2010, the Tor Project’s core contributors have tried to meet twice a year to enjoy the pleasure of each other’s company and move projects forward through face-to-face discussions and hacking time. This year, close to forty people attended the 2014 winter dev. meeting, which was held in Reykjavík, Iceland.

The team discussed over forty topics ranging from organizational matters to highly technical design decisions. Among the highlights: many sessions were focused on discussing and producing roadmaps — a mid-term vision for the Tor Browser, a step-by-step plan for the Tor Instant Messaging Bundle, detailed ideas for new bridge bundles, ways to solve the research problems around guard nodes, and how to plan little-t tor releases.

The meeting also enabled cross-team communication: pluggable transports developers were able to discuss integration into the Tor Browser and the lifecycle of recommended transports, while the Tor Browser group and the support teams met to see how to improve communications on both sides. One outcome is a plan to remix existing documentation to create the Tor Browser User Manual.

Two days of intense discussion were followed by hands-on sessions which saw their fair share of hacking and write-ups.

Some of the minutes are still missing, but there is already plenty to read. Now that the developers have had to stop contemplating the Northern Lights, some discussions are already continuing on the project’s various mailing lists. Stay tuned!

Miscellaneous news

Karsten Loesing  announced an IRC meeting to discuss the next steps for the rewrite of Tor Weather, to be held on the OFTC #tor-dev channel on Wednesday 26th February at 18:00 UTC. “Topics include reporting progress made since the last meeting two weeks ago, making plans for the next week, and possibly turning this project into a GSoC project”.

Nick Mathewson announced the start of a weekly Tor developer’s meeting, to be held on the OFTC #tor-dev channel, “for working on the program ‘tor’. (This won’t cover all the other programs developed under the Tor umbrella.)” .

The Tails developers will be holding their next contributors’ meeting on the OFTC #tails-dev channel at 9pm UTC on March 5th; “everyone interested in contributing to Tails is welcome.” .

Andrew Lewman submitted his monthly status report for January, and also wrote up a report of his involvement in the recent Boston CryptoParty.

Alexander Dietrich published a multi-instance init script for Tor (“basically the current official init script and torservers.net’s “instances” mechanism frankensteined together”, in Alexander’s words) in response to a recent discussion on tor-relays.

Responding to a message from someone interested in writing a DNS-based pluggable transport, George Kadianakis suggested several ways in which the existing obfsproxy code could be reworked to accommodate this.

George also recommended that operators of obfs3 or ScrambleSuit bridges install the python-gmpy package on their relays, as it can significantly increase the speed of some cryptographic operations.

Jens Kubieziel wrote up the results of an attempt to determine whether the recent transition between the TAP and NTor handshake protocols is connected to some users’ reports of hidden service unavailability.

Max Jakob Maass published the preliminary results of a test in which the RIPE Atlas measurement API was used to retrieve the SSL certificate of torproject.org from as many countries as possible in order to detect attempted attacks or censorship, and wondered whether it might be worth running such a test on a regular basis.

With regard to a coming redesign of the “Volunteers” section on the Tor Project’s website, Moritz Bartl wrote up a list of proposed volunteer categories that was the fruit of a brainstorming session at the Tor developers’ meeting, and asked for suggestions of “obvious” missing sections, as well as “acceptably-licensed” graphics that could serve as icons for each category .

Nathan Freitas wrote from the Tor developers’ meeting with a request for help in compiling “user stories” on the Tor wiki: that is, stories of the form “a type of Tor user wants to some feature of a Tor app in order to some reason related to security, privacy, etc”. If you have any to add, please write them up on the dedicated wiki page!

Yawning Angel sent out a draft of a proposal to “extend the SOCKS5 protocol when communicating with pluggable transports to allow passing more per-bridge meta-data to the transport and returning more meaningful connection failure response codes back to Tor”.

Josh Ayers wrote to the Tor-ramdisk list suggesting possible ways to ensure that sufficient entropy is available to the kernel by the time tor-ramdisk generates its long-term keys.

Tor help desk roundup

A common question the help desk receives is how to respond to the Tor Browser Bundle’s download warning message. The message indicates that the Tor Browser Bundle only routes browser traffic through Tor, not traffic from any other application. For example, a PDF file that connects automatically to a URL will not route its traffic through Tor if the file is opened with an external application. An open bug ticket for improving this warning message has more information about the issue.


This issue of Tor Weekly News has been assembled by harmony, Lunar, Matt Pagan, Nicolas Vigier, Roger Dingledine, and George Kadianakis.

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 — February 19th, 2014

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

Tor 0.2.5.2-alpha is out

Roger Dingledine announced the second alpha release in the Tor 0.2.5 series. As well as incorporating “all the fixes from 0.2.4.18-rc and 0.2.4.20, like the “poor random number generation” fix and the “building too many circuits” fix”, this release brings with it several new features of its own, among them the forced inclusion of at least one relay capable of the NTor handshake in every three-hop circuit, which should reduce the chance “that we’re building a circuit that’s worth attacking by an adversary who finds breaking 1024-bit crypto doable”, as Roger wrote.

You can read the full changelog in Roger’s announcement, and download the new release from the Tor Project website.

Tor Browser 3.5.2.1 is released

A new point release of the Tor Browser Bundle was put out on February 15th. A change in how Mozilla tags Firefox releases broke the localization of the browser interface. This release restores proper behavior for languages other than English.

Apart from the localization fix and the removal of unneeded libraries from the Windows bundles, no other changes have been made.

Help draft a proposal for partnership with the Wikimedia Foundation

The relationship between Tor users and the Wikimedia Foundation, which operates Wikipedia and related projects, is currently not as good as it could be: many Tor users feel they should be able to contribute to Wikipedia anonymously, while many Wikipedia editors are wary of dealing with a tool that could enable untraceable or unblockable vandalism of pages and articles.

As a prelude to resolving this conflict, Lane Rasberry has opened a discussion on the Wikimedia Foundation’s IdeaLab, a forum in which ideas can be discussed and debated before being collaboratively developed into full grant proposals. As Lane wrote, “persons using Tor (the anonymity network) should be able to create Wikipedia accounts and contribute to Wikipedia while logged into those accounts. Some technical problems currently disallow this and some social problems prevent the technical problems from being addressed. Anyone with a proposal of what kind of relationship Tor and the Wikimedia movement should have should describe it here.”

If you are interested in helping to resolve this issue, please see the IdeaLab page, and add your comments!

Only as good as your weakest transport?

Delton Barnes pointed out that although the ScrambleSuit pluggable transport protocol includes a certain amount of protection against active probing for bridges by censorship systems like the Chinese “Great Firewall”, bridge operators who run more vulnerable protocols like obfs3 alongside ScrambleSuit may be increasing the risk that censors will discover their relay and block connections to it of any kind.

In reply, Philipp Winter conceded that although the Chinese censorship system currently seems to block bridges by IP:port tuples, rather than by IP address alone, the mere presence of an easily-discoverable pluggable transport protocol (or a public relay) on a given machine makes it more likely that a censor will be motivated to try and defeat protections such as those offered by ScrambleSuit. “So you are right, only running ScrambleSuit gives your bridge more protection than running other protocols at the same time — at the cost of attracting less users, however”, he concluded.

Miscellaneous news

The Tails team has published its report for January 2014. A lot is happening in the growing community of Tails developers. Have a look!

Qingping Hou sent out the beginnings of a proposal to increase the speed of connections to Tor Hidden Services by using circuits of only five hops, and asked the community for feedback.

Yawning Angel called for help with testing obfsclient, a C++ pluggable transport client, and clarified the next steps in the development process.

David Fifield made available a second updated set of the experimental Tor Pluggable Transport Bundle with tor-fw-helper, which fixes several of the errors encountered in the first version.

Nick Mathewson called for help with reviewing proposal 227, which involves “extending the Tor consensus document to include digests of the latest versions of one or more package files, to allow software using Tor to determine its up-to-dateness, and help users verify that they are getting the correct software”.

Efforts to include the FTE protocol in the Tor Pluggable Transport Bundles have taken a step forward, as Kevin P. Dyer announced the release of a patch including fteproxy that not only works, but also builds deterministically, in keeping with the Tor Project’s focus on build security.

Rusty Bird announced the release of corridor, a Tor traffic whitelisting gateway. corridor will turn a Linux system into a router that “allows only connections to Tor relays to pass through (no clearnet leaks!)”. However, unlike transparent proxying solutions, “client computers are themselves responsible for torifying their own traffic.”

One relay operator was looking for an init.d script able to start multiple tor instances. Johannes Fürmann pointed out that one was available in the torservers.net Git repository.

TorBirdy, the Tor-enabling extension for the Thunderbird mail client, currently disables the automated account configuration system for security reasons. Progress is being made in changing the behavior to make it fit the expectations of Tor users.

Andrea Shepard submitted seven status reports, covering her activity since July 2013 (July, August, September, October, November, December, January).

Tor help desk roundup

Users often ask for help updating their Tor Browser Bundle. Some users download and try to run their new Tor Browser without first closing their current Tor Browser. This causes an error message, since Tor is already running. The Tor Browser Bundle update is not an upgrade that can be applied while Tor Browser is still running. Users must close their current Tor Browser before running their newly downloaded Tor Browser Bundle.


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

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.2.1 is released

The 3.5.2.1 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 fixes the localization of the non-english bundles.

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 list of changes since 3.5.2. The 3.x ChangeLog is also available.

  • All Platforms
    • Bug 10895: Fix broken localized bundles
  • Windows:
    • Bug 10323: Remove unneeded gcc/libstdc++ libraries from dist
Syndicate content Syndicate content