Support all your favorite nonprofits with a single donation.

Donate safely, anonymously & monthly, in any amount. It's a smarter way to give online. Learn more
The Tor Project
Dedham, MA
givvers: jason, emerssso + 4 others

Tor is free software and an open network that helps you defend against a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security known as traffic analysis.

The Tor Project is a 501(c)3 organization.

Latest News

Oct 21, 2014

This is a copy of the message Nick Mathewson sent to the tor-talk & tor-relays mailing lists.

Hello, relay operators!

There's one important bugfix in the 0.2.5.9-rc release that relay operators should know about. If you have a version of OpenSSL that came out last week (like 1.0.1j, 1.0.0, ) and if your version of OpenSSL is built with the "no-ssl3" flag, then it's possible to crash your Tor relay remotely if you don't upgrade to 0.2.5.9-rc or to 0.2.4.25 (when that's out).

This appears to be an OpenSSL bug. The Tor releases in question contain a workaround for it.

To tell if your version of OpenSSL was built with 'no-ssl3': run:

openssl s_client -ssl3 -connect www.torproject.org:443

If it gives you output beginning with something like:

CONNECTED(00000003)
140632971298688:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
alert handshake failure:s3_pkt.c:1257:SSL alert number 40
140632971298688:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl
handshake failure:s3_pkt.c:596:

then you're fine and you don't need to upgrade Tor on your relay. But if it says something that starts with:

unknown option -ssl3
usage: s_client args

then you need to upgrade Tor.

Some questions and answers:

Q: Does this affect clients?
A: No. Only relays.

Q: Does this affect me if I'm running a version of OpenSSL other than 1.0.1j, 1.0.0o, or 0.9.8zc?
A: No. Only those versions.

Q: Does this affect me if I'm running a version of OpenSSL configured without the "no-ssl3" option?
A: No. Only versions that were built with the "no-ssl3" option are affected.

Q: Does the OpenSSL team know?
A: Yes. Have a look at this thread. Also, before I saw that thread, I informed them the other day.

Q: Does this affect Tor packages?
A: I don't think that we shipped any packages where we used the "no-ssl3" flag to diable ssl3. So only if you're using OpenSSL from another source (say, your operating system) will you be affected.

Q: What can I do to remediate this problem?
A: You can upgrade to the most recent Tor, or you can use a version of OpenSSL built without the "no-ssl3" flag. Downgrading your OpenSSL is not recommended.

Q: What is the potential impact of this bug?
A: If a relay is affected by this bug, anybody can make the relay crash remotely. It does not enable any data leaks or remote code execution. Still, the ability to selectively disable relays might enable a sophisticated attacker to do some kinds of traffic analysis more efficiently. So, fix your relay if it's affected.

Q: Should we run in circles and freak out?
A: Not this time. We should just make sure we fix affected relays.

Q: Hey, Nick, you didn't explain this properly!
A: Please send a follow-up message that explains it better. :)

Oct 16, 2014

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

This release fixes numerous security issues and all users must upgrade as soon as possible.

Changes

