Tor Browser 6.5a3 is released

Tor Browser 6.5a3 is now available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox including the recently disclosed extension update vulnerability. All users should upgrade as soon as possible.

This release bumps the versions of several of our components: Firefox to 45.4.0esr, Tor to and OpenSSL to 1.0.2h, HTTPS-Everywhere to 5.2.4, NoScript to Additionally we are adding Unix Domain Socket support on Linux and OSX, the about:tbupdate page giving information about the update has been improved, the referrer spoofing for .onion domains has been moved from Torbutton to C++ patches.

Note: Due to bug 20185 Tor Browser on Linux and OS X will not work correctly if the path where it is installed is too long. As a workaround you may need to move it to a directory with a shorter path.

Update (9/22 07:15 UTC): We got reports about updates failing on OS X systems. We are still investigating the problem but this is likely due to a combination of issues. For one we might have introduced a permission problem by trying to get our incremental updates working again. Secondly, unix domain socket paths for the control port that contain spaces are not working. See comment 5 in bug 20210 for a preliminary analysis and workarounds. We are sorry for the inconvenience.

Here is the full changelog since 6.5a2:

  • All Platforms
    • Update Firefox to 45.4.0esr
    • Update Tor to
    • Update OpenSSL to 1.0.2h (bug 20095)
    • Update Torbutton to
      • Bug 17334: Move referrer spoofing for .onion domains into tor-browser.git
      • Bug 17767: Make "JavaScript disabled" more visible in Security Slider
      • Bug 19995: Clear site security settings during New Identity
      • Bug 19906: "Maximizing Tor Browser" Notification can exist multiple times
      • Bug 19837: Whitelist internal URLs that Firefox requires for media
      • Bug 15852: Remove/synchronize Torbutton SOCKS pref logic
      • Bug 19733: GETINFO response parser doesn't handle AF_UNIX entries + IPv6
      • Bug 14271: Make Torbutton work with Unix Domain Socket option
      • Translation updates
    • Update Tor Launcher to
      • Bug 14272: Make Tor Launcher work with Unix Domain Socket option
      • Bug 19568: Set CurProcD for Thunderbird/Instantbird
      • Bug 19432: Remove special handling for Instantbird/Thunderbird
      • Translation updates
    • Update HTTPS-Everywhere to 5.2.4
    • Update NoScript to
    • Bug 14273: Backport patches for Unix Domain Socket support
    • Bug 19890: Disable installation of system addons
    • Bug 17334: Spoof referrer when leaving a .onion domain
    • Bug 20092: Rotate ports for default obfs4 bridges
    • Bug 20040: Add update support for unpacked HTTPS Everywhere
    • Bug 20118: Don't unpack HTTPS Everywhere anymore
    • Bug 19336+19835: Enhance about:tbupdate page
  • Android
    • Bug 19706: Store browser data in the app home directory
  • Build system
    • All platforms
      • Bug 20133: Don't apply OpenSSL patch anymore
      • Bug 19528: Set MOZ_BUILD_DATE based on Firefox version
    • OS X
      • Bug 19856: Make OS X builds reproducible again
      • Bug 19410: Fix incremental updates by taking signatures into account

Cooking with Onions: Finding the OnionBalance


This blog post is the first part of the Cooking with Onions series which aims to highlight various interesting developments on the .onion space. This particular post presents a technique for efficiently scaling busy onion services.

The need for scaling

Onion services have been around for a while. During the past few years, they have been deployed by many serious websites like major media organizations (like the Washington Post), search engines (such as DuckDuckGo) and critical Internet infrastructure (e.g. PGP keyservers). This has been a great opportunity for us, the development team, since our code has been hardened and tested by the sheer volume of clients that use it every day.

This recent widespread usage also gave us greater insights on the various scalability issues that onion service operators face when they try to take their service to the next level. More users means more load to the onion service, and there is only so much that a single machine can handle. The scalability of the onion service protocol has been a topic of interest to us for a while, and recently we've made advancements in this area by releasing a tool called OnionBalance.

