Blogs

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

Downloads

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)

Windows

OS X (Mac)

sha256sums.txt
sha256sums.txt.asc

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.

Changelog

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-0.2.8.7 or tor-0.2.9.2.-alpha, 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 Torservers.net. 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 0.2.8.7 is released, with important fixes

Tor 0.2.8.7 fixes an important bug related to the ReachableAddresses option in 0.2.8.6, 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 0.2.8.6.

Changes in version 0.2.8.7 - 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 0.2.8.2-alpha.
  • 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 0.2.8.1-alpha.
  • Minor bugfixes (fallback directories):
    • Avoid logging a NULL string pointer when loading fallback directory information. Fixes bug 19947; bugfix on 0.2.4.7-alpha and 0.2.8.1-alpha. Report and patch by "rubiate".

Tor 0.2.9.2-alpha is released, with important fixes

Tor 0.2.9.2-alpha 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 0.2.8.7. Everyone who sets the ReachableAddresses option, and all bridges, are strongly encouraged to upgrade to 0.2.8.7, or to 0.2.9.2-alpha.

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 0.2.9.1-alpha.

Changes in version 0.2.9.2-alpha - 2016-08-24

  • Directory authority changes (also in 0.2.8.7):
    • The "Tonga" bridge authority has been retired; the new bridge authority is "Bifroest". Closes tickets 19728 and 19690.
  • Major bugfixes (client, security, also in 0.2.8.7):
    • 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 0.2.8.2-alpha.

  read more »

Tor Browser 6.0.4 is released

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

This release finally brings Tor Browser users the latest Tor stable, 0.2.8.6, and avoids pinging Mozilla's servers for system extensions.

Pinging Mozilla's servers was responsible for users getting an extension into their Tor Browser that resulted in annoying and confusing "Your Firefox is out of date" notifications on start-up (bug 19890). Thanks to Mozilla engineers, who fixed that issue as quickly as possible on their side, the extension is not shipped to Tor Browser users anymore since August 11 13:00 UTC. This takes care of getting the add-on removed as well in case it got installed into Tor Browser (as does the fix we ship in Tor Browser 6.0.4) which should have happened/is happening during the next extension update ping. For further information see the discussion in our bug tracker.

Users that are on the alpha channel or are using the hardened Tor Browser were not affected. The same goes for Tails users as far as we know.

The full changelog since Tor Browser 6.0.3 is:

Tor Browser 6.0.4 -- August 16

  • All Platforms
    • Update Tor to 0.2.8.6
    • Update NoScript to 2.9.0.14
    • Bug 19890: Disable installation of system addons

The Tor Social Contract

At The Tor Project, we make tools that help promote and protect the essential human rights of people everywhere. We have a set of guiding principles that make that possible, but for a long time, those principles were more or less unspoken. In order to ensure that project members build a Tor that reflects the commitment to our ideals, we've taken a cue from our friends at Debian and written the Tor Social Contract -- the set of principles that show who we are and why we make Tor.

Our social contract is a set of behaviors and goals: not just the promised results we want for our community, but the ways we seek to achieve them. We want to grow Tor by supporting and advancing these guidelines in the time we are working on Tor, while taking care not to undermine them in the rest of our time.

The principles can also be used to help recognize when people's actions or intents are hurting Tor. Some of these principles are established norms; things we've been doing every day for a long time; while others are more aspirational -- but all of them are values we want to live in public, and we hope they will make our future choices easier and more open. This social contract is one of several documents that define our community standards, so if you're looking for things that aren't here (e.g. something that might be in a code of conduct) bear in mind that they might exist, in a different document.

Social goals can be complex. If there is ever tension in the application of the following principles, we will always strive to place highest priority on the safety and freedom of any who would use the fruits of our endeavors. The social contract can also help us work through such tensions -- for example, there are times when we might have a need to use tools that are not completely open (contradicting point 2) but opening them would undermine our users' safety (contradicting point 6). Using such a tool should be weighed against how much it's needed to make our technologies usable (point 1). And if we do use such a tool, we must be honest about its capabilities and limits (point 5).

Tor is not just software, but a labor of love produced by an international community of people devoted to human rights. This social contract is a promise from our internal community to the rest of the world, affirming our commitment to our beliefs. We are excited to present it to you.

1. We advance human rights by creating and deploying usable anonymity and privacy technologies.

We believe that privacy, the free exchange of ideas, and access to information are essential to free societies. Through our community standards and the code we write, we provide tools that help all people protect and advance these rights.

2. Open and transparent research and tools are key to our success.

We are committed to transparency; therefore, everything we release is open and our development happens in the open. Whenever feasible, we will continue to make our source code, binaries, and claims about them open to independent verification. In the extremely rare cases where open development would undermine the security of our users, we will be especially vigilant in our peer review by project members.

3. Our tools are free to access, use, adapt, and distribute.