Notable user-visible changes include:

  • Major new features
    • Install (most of) the Tor Browser, replacing our previous Iceweasel-based browser. The version installed is from TBB 4.0 and is based on Firefox 31.2.0esr. This fixes the POODLE vulnerability.
    • Upgrade Tor to 0.2.5.8-rc.
    • Confine several important applications with AppArmor.
  • Bugfixes
    • Install Linux 3.16-3 (version 3.16.5-1).
  • Minor improvements
    • Upgrade I2P to 0.9.15, and isolate I2P traffic from the Tor Browser by adding a dedicated I2P Browser. Also, start I2P automatically upon network connection, when the i2p boot option is added.
    • Make it clear that TrueCrypt will be removed in Tails 1.2.1 (ticket #7739), and document how to open TrueCrypt volumes with cryptsetup.
    • Enable VirtualBox guest additions by default (ticket #5730). In particular this enables VirtualBox's display management service.
    • Make the OTR status in Pidgin clearer thanks to the formatting toolbar (ticket #7356).
    • Upgrade syslinux to 6.03-pre20, which should fix UEFI boot on some hardware.

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 November 25.

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

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

Oct 15, 2014

Update (Oct 16 20:35 UTC): The meek transport still needs performance tuning before it matches other more conventional transports. Ticket numbers are now listed in the post.

The first release of the 4.0 series is available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox. Additionally, due to the POODLE attack, we have also disabled SSLv3 in this release.

The primary user-facing change since the 3.6 series is the transition to Firefox 31-ESR.

More importantly for censored users who were using 3.6, the 4.0 series also features the addition of three versions of the meek pluggable transport. In fact, we believe that both meek-amazon and meek-azure will work in China today, without the need to obtain bridge addresses. Note though that we still need to improve meek's performance to match other transports, though. so adjust your expectations accordingly. See tickets #12428, #12778, and #12857 for details.

This release also features an in-browser updater, and a completely reorganized bundle directory structure to make this updater possible. This means that simply extracting a 4.0 Tor Browser over a 3.6.6 Tor Browser will not work. Please also be aware that the security of the updater depends on the specific CA that issued the www.torproject.org HTTPS certificate (Digicert), and so it still must be activated manually through the Help ("?") "about browser" menu option. Very soon, we will support both strong HTTPS site-specific certificate pinning (ticket #11955) and update package signatures (ticket #13379). Until then, we do not recommend using this updater if you need stronger security and normally verify GPG signatures.

There are also a couple behavioral changes relating to NoScript since 3.6. In particular, by default it now enforces script enable/disable for all sub-elements of a page, so you only need to enable scripts once for a page to work, rather than enabling many sub-scripts. This will hopefully make it possible for more people to use the "High Security" setting in our upcoming Security Slider, which will have Javascript disabled globally via NoScript by default. While we do not recommend per-element whitelisting due to fingerprinting, users who insist on keeping this functionality may wish to check out RequestPolicy.

Note to MacOS users: We intend to deprecate 32bit OSX bundles very soon. If you are still using 32bit OSX 10.6, you soon will need to either update your OS to a later version, or begin using the Tails live operating system.

Here is the changelog since 4.0-alpha-3:

  • All Platforms
    • Update Firefox to 31.2.0esr
    • Update Torbutton to 1.7.0.1
      • Bug 13378: Prevent addon reordering in toolbars on first-run.
      • Bug 10751: Adapt Torbutton to ESR31's Australis UI.
      • Bug 13138: ESR31-about:tor shows "Tor is not working"
      • Bug 12947: Adapt session storage blocker to ESR 31.
      • Bug 10716: Take care of drag/drop events in ESR 31.
      • Bug 13366: Fix cert exemption dialog when disk storage is enabled.
    • Update Tor Launcher to 0.2.7.0.1
      • Translation updates only
    • Udate fteproxy to 0.2.19
    • Update NoScript to 2.6.9.1
    • Bug 13027: Spoof window.navigator useragent values in JS WebWorker threads
    • Bug 13016: Hide CSS -moz-osx-font-smoothing values.
    • Bug 13356: Meek and other symlinks missing after complete update.
    • Bug 13025: Spoof screen orientation to landscape-primary.
    • Bug 13346: Disable Firefox "slow to start" warnings and recordkeeping.
    • Bug 13318: Minimize number of buttons on the browser toolbar.
    • Bug 10715: Enable WebGL on Windows (still click-to-play via NoScript)
    • Bug 13023: Disable the gamepad API.
    • Bug 13021: Prompt before allowing Canvas isPointIn*() calls.
    • Bug 12460: Several cross-compilation and gitian fixes (see child tickets)
    • Bug 13186: Disable DOM Performance timers
    • Bug 13028: Defense-in-depth checks for OCSP/Cert validation proxy usage
    • Bug 13416: Defend against new SSLv3 attack (poodle).


Here is the list of all changes in the 4.0 series since 3.6.6:

  • All Platforms
    • Update Firefox to 31.2.0esr
    • Udate fteproxy to 0.2.19
    • Update Tor to 0.2.5.8-rc (from 0.2.4.24)
    • Update NoScript to 2.6.9.1
    • Update Torbutton to 1.7.0.1 (from 1.6.12.3)
      • Bug 13378: Prevent addon reordering in toolbars on first-run.
      • Bug 10751: Adapt Torbutton to ESR31's Australis UI.
      • Bug 13138: ESR31-about:tor shows "Tor is not working"
      • Bug 12947: Adapt session storage blocker to ESR 31.
      • Bug 10716: Take care of drag/drop events in ESR 31.
      • Bug 13366: Fix cert exemption dialog when disk storage is enabled.
    • Update Tor Launcher to 0.2.7.0.1 (from 0.2.5.6)
      • Bug 11405: Remove firewall prompt from wizard.
      • Bug 12895: Mention @riseup.net as a valid bridge request email address
      • Bug 12444: Provide feedback when “Copy Tor Log” is clicked.
      • Bug 11199: Improve error messages if Tor exits unexpectedly
      • Bug 12451: Add option to hide TBB's logo
      • Bug 11193: Change "Tor Browser Bundle" to "Tor Browser"
      • Bug 11471: Ensure text fits the initial configuration dialog
      • Bug 9516: Send Tor Launcher log messages to Browser Console
    • Bug 13027: Spoof window.navigator useragent values in JS WebWorker threads
    • Bug 13016: Hide CSS -moz-osx-font-smoothing values.
    • Bug 13356: Meek and other symlinks missing after complete update.
    • Bug 13025: Spoof screen orientation to landscape-primary.
    • Bug 13346: Disable Firefox "slow to start" warnings and recordkeeping.
    • Bug 13318: Minimize number of buttons on the browser toolbar.
    • Bug 10715: Enable WebGL on Windows (still click-to-play via NoScript)
    • Bug 13023: Disable the gamepad API.
    • Bug 13021: Prompt before allowing Canvas isPointIn*() calls.
    • Bug 12460: Several cross-compilation and gitian fixes (see child tickets)
    • Bug 13186: Disable DOM Performance timers
    • Bug 13028: Defense-in-depth checks for OCSP/Cert validation proxy usage
    • Bug 4234: Automatic Update support (off by default)
    • Bug 11641: Reorganize bundle directory structure to mimic Firefox
    • Bug 10819: Create a preference to enable/disable third party isolation
    • Bug 13416: Defend against new SSLv3 attack (poodle).
  • Windows:
    • Bug 10065: Enable DEP, ASLR, and SSP hardening options
  • Linux:
    • Bug 13031: Add full RELRO hardening protection.
    • Bug 10178: Make it easier to set an alternate Tor control port and password
    • Bug 11102: Set Window Class to "Tor Browser" to aid in Desktop navigation
    • Bug 12249: Don't create PT debug files anymore

The list of frequently encountered known issues is also available in our bug tracker.

Oct 15, 2014

Welcome to the forty-first issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Academic research into Tor: four recent studies

Major contributions to the development and security of Tor are often made by academic researchers, either in a laboratory setting using network simulators like Shadow, or through measurement and analysis of the live network itself (taking care not to harm the security or anonymity of clients and services). Different aspects of Tor’s networking and security, from path selection to theoretical attacks, have been analysed in three recently-published studies.

Otto Huhta’s MSc thesis investigates the possibility that an adversary in control of a non-exit relay could link two or more Tor circuits back to the same client based on nothing more than timing information. As Otto explained, “this is mainly the result of the fixed 10 minute circuit lifetime and the fact that the transition to using a new circuit is quite sharp.” With the help of a machine classifier, and the fact that any one client will build its circuits through a fixed set of entry guards, the study suggested that such an adversary “can focus only on circuits built through these specific nodes and quite efficiently determine if two circuits belong to the same user.” There is no suggestion that this knowledge alone poses a serious deanonymization risk to clients; however, wrote Otto, “our goal was not to ultimately break the anonymity of any real user but instead to expose a previously unknown threat so that it can be mitigated before anyone actually devises an attack around it.”

Steven Murdoch published a paper on the optimization of Tor’s node selection probabilities showing, in Steven’s words, “that what Tor used to do (distributing traffic to nodes in proportion to their contribution to network capacity) is not the best approach.” Prior to publication of the study, “Tor moved to actively measuring the network performance and manipulating the consensus weights in response to changes. This seems to have ended up with roughly the same outcome. […] However, the disadvantage is that it can only react slowly to changes in network characteristics.”

Sebastian Urbach shared a link to “Defending Tor from Network Adversaries: A Case Study of Network Path Prediction”, in which the researchers analyze the effect of network features like autonomous systems and Internet exchanges on the security of Tor’s path selection, finding that “AS and IX path prediction significantly overestimates the threat of vulnerability to such adversaries”, and that “the use of active path measurement, rather than AS path models” would be preferable “in further study of Tor vulnerability to AS- and IX-level adversaries and development of practical defenses.”

Meanwhile, Philipp Winter took to the Tor blog to summarize some new findings concerning the the way in which the Chinese state Internet censorship system (the “Great Firewall of China”) acts upon blocked connections, like those trying to reach Tor, as detailed in a recent project to which he contributed. Searching for spatial and temporal patterns in Chinese censorship activity, the researchers found that “many IP addresses inside the China Education and Research Network (CERNET) are able to connect” to Tor in certain instances, while the filtering of other networks — centrally conducted at the level of Internet exchanges — “seems to be quite effective despite occasional country-wide downtimes”.

Each of these studies is up for discussion on the tor-dev mailing list, so feel free to join in there with questions and comments for the researchers!

Miscellaneous news

Michael Rogers submitted patches against tor and jtorctl, making two improvements to the performance of mobile hidden services: one “avoids a problem where we’d try to build introduction circuits immediately, all the circuits would fail, and we’d wait for 5 minutes before trying again”, and the other “[adds] a command to the control protocol to purge any cached state relating to a specified hidden service”.

Karsten Loesing published a “non-functional” mock-up of a possible redesign for the Tor Metrics portal, with notes on design decisions: “Feedback much appreciated. This is the perfect time to consider your ideas.”

Jeremy Gillula analyzed data relating to Tor node churn found in Tor consensuses for September 2014, and found that “on average, 0.003% of nodes switch from being relay nodes to exit nodes in any given 1-hour period, and 0.002% switch from being exit nodes to relay nodes”.

Noel Torres and Andrew Lewman sent their status reports for September. Roger Dingledine also sent out the report for SponsorF.

Greg Norcie wondered why the interval at which Tor switches to using a new circuit was set at ten minutes, and Nick Mathewson responded that after the original period of thirty seconds was found to be unworkable, the new number was selected in 2005 “more or less intuitively”. Paul Syverson added that the choice was “an informed one”, taken after “a bunch of discussions concerning the trade-offs between the overhead of the public-key operations of circuit building and the pseudonymous profiling occurring at an exit”.

Both Tor and Tails received their first cinematic credits with the première of “CITIZENFOUR”, a documentary film concerning the recent disclosure of intelligence documents by Edward Snowden. Eagle-eyed viewers might spot a well-known hostname in the film’s trailer

WhonixQubes reported on progress in many areas of the Whonix+Qubes project, which as the name implies is a combination of the Whonix and Qubes operating systems. Among other things, the system now supports Whonix 9, a community forum has been set up, and greater upstream integration is being discussed.

News from Tor StackExchange

"What happens when Tor always chooses the same path?" asks Mark and wants to know which weaknesses this exposes. User194 believes that this would prevent a “predecessor attack” and make the system stronger, while Lisbeth writes: “This makes your entire traffic highly fingerprintable as compared to a standard random path. If your connections always used A, B, and C nodes, it is statistically unlikely that many other people are consistently using that same path, therefore it’s very easy to correlate your traffic to your originating IP.”

Muncher visited a website which asked to add HidServAuth into the torrc and wants to know if it is safe to do so. Jeff recommended that this is safe because it doesn’t divulge anything about the identity of a user. Mirimir furthermore referred to a question where adrelanos looks for documentation.


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

Oct 15, 2014

Hi! It's a new month, so that means there's a new attack on TLS.

This time, the attack is that many clients, when they find a server that doesn't support TLS, will downgrade to the ancient SSLv3. And SSLv3 is subject to a new padding oracle attack.

There is a readable summary of the issue at Adam Langley's blog; it links to other descriptions of the attack.

Tor itself is not affected: all released versions for a long time have shipped with TLSv1 enabled, and we have never had a fallback mechanism to SSLv3. Furthermore, Tor does not send the same secret encrypted in the same way in multiple connection attempts, so even if you could make Tor fall back to SSLv3, a padding oracle attack probably wouldn't help very much.

TorBrowser, on the other hand, is based on Firefox, and has the same protocol downgrade mechanisms as Firefox. I expect and hope the TorBrowser team will be
releasing a new version soon with SSLv3 disabled. But in the meantime, I think you can disable SSLv3 yourself by changing the value of the "security.tls.version.min" preference to "1". (The default value is "0".)

To do that:

  1. Enter "about:config" in the URL bar.
  2. Then you click "I'll be careful, I promise".
  3. Then enter "security.tls.version.min" in the preference "search"
    field underneath the URL bar. (Not the search box next to the URL
    bar.)

  4. You should see an entry that says "security.tls.version.min" under
    "Preference Name". Double-click on it, then enter the value "1" and
    click okay.

You should now see that the value of "security.tls.version.min" is set to one.

(Note that I am not a Firefox developer or a TorBrowser developer: if you're cautious, you might want to wait until one of them says something here before you try this workaround. On the other hand, if you believe me, you should probably do this in your regular Firefox as well.)

Obviously, this isn't a convenient way to do this; if you are uncertain of your ability to do so, waiting for an upgrade might be a good move. In the meantime, if you have serious security requirements and you cannot disable SSLv3, it might be a good idea to avoid using the Internet for a week or two while this all shakes out.

Best wishes to other residents of these interesting times.

Oct 08, 2014

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

Setup ooniprobe in five minutes

New versions of the Open Observatory of Network Interference (OONI) tools are out. On October 1st, Arturo Filastò announced ooniprobe 1.2.0 and oonibackend 1.1.4.

“One of the most interesting new features that are now part of ooniprobe is the ability to generate test decks for the country you are in a way that is much easier than before”, wrote Arturo.

He added: “As a matter of fact to start contributing useful measurements it’s just a matter of 5 minutes of setup.” So don’t be shy about adding your measurements to the project!

Monthly status reports for September 2014

The wave of regular monthly reports from Tor project members for the month of September has begun. Juha Nurmi released his report first, followed by reports from Georg Koppen, Damian Johnson, George Kadianakis, Matt Pagan, Lunar, Sherief Alaa, Leiah Jansen, Harmony, Pearl Crescent, Nick Mathewson, Karsten Loesing, Sukhbir Singh, Nicolas Vigier (in addition to July and August), Arlo Breault, J. Todaro, and Colin C.

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

Miscellaneous news

Orbot users should rejoice at the news that orWall 1.0.0 has been released! orWall will force selected applications through Tor while preventing unauthorized applications to have any network access. “Any feedback from Tor/Orbot users interests me in order to improve orWall. I think the current release is pretty good, but as the main dev I’m maybe not that neutral regarding this statement” joked CJ.

The OONI project has been “developing a test that allows probes in censored countries to test which bridges are blocked and which are not”. George Kadianakis is seeking help to create interesting visualization of the resulting data. He shared a sketch about countries and pluggable transports and another one showing time before blocks happened.

Nick Mathewson announced the release of Trunnel 1.3. Trunnel is a code generator for binary encoders/decoders. Nick adds: “Some code that it has generated has been merged into the Tor master branch for the 0.2.6 release series, though that code is not yet in active use.“

David Fifield sent a summary of the costs incurred by the meek pluggable transport for the month of September 2014. More details are included in the email, but costs are currently very low: “$3.85 for App Engine, $4.59 for Amazon, $0.00 for Azure”.

Virgil Griffith shared a yet unpublished tech report on Tor growth. To pick just one finding, the Tor network’s bandwidth has been doubling every 13–14 months so far.

The Knight Foundation is going to fund projects for “the future of libraries”. The Library Freedom Project wants to teach “librarians about privacy rights, law, and tech tools to protect patrons from dragnet surveillance”. It’s based on their previous experience promoting Tor and other privacy tools in Massachusetts libraries. Show them support!

The US National Science Foundation is seeking input to lay out a future Privacy Research Strategy. The deadline being October 17th, Roger Dingledine suggests: “if anybody here has partially written ideas that they want to put together into a submission, please do!”

Thanks to opi for running a new mirror of the Tor Project’s website and software.

Easy development tasks to get involved with

oonibackend is used by ooni, the Open Observatory of Network Interference, to run in the background and perform tasks like discovering addresses of test helpers and performing measurements that require a backend system to talk to. When oonibackend was changed to fix compatibility with Twisted 13.1 it lost its ability to start tor and then drop privileges. Arturo suspects that the correct way of doing this is to place the logic for starting tor inside of preApplication or startService. But from a quick research he suspects that Twisted does not support returning Deferreds in there. He also points to two relevant Twisted tickets (1, 2). If you have experience with Twisted and want to help debug or even solve this problem, be sure to post your thoughts or patches to the ticket.


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

Oct 06, 2014

Over the last years, we learned a lot about how the Great Firewall of China is blocking Tor. Some questions remained unanswered, however. Roya, Mueen, Jed, and I just published a project which seeks to answer some of these open questions. Being curious as we are, we tried to find answers to the following questions:

  • Is the filtering decentralised (i.e., happening in provinces) or centralised (i.e., happening in Internet exchange points (IXP))?
  • Are there any temporal patterns in the filtering? Or in other words, are there certain times when people are more likely to be able to connect to Tor?
  • Similarly, are there any spatial patterns? Are folks in some special regions of China able to connect to Tor while others cannot?
  • When a computer in China tries to connect to a Tor relay, what part of the TCP handshake is blocked?

It turns out that some of these questions are quite tricky to answer. For example, to find spatial patterns, we need to be able to measure the connectivity between many Tor relays and many clients in China. However, we are not able to control even a single one of these machines. So how do we proceed from here? As so often, side channels come to the rescue! In particular, we made use of two neat network measurement side channels which are the hybrid idle scan and the SYN backlog scan. The backlog scan is a new side channel we discovered and discuss in our paper. Equipped with these two powerful techniques, we were able to infer if there is packet loss between relay A and client B even though we cannot control A and B.

You might notice that our measurement techniques are quite different from most other Internet censorship studies which rely on machines inside the censoring country. While our techniques give us a lot more geographical coverage, they come at a price which is flexibility; we are limited to measuring Internet filtering on the IP layer. More sophisticated filtering techniques such as deep packet inspection remain outside our scope.

Now what we did was to measure the connectivity between several dozen Tor relays and computers in China over four weeks which means that we collected plenty of data points, each of which telling us "was A able to talk to B at time T?". These data points reveal a number of interesting things:

  • It appears that many IP addresses inside the China Education and Research Network (CERNET) are able to connect to at least our Tor relay.
  • Apart from the CERNET netblock, the filtering seems to be quite effective despite occasional country-wide downtimes.
  • It seems like the filtering is centralised at the IXP level instead of being decentralised at the provincial level. That makes sense from the censor's point of view because it is cheap, effective, and easy to control.

Now what does all of this mean for Tor users? Our results show that China still has a tight grip on its communication infrastructure, especially on the IP and TCP layer. That is why our circumvention efforts mostly focus on the application layer (with meek being an exception) and pluggable transport protocols such as ScrambleSuit (which is now part of the experimental version of TorBrowser) and obfs4 are specifically designed to thwart the firewall's active probing attacks.

Oct 01, 2014

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

Tor 0.2.4.24 and 0.2.5.8-rc are out

Roger Dingledine announced new releases in both the stable and the alpha branches of the core Tor software. Clients accessing hidden services should experience faster and more robust connections as they will now send the correct rendezvous point address. “They used to send the wrong address, which would still work some of the time because they also sent the identity digest of the rendezvous point, and if the hidden service happened to try connecting to the rendezvous point from a relay that already had a connection open to it, the relay would reuse that connection”. This fix also prevents the endianness of the client’s system from being leaked to the hidden service.

The only other changes in these releases are an update of the geoip databases and the location of the gabelmoo directory authority. As usual, you can download the source code from the Tor distribution directory.

Tor Browser 3.6.6 and 4.0-alpha-3 are out

Mike Perry announced two new releases by the Tor Browser team. Tor Browser 3.6.6 includes a workaround for the bug that has sometimes been preventing the browser window from opening after an apparently successful connection to the Tor network; it also stops intermediate SSL certificates from being written to disk. In addition to these fixes, Tor Browser 4.0-alpha-3 resolves a number of issues to do with the upcoming Tor Browser updater, including the mistaken upgrade of non-English Tor Browsers to the English-language version. As this bug is only fixed in the new release, users upgrading from 4.0-alpha-2 will still experience this issue during the process. Furthermore, “meek transport users will need to restart their browser a second time after upgrade if they use the in-browser updater. We are still trying to get to the bottom of this issue”, wrote Mike.

Both releases also include important Firefox security updates, so all users should upgrade as soon as possible. See Mike’s announcements for full details, and get your copy from the project page or the distribution directory.

Tails 1.1.2 is out

The second point release in the Tails 1.1.x series was put out by the Tails team, “mainly to fix a serious flaw in the Network Security Services (NSS) library used by Firefox and other products that allows attackers to create forged RSA certificates. Before this release, users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for legitimate sites.”

Other packages affected by recently-disclosed security flaws and updated in this version include APT, bash, and GnuPG, so all Tails users should make sure to upgrade as soon as possible. If you have a running copy of Tails, you can make use of the incremental upgrades system; otherwise, head to the download page for more information.

obfs4 is ready for general deployment: bridge operators needed!

Pluggable transports, the circumvention techniques which allow users to access the Tor network from censored areas by disguising the fact that the Tor protocol is being used, are about to take another step forward with the release of obfs4, and Yawning Angel sent out a brief discussion of this new protocol.

obfs4 offers a number of developments over the obfs3 and ScrambleSuit protocols, until now the most sophisticated pluggable transports in use on the Tor network. Like ScrambleSuit, obfs4 improves on obfs3 to “provide resilience against active attackers and to disguise flow signatures”, while a safer and more efficient key-exchange process than ScrambleSuit’s should make it impossible for attackers to launch man-in-the-middle attacks based on the client/bridge shared secret.

Like its predecessors in the obfsproxy series, obfs4 is a bridge-based transport, meaning that volunteers are needed to operate relays running an implementation of the new protocol before users can take advantage of it. The current implementation, obfs4proxy, is now available to download either as source code or as a package from Debian’s unstable repositories. Those who want to try browsing over the new protocol can download Yawning’s experimental Tor Browsers, and if you’re willing to run an obfs4 bridge, please see Yawning’s message for all the relevant details — “questions, comments, and bridges appreciated”!

Miscellaneous news

Anthony G. Basile announced the release of version 20140925 of tor-ramdisk, the micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. This release includes updates to Tor, BusyBox, OpenSSL, and the Linux kernel.

As part of the current push to better understand hidden services and their use on the Tor network, Roger Dingledine asked relay operators who are “comfortable compiling Tor from git” and who “want to help investigate what fraction of Tor network load comes from hidden service use” to check out the new hs-stats git branch. This version “will collect per-thirty-minute statistics about number of circuits and number of cells your relay sees that have to do with exiting, with hidden services, with circuits where you're not the final hop, and a fourth none-of-the-above category”, which can then be posted to the appropriate ticket on the bug tracker or sent to Roger directly.

Yawning Angel sent a “friendly reminder” to ScrambleSuit bridge operators, asking them to upgrade to tor-0.2.5.x if they haven’t already: “If you are running a ScrambleSuit bridge with tor-0.2.4.x, it is useless. Users that happen to be served your ScrambleSuit bridge will not be able to connect, because the password is missing”.

Mike Perry asked relay operators, particularly those running exit relays, to contribute information about the “hardware, CPU cores, and uplink” of their servers, and how much these cost per month, in order to “put together some estimates on bounds of the current value and cost of the capacity of the Tor network as it is, and use that to generate some rough guestimates on what it would cost to grow it”.

In response to the possible integration of Tor as a “private browsing mode” by a major browser vendor, Andrew Lewman kicked off a discussion of ways in which the Tor network might be scaled up to accommodate “hundreds of millions” of extra users.

Tor help desk roundup

In Firefox, it is possible to drag a URL from the Navigation Toolbar to the Desktop in order to create a shortcut to a website, and the help desk has been asked why this functionality is disabled in Tor Browser. A Desktop shortcut to a URL, when clicked, would be opened by the operating system’s default browser, not by Tor Browser. Permitting this behavior would open the door to confusion as to whether or not a user was visiting a link over Tor, and would violate the “Proxy Obedience” requirement of the Tor Browser design.

News from Tor StackExchange

Tor StackExchange has started its site self-evaluation for September 2014. Ten questions were selected and you’re asked to review them. Are they good or is there room for improvement? Please have a look at the questions and rate them.

Jens Kubieziel noted that users mix up the terms Tor, Tor Browser and torbrowser-launcher, so he explained each of them to users of the Q&A page.


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

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!