So what is OnionBalance?

OnionBalance is software designed and written by Donncha O'Cearbhaill as part of Tor's Summer of Privacy 2015. It allows onion service operators to achieve the property of high availability by allowing multiple machines to handle requests for a single onion service. You can think of it as the onion service equivalent of load balancing using round-robin DNS.

OnionBalance has recently started seeing more and more usage by onion service operators! For example, the Debian project recently started providing onion services for its entire infrastructure, and the whole project is kept in line by OnionBalance.

How OnionBalance works

Consider Alice, an onion operator, who wants to load balance her overloaded onion service using OnionBalance.

She starts by setting up multiple identical instances of that onion service in multiple machines, makes a list of their onion addresses, and passes the list to OnionBalance. OnionBalance then fetches their descriptors, extracts their introduction points, and publishes a "super-descriptor" containing all their introduction points. Alice now passes to her users the onion address that corresponds to the "super-descriptor". Multiple OnionBalance instances can be run with the same configuration to provide redundancy when publishing the super descriptor.

When Bob, a client, wants to visit Alice's onion service, his Tor client will pick a random introduction point out of the super-descriptor and use it to connect to the onion service. That introduction point can correspond to any of the onion service instances, and this way the client load gets spread out.

With OnionBalance, the "super-descriptor" can be published from a different machine to the one serving the onion service content. Your onion service private key can be kept in a more isolated location, reducing the risk of key compromise.

For information on how to set up OnionBalance, please see the following article:


OnionBalance is a handy tool that allows operators to spread the load of their onion service to multiple machines. It's easy to set up and configure and more people should give it a try.

In the meanwhile, we'll keep ourselves busy coming up with other ways to scale onion services in this brave new world of onions that is coming!

Take care until the next episode :)

Tor Browser 6.0.5 is released

Tor Browser 6.0.5 is now available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox including the recently disclosed extension update vulnerability. All users should upgrade as soon as possible.

That vulnerability allows an attacker who is able to obtain a valid certificate for to impersonate Mozilla's servers and to deliver a malicious extension update, e.g. for NoScript. This could lead to arbitrary code execution. Moreover, other built-in certificate pinnings are affected as well. Obtaining such a certificate is not an easy task, but it's within reach of powerful adversaries (e.g. nation states).

Thanks to everyone who helped investigating this bug and getting a bugfix release out as fast as possible.

We are currently building the alpha and hardened bundles (6.5a3 and 6.5a3-hardened) that will contain the fix for alpha/hardened channel users. We expect them to get released at the beginning of next week. Until then users are strongly encouraged to use Tor Browser 6.0.5.