The more diverse our users, the less is implied about any person by simply being a Tor user. This diversity is a fundamental goal and we aim to create tools and services anyone can access and use. Someone's ability to pay for these tools or services should not be a determining factor in their ability to access and use them. Moreover, we do not restrict access to our tools unless access is superceded by our intent to make users more secure.

We expect the code and research we publish will be reviewed and improved by many different people, and that is only possible if everyone has the ability to use, copy, modify, and redistribute this information. We also design, build, and deploy our tools without collecting identifiable information about our users.

4. We make Tor and related technologies ubiquitous through advocacy and education.

We are not just people who build software, but ambassadors for online freedom. We want everybody in the world to understand that their human rights -- particularly their rights to free speech, freedom to access information, and privacy -- can be preserved when they use the Internet. We teach people how and why to use Tor and we are always working to make our tools both more secure and more usable, which is why we use our own tools and listen to user feedback. Our vision of a more free society will not be accomplished simply behind a computer screen, and so in addition to writing good code, we also prioritize community outreach and advocacy.

5. We are honest about the capabilities and limits of Tor and related technologies.

We never intentionally mislead our users nor misrepresent the capabilities of the tools, nor the potential risks associated with using them. Every user should be free to make an informed decision about whether they should use a particular tool and how they should use it. We are responsible for accurately reporting the state of our software, and we work diligently to keep our community informed through our various communication channels.

6. We will never intentionally harm our users.

We take seriously the trust our users have placed in us. Not only will we always do our best to write good code, but it is imperative that we resist any pressure from adversaries who want to harm our users. We will never implement front doors or back doors into our projects. In our commitment to transparency, we are honest when we make errors, and we communicate with our users about our plans to improve.

New alpha release: Tor 0.2.9.1-alpha

Tor 0.2.9.1-alpha is the first alpha release in the 0.2.9 development series. It improves our support for hardened builds and compiler warnings, deploys some critical infrastructure for improvements to hidden services, includes a new timing backend that we hope to use for better support for traffic padding, makes it easier for programmers to log unexpected events, and contains other small improvements to security, correctness, and performance.

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

Changes in version 0.2.9.1-alpha - 2016-08-08

  • New system requirements:
    • Tor now requires Libevent version 2.0.10-stable or later. Older versions of Libevent have less efficient backends for several platforms, and lack the DNS code that we use for our server-side DNS support. This implements ticket 19554.
    • Tor now requires zlib version 1.2 or later, for security, efficiency, and (eventually) gzip support. (Back when we started, zlib 1.1 and zlib 1.0 were still found in the wild. 1.2 was released in 2003. We recommend the latest version.)
  • Major features (build, hardening):
    • Tor now builds with -ftrapv by default on compilers that support it. This option detects signed integer overflow (which C forbids), and turns it into a hard-failure. We do not apply this option to code that needs to run in constant time to avoid side-channels; instead, we use -fwrapv in that code. Closes ticket 17983.
    • When --enable-expensive-hardening is selected, stop applying the clang/gcc sanitizers to code that needs to run in constant time. Although we are aware of no introduced side-channels, we are not able to prove that there are none. Related to ticket 17983.

  read more »

Breaking through censorship barriers, even when Tor is blocked

Download video | view on YouTube


While Tor Browser provides many security and privacy properties and features, not everyone around the world has the luxury to connect to use it. By default, Tor Browser makes all of its users look alike by spoofing UserAgent (and other methods) to avoid fingerprinting attacks. However, it doesn't hide the fact you're connecting to Tor, an open network where anyone can get the list of relays. This network transparency has many benefits, but also has a downside: Many repressive governments and authorities benefit from blocking their users from having free and open access to the internet. They can simply get the list of Tor relays and block them. This bars millions of people from access to free information, often including those who need it most. We at Tor care about freedom of access to information and strongly oppose censorship. This is why we've developed methods to connect to the network and bypass censorship. These methods are called Pluggable Transports (PTs).

Pluggable Transports are a type of bridge to the Tor network. They take advantage of various transports and make encrypted traffic to Tor look like not-interesting or garbage traffic. Unlike normal relays, bridge information is kept secret and distributed between users via BridgeDB. If you're interested in helping censored users, you can become a bridge operator. And if you're a developer and have interesting ideas on how to make new PTs or want to contribute code, we've some good documents to get you up to speed.

And finally, if you're a censored user and want to take advantage of PTs, I've good news for you. They're already included in Tor Browser and this how-to graphic should help you configure it to bypass censorship.


How to use PTs: 1-download tor-send email to gettor@torproject.org; 2 select configure 3; check my isp blocks tor option; 4 select obfs4; 5 press connect
(download png)


And of course we didn't forget to make a gif version:


How to use PTs: 1-download tor-send email to gettor@torproject.org; 2 select configure 3; check my isp blocks tor option; 4 select obfs4; 5 press connect
(download gif)



In case you need more bridges, send an email to bridges@torproject.org or visit BridgeDB website.

At the end, I'd like to thank all anonymous contributors and Vivido Studio for making this work possible.

In solidarity,
Nima Fatemi

Syndicate content Syndicate content