Apart from fixing Firefox vulnerabilities this release comes with a new Tor stable version (, an updated HTTPS-Everywhere (5.2.4), and fixes minor bugs.

Here is the full changelog since Tor Browser 6.0.4:

  • All Platforms
    • Update Firefox to 45.4.0esr
    • Update Tor to
    • Update Torbutton to
      • Bug 19995: Clear site security settings during New Identity
      • Bug 19906: "Maximizing Tor Browser" Notification can exist multiple times
    • Update HTTPS-Everywhere to 5.2.4
    • Bug 20092: Rotate ports for default obfs4 bridges
    • Bug 20040: Add update support for unpacked HTTPS Everywhere
  • Windows
    • Bug 19725: Remove old updater files left on disk after upgrade to 6.x
  • Linux
    • Bug 19725: Remove old updater files left on disk after upgrade to 6.x
  • Android
    • Bug 19706: Store browser data in the app home directory
  • Build system
    • All platforms
      • Upgrade Go to 1.4.3

The FBI's Quiet Plan to Begin Mass Hacking

Senator Ron Wyden delivered a speech on the floor of the Senate on Thursday calling for passage of a bill that would annul new rules for judges. These rules will give the FBI authority to hack millions of people's computers with a single search warrant, regardless of where the device is located.

The Stop Mass Hacking Act (S. 2952, H.R. 5321), which has bipartisan support, is composed of a single sentence:

"To prevent the proposed amendments to rule 41 
of the Federal Rules of Criminal Procedure from taking effect."

Wyden's bill attempts to stop the upcoming changes to Rule 41, set to take effect in less than 90 days.

The changes to Rule 41 would allow judges to grant warrants to search and seize electronic media located outside of their home districts when the location of the information is “concealed through technological means."

For instance, when a person is using Tor.

The broad search warrants allowable under these new rules will apply to people using Tor in any country—even if they are journalists, members of a legislature, or human rights activists. The FBI will be permitted to hack into a person’s computer or phone remotely and to search through and remove their data. The FBI will be able to introduce malware into computers. It will create vulnerabilities that will leave users exposed.

To quote a tweet from Daniel Shuman of the NGO Demand Progress, "Even if you like mass FBI hacking, shouldn't the Senate hold a hearing first before it automatically becomes law?"

We are at a critical point in the United States regarding surveillance law. Some public officials, like those at the US Department of Justice (the FBI is a department of DOJ), understand very well how surveillance technology works and the implications of the Rule 41 changes. But the judges who must approve these warrants under the new rules vary widely in their technical expertise and understanding of how these decisions affect the larger Constitutional issues of search and seizure. Rule 41 will allow savvy law enforcement officials to seek those judges who don't yet understand the tech.

Similarly, there are many members of Congress who don't yet understand either the technology or its impact on democratic institutions and values. Some understand that Tor and encryption are currently used by politicians, judges, and even the FBI to keep their communications private--but others do not. Some—but not all—know that privacy tools like Tor can help enforce the separation of powers by preventing one branch of government from spying on another. Some know that a back door for one good guy is eventually a back door for multiple bad guys. Many others do not.

So some US officials can take advantage of this ignorance in order to expand their power. And since the FBI works for the Department of Justice, and the Department of Justice works for the White House, Rule 41 gives new surveillance power to the Administrative branch of US government. New power over millions of people--that Congress never discussed or approved.

Why go through Congress, the reasoning goes, and risk public exposure, debate, and possible defeat, when law enforcement can tweak a rulebook and get the same new hacking power?

If you care about FBI mass hacking, urge Congress to pass the Stop Mass Hacking bill on social media with the hashtag #SMHAct (one of the better legislative hashtags).

If you are an American citizen, there is much more you can do. Here is a seemingly minor thing--but one that can have great impact. Call and leave a message with the Washington, DC, office of the US Senator from your state. Senators actually count these calls, and they influence their decisions--Perhaps they don't want to be voted out of office by the constituents they ignored.

Here is a list of Senators' phone numbers (calling is much more effective than email for this purpose):

Your call or voicemail can be very simple:

"My name is _____, I am Senator ____'s constituent in the state of ___, and I support the "Stop Mass Hacking Act." I ask Senator _____ to support The Stop Mass Hacking Act also and that it be considered during this work period. Thank you.”

You can also leave a thank you message with Senator Wyden's office--This gives Wyden more ballast to encourage his colleagues to support the bill).

If you make those calls or leave voicemails and you're on Twitter, tweet that you called your Senator using their Twitter handle and the #SMHAct hashtag. This amplifies the power of the phone call.

The Stop Mass Hacking Act has bipartisan support. Senator Steve Daines (R-Montana), along with Senator Rand Paul (R-Kentucky) Senators Tammy Baldwin (D-Wisconsin) and Jon Tester (D-Montana) are original co-sponsors of the Senate bill.

People listen to the Tor community on issues of anonymity technology. But the threat to anonymity can be just as destructive when it comes because of a small rule change--a bureaucratic sleight of hand---as when it comes through a attack on our software by a state intelligence agency. As Tor users, our threat model includes both, so our response as a community must also include both.

UPDATE: Phoning is by far most important. Then you can tweet to your Senator.

The Twitter accounts for US Senators are here: #SMHAct


Tor Messenger 0.2.0b2 is released

We are pleased to announce another public beta release of Tor Messenger. This release features a secure automatic updater and important security fixes to Instantbird. All users are highly encouraged to upgrade.

Secure Updater

This is the first release that contains ported patches from Tor Browser to securely update the application (#14388). Moving forward, Tor Messenger will prompt you when a new release is available, automatically download the update over Tor, and apply it upon restart. Keeping Tor Messenger up-to-date should now be seamless, painless, and secure.

OS X Profile Directory

In previous releases, Tor Messenger stored its profile directory inside the application bundle. This was a result of the Tor Messenger team building on the work done for Tor Browser. While normally straightforward, this caused some trouble with Mac users who said that there's a common expectation to be able to copy extracted applications to someone else's computer. This could lead to them unknowingly transferring accounts and OTR keys.

Tor Browser has since switched courses and, in the 6.0 series, it now stores its profile in ~/Library/Application\ Support/TorBrowser-Data (#13252). With that change, we can now follow suit and store the Tor Messenger profile in ~/Library/Application\ Support/TorMessenger-Data (#13861). However, this should only be case when the application is placed in /Applications. Otherwise, the profile is stored beside the application bundle.

Windows and OS X bundles are now signed

In past releases, users may have seen cumbersome and scary warnings that the Tor Messenger application is not signed by a known developer (#17452), and may not be trustworthy. We are now signing the Windows and OS X bundles with the Tor Browser developer keys.

Google Summer of Code (GSoC)

This summer, the Tor Messenger team participated in Google's Summer of Code program, mentoring a project by Vu Quoc Huy, titled "CONIKS for Tor Messenger" (#17961). CONIKS is a key management and verification system for end-to-end secure communication services, using a model called key transparency. In this model, our users' keys are managed in a publicly (and cryptographically) auditable yet privacy preserving key directory in order to provide stronger security and better usability.

Although we hope to have a prototype deployed for testing in the near future, much work remains before we can consider turning it on in production. So far, we've produced an implementation of a CONIKS keyserver and several patches to Tor Messenger to support the additional logic and interface. This has been a collaboration between researchers Marcela Melara (CONIKS' project lead) from Princeton, Ismail Khoffi from EPFL, our student Huy, and the Tor Messenger team. We'd like to thank all who participated.

Before upgrading, back up your OTR keys

You will need to back up your OTR keys to preserve them across this upgrade. Please see the steps to back them up, or consider simply generating new ones after upgrading.

Note that with the advent of the secure updater, this step will no longer be necessary in future releases. All profile data will be preserved upon automatic update, including accounts and OTR keys (#13861).


Please note that Tor Messenger is still in beta. The purpose of this release is to help test the application and provide feedback. At-risk users should not depend on it for their privacy and safety.

Linux (32-bit)

Linux (64-bit)


OS X (Mac)


The sha256sums.txt file containing hashes of the bundles is signed with the key 0xB01C8B006DA77FAA (fingerprint: E4AC D397 5427 A5BA 8450 A1BE B01C 8B00 6DA7 7FAA). Please verify the fingerprint from the signing keys page on Tor Project's website.


Here is the complete changelog since v0.1.0b6:

Tor Messenger 0.2.0b2 -- September 06, 2016

  • Mac
    • Bug 19269: Fix OS X file permissions
    • Fix OS X profile when application is not placed in /Applications

Tor Messenger 0.2.0b1 -- September 02, 2016

  • All Platforms
    • Use the THUNDERBIRD_45_3_0_RELEASE tag on mozilla-esr45
    • Use the THUNDERBIRD_45_3_0_RELEASE tag on comm-esr45
    • Bug 19053: Display plaintext in notifications
    • Bug 17363: Remove redundant Tor Messenger folders
    • Bug 14388: Secure automatic updates for Tor Messenger
    • Bug 13861: Preserve user profiles after updates
    • Update libgcrypt to 1.6.6 for CVE-2016-6316
    • Update ctypes-otr to 0.0.2
  • Linux
    • Bug 18634: Switch to building Tor Messenger on Debian Wheezy
  • Mac
    • Bug 13861: Profile directory stored in ~/Library/Application\ Support/TorMessenger-Data
    • Bug 17460: Add graphics for OS X drag and drop to Applications
    • Bug 17648: Fix update service error in error console

A New Bridge Authority

After ten years of volunteer maintenance of Tonga, Tor's bridge Authority—a piece of critical infrastructure within the Tor network—our colleague and friend, Lucky Green, a long time cypherpunk, and free speech and privacy advocate, has decided to step down from this role. Tonga's cryptographic keys will be destroyed this week. We are incredibly thankful to Lucky for all his support and selfless labour in maintaining a key component of our censorship circumvention efforts, grateful for the years we have spent working with him, and very sorry to see him go.

The Bridge Authority is a simple but essential piece of the Tor Network. Unlike the other directory authorities, the Bridge Authority does not get a vote in Tor's consensus protocol. Instead, it serves to aggregate relay descriptors which Tor Bridges send to it, checking their cryptographic validity and testing that the Bridges' ORPorts within these descriptors are reachable. It then sends these descriptors to BridgeDB, which does all the deduplication, cryptographic signature verification (again), stability calculations, pluggable transport argument validation, assignment into the hashring of each Bridge distribution mechanism, and finally distributing the Bridges to Tor clients.

Number of bridges reported by both Tonga and Bifröst during the bridge authority transition period. Graph by Karsten Loesing.

This transition does not affect Tor users, regardless of whether or not Bridges are used to connect to the Tor network. However, it is extremely important that relay operators running Bridges upgrade to tor- or tor-, which contains a patch to replace Tonga with the new Bridge Authority. Bridges which do not upgrade will cease to be distributed to new clients; however, clients which have connected to your Bridge previously will still be able to connect (at least until your Bridge's IP address, port, or fingerprint changes).

"The same thing, but made of rainbows and on fire."

As a replacement for Tonga, I am happy to announce that Greenhost has donated hardware and hosting for the new Bridge Authority, Bifröst. Bifröst is a Norse mythological bridge that connects Midgard, the mortal realm, and Asgard, the realm of the gods, and is described in the poem Grímnismál within the Poetic Edda as a burning bridge, constructed out of a rainbow whose end lies upon Himinbjorg, or "Heaven's cliffs." The name was suggested by both our colleagues Alison Macrina of the Library Freedom Project and Moritz Bartl of Despite the personal temptation to follow Nick Mathewson's suggestion to christen it after that iconic symbol of my home, I could not help but name it Bifröst, because why go with some boring normal thing, when you could have the same thing, but made of rainbows and on fire. RAINBOWS. FIRE. Clear choice.

The Tor Project is incredibly thankful to Greenhost for their generous donation of hardware, hosting, and bandwidth. In particular, I am thankful to my colleagues at Greenhost, Sacha von Geffen and Jurre van Bergen, for all the work they put into the organisation, collaboration, and technical efforts in setting the server up quickly. Working with Greenhost, as always, is a pleasure, and I would give my highest recommendations for Greenhost to those seeking an ethical, friendly, and experienced hosting provider.

Future Research and Hacking

Moving forward, there are several improvements to these systems which could be made, some requiring further research.

  1. We currently don't have any mechanism for testing the bandwidth capacity of bridge relays. Additional design complications may arise when Bridges have their own Guard relays (#7144), e.g. causing fast Bridges which select slower Guards to not utilize their full capacity. This might be navigated by adding support for bridges to do a self-bandwidth test before selecting a guard node.

  2. We also don't currently have anything that tests the reachability of the address/port for any of a Bridge's pluggable transports. Our previous attempts at a distributed/automated Bridge reachability testing system lead me to believe that there is no way to both reliably and securely, i.e., without literally burning the Bridge by attracting a censor's attention to it, test reachability in a distributed manner. Add on top a game of Russian roulette by mixing in N different pluggable transports with varying indistinguishability, authentication, and security properties merely compounds the issue, adding to the likelihood that the secrecy of the best transport a Bridge provides is reduced to that of its worst. That said, thorough analysis of the risks of a centralised system should be made, and there are likely other alternatives. For example, one might attempt to build a system which heuristically crowdsources this information from clients.

  3. There's no legitimate reason to have the Bridge Authority and BridgeDB be separate systems. It would make more sense to break apart the components into those which
    • receive descriptors
    • conduct reachability tests
    • archive all descriptors
    • access archived descriptors for which Bridges may currently be distributed to clients
    • distribute Bridges to clients in some manner.

  4. Decentralise the Bridge Authority/BridgeDB systems without simply turning a single point-of-failure into multiple points-of-failure.

Researchers and hackers interested in these problems are welcome and encouraged to contribute. If these problems interest you (or your sufficiently bright, self-directed, and motivated students!), please feel encouraged to contact me and/or our Research Director, Roger Dingledine to discuss ideas and projects moving forward.

Tor is released, with important fixes

Tor fixes an important bug related to the ReachableAddresses option in, and replaces a retiring bridge authority. Everyone who sets the ReachableAddresses option, and all bridges, are strongly encouraged to upgrade.

You can download the source from the Tor website. Packages should be available over the next week or so.

Below is a list of changes since

Changes in version - 2016-08-24

  • Directory authority changes:
    • The "Tonga" bridge authority has been retired; the new bridge authority is "Bifroest". Closes tickets 19728 and 19690.
  • Major bugfixes (client, security):
    • Only use the ReachableAddresses option to restrict the first hop in a path. In earlier versions of 0.2.8.x, it would apply to every hop in the path, with a possible degradation in anonymity for anyone using an uncommon ReachableAddress setting. Fixes bug 19973; bugfix on
  • Minor features (geoip):
    • Update geoip and geoip6 to the August 2 2016 Maxmind GeoLite2 Country database.
  • Minor bugfixes (compilation):
    • Remove an inappropriate "inline" in tortls.c that was causing warnings on older versions of GCC. Fixes bug 19903; bugfix on
  • Minor bugfixes (fallback directories):
    • Avoid logging a NULL string pointer when loading fallback directory information. Fixes bug 19947; bugfix on and Report and patch by "rubiate".

Tor is released, with important fixes

Tor continues development of the 0.2.9 series with several new features and bugfixes. It also includes an important authority update and an important bugfix from Everyone who sets the ReachableAddresses option, and all bridges, are strongly encouraged to upgrade to, or to

You can download the source from the usual place on the website.
Packages should be available over the next several days. Remember
to check the signatures!

Please note: This is an alpha release. You should only try this one if you are interested in tracking Tor development, testing new features, making sure that Tor still builds on unusual platforms, or generally trying to hunt down bugs. If you want a stable experience, please stick to the stable releases.

Below are the changes since

Changes in version - 2016-08-24

  • Directory authority changes (also in
    • The "Tonga" bridge authority has been retired; the new bridge authority is "Bifroest". Closes tickets 19728 and 19690.
  • Major bugfixes (client, security, also in
    • Only use the ReachableAddresses option to restrict the first hop in a path. In earlier versions of 0.2.8.x, it would apply to every hop in the path, with a possible degradation in anonymity for anyone using an uncommon ReachableAddress setting. Fixes bug 19973; bugfix on

  read more »

Syndicate content Syndicate content