Tails 1.7 is out

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

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

New features

  • You can now start Tails in offline mode to disable all networking for additional security. Doing so can be useful when working on sensitive documents.

  • We added Icedove, a rebranded version of the Mozilla Thunderbird email client.

    Icedove is currently a technology preview. It is safe to use in the context of Tails but it will be better integrated in future versions until we remove Claws Mail. Users of Claws Mail should refer to our instructions to migrate their data from Claws Mail to Icedove.

Upgrades and changes

  • Improve the wording of the first screen of Tails Installer.

  • Restart Tor automatically if connecting to the Tor network takes too long. (#9516)

  • Update several firmware packages which might improve hardware compatibility.

  • Update the Tails signing key which is now valid until 2017.

  • Update Tor Browser to 5.0.4.

  • Update Tor to

Fixed problems

  • Prevent wget from leaking the IP address when using the FTP protocol. (#10364)

  • Prevent symlink attack on ~/.xsession-errors via tails-debugging-info which could be used by the amnesia user to bypass read permissions on any file. (#10333)

  • Force synchronization of data on the USB stick at the end of automatic upgrades. This might fix some reliability bugs in automatic upgrades.

  • Make the "I2P is ready" notification more reliable.

Known issues

See the current list of known issues.

Download or upgrade

Go to the download or upgrade page.

If you have been updating automatically for a while and your Tails does not boot after an automatic upgrade, you can update your Tails manually.

What's coming up?

The next Tails release is scheduled for December 15.

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

We need your help and there are many ways to contribute to Tails (donating is only one of them). Come talk to us!

Support and feedback

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

Tor Weekly News — October 31st, 2015

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

IETF reserves .onion as a Special-Use Domain Name

Several years of effort by Tor Project members and contributors bore fruit this week when the Internet Engineering Task Force, which develops and promotes voluntary standards for Internet technologies, recognized the .onion suffix as a special-use domain name.

As Jacob Appelbaum, who led the charge along with Facebook security engineer Alec Muffett, explained: “IETF name reservations are part of a lesser known process that ensures a registered Special-Use Domain Name will not become a Top Level Domain (TLD) to be sold by the Internet Corporation For Assigned Names and Numbers (ICANN).” In other words, it will not be possible for domain registrars to sell web addresses ending in .onion; if it were, it would create problems for Tor’s hidden service system, which uses that suffix to allow users to run anonymous and censorship-resistant web services accessible via the Tor Browser.

Another benefit of the name reservation is that it will now be possible to buy Extended Validation (EV) SSL certificates for .onion domains, a system which Facebook has trialled on its own popular hidden service.

“We think that this is a small and important landmark in the movement to build privacy into the structure of the Internet”, wrote Jacob. Congratulations to all those who spent time drafting this proposal and advocating for its adoption.

Tor proposal updates

Tor’s body of development proposals, documents that plan for improvements and changes in Tor’s software ecosystem, has seen some additions, updates, and reviews over the past week.

Nick Mathewson published proposal 256, which examines methods for revoking the long-lived public keys used by Tor relays and directory authorities in the event that they are compromised, or the operator believes there is a significant possibility that they have been compromised. Andrea Shepard wrote proposal 258, explaining how directory authorities could mitigate the risk of denial-of-service (DOS) attacks by classifying the types of directory requests they receive and setting thresholds for each. Nick and Andrea together published proposal 257, which identifies the different functions performed by directory authorities and examines how the risk of DOS attacks could be reduced by “isolating the security-critical, high-resource, and availability-critical pieces of our directory infrastructure from one another”.

George Kadianakis published a review of all the open proposals relevant to next-generation hidden services, giving a summary of each one along with its current status, “so that researchers and developers have easier access to them”.

Proposal 250, which specifies how directory authorities can come up with a shared random value every day, and which George describes as “a prerequisite” for all other work on next-gen hidden services, was itself updated to reflect changes in the implementation, which is almost finished, as David Goulet explained. Finally, Tim Wilson-Brown (teor) published a revised version of the as-yet unnumbered proposal for “rendevous single onion services”, “an alternative design for single onion services, which trade service-side location privacy for improved performance, reliability, and scalability”.

If you have any comments on these or other Tor proposals, feel free to post your thoughts to the tor-dev mailing list.

Miscellaneous news

The Tor BSD Diversity Project, “an effort to extend the use of the BSD Unixes into the Tor ecosystem, from the desktop to the network”, announced the release of an OpenBSD port of Tor Browser 5.0.3, its sixth Tor Browser release for BSD systems. See attila’s announcement for download instructions, as well as a report on the TDP’s other development and advocacy activities.

Tor’s Metrics team, “a group of Tor people who care about measuring and analyzing things in the public Tor network”, now has its own public mailing list and wiki page, as Karsten Loesing announced. There is a simple step to complete before you can post freely to the list, but anyone interested in “measurements and analysis” is welcome to listen in on discussions, and to check the team’s roadmap and workflow on the wiki page.

“In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention”, Yawning Angel drafted a rewrite of the pluggable transports spec document. No behavior changes are specified in this rewrite, but “unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented”.

Simone Bassano published a report on the OONI hackathon that took place in Rome at the start of October. A working beta version of MeasurementKit and progress on NetworkMeter, as well as ways to make use of censorship data, were among the outcomes.

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

Tor Messenger Beta: Chat over Tor, Easily

Today we are releasing a new, beta version of Tor Messenger, based on Instantbird, an instant messaging client developed in the Mozilla community.

What is it?

Tor Messenger is a cross-platform chat program that aims to be secure by default and sends all of its traffic over Tor. It supports a wide variety of transport networks, including Jabber (XMPP), IRC, Google Talk, Facebook Chat, Twitter, Yahoo, and others; enables Off-the-Record (OTR) Messaging automatically; and has an easy-to-use graphical user interface localized into multiple languages.

What it isn't...

Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor.

We are also excited about systems like Pond and Ricochet, which try to solve this problem, and would encourage you to look at their designs and use them too.

Why Instantbird?

We considered a number of messaging clients: Pidgin, Adam Langley's xmpp-client, and Instantbird. Instantbird was the pragmatic choice -- its transport protocols are written in a memory-safe language (JavaScript); it has a graphical user interface and already supports many natural languages; and it's a XUL application, which means we can leverage both the code (Tor Launcher) and in-house expertise that the Tor Project has developed working on Tor Browser with Firefox. It also has an active and vibrant software developer community that has been very responsive and understanding of our needs. The main feature it lacked was OTR support, which we have implemented and hope to upstream to the main Instantbird repository for the benefit of all Instantbird (and Thunderbird) users.

Current Status

Today we are releasing a beta version with which we hope to gain both usability and security related feedback. There have been three previous alpha releases to the mailing lists that have already helped smooth out some of the rougher edges.

Downloads (Updated)

Linux (32-bit)

Linux (64-bit)

Windows (UPDATED)



The sha256sums.txt file containing hashes of the bundles is signed with the key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391).


  • On Linux, extract the bundle(s) and then run: ./start-tor-messenger.desktop
  • On OS X, copy the Tor Messenger application from the disk image to your local disk before running it.
  • On all platforms, Tor Messenger sets the profile folder for Firefox/Instantbird to the installation directory.

  • Note that as a policy, unencrypted one-to-one conversations are not allowed and your messages will not be transmitted if the person you are talking with does not have an OTR-enabled client. You can disable this option in the preferences to allow unencrypted communication but doing so is not recommended.

Source Code

We are doing automated builds of Tor Messenger for all platforms.

The Linux builds are reproducible: anyone who builds Tor Messenger for Linux should have byte-for-byte identical binaries compared with other builds from a given source. You can build it yourself and let us know if you encounter any problems or cannot match our build. The Windows and OS X builds are not completely reproducible yet but we are working on it.

What's to Come

Our current focus is security, robustness and user experience. We will be fixing bugs and releasing updates as appropriate, and in the future, we plan on pairing releases with Mozilla's Extended Support Release (ESR) cycle. We have some ideas on where to take Tor Messenger but we would like to hear what you have to say. Some possibilities include:

How To Help

Give it a try and provide feedback, requests, and file bugs (choose the "Tor Messenger" component). If you are a developer, help us close all our tickets or help us review our design doc. As always, we are idling on IRC in #tor-dev (OFTC) (nicks: arlolra; boklm; sukhe) and subscribed to the tor-talk/dev mailing lists.

Please note that this release is for users who would like to help us with testing the product but at the same time who also understand the risks involved in using beta software.

Thanks and we hope you enjoy Tor Messenger!

Update: For Windows 10 (and some Windows 7, 8) users who were experiencing an issue in Tor Messenger where it wouldn't start, we have updated the download links above with a newer version that fixes the problem described in bug 17453.

Landmark for Hidden Services: .onion names reserved by the IETF

The Internet Engineering Task Force (IETF), the body that sets standards for the Internet, has formally recognized .onion names. We think that this is a small and important landmark in the movement to build privacy into the structure of the Internet. This standardization work for .onion is joint work between Facebook and the Tor Project amongst others in an effort to help secure users everywhere.

Over the last few years, The Tor Project has been working with other members of the Peer to Peer community led by Dr. Christian Grothoff, founder of the GNUnet project to register several Special-Use Domain Names. IETF name reservations are part of a lesser known process that ensures a registered Special-Use Domain Name will not become a Top Level Domain (TLD) to be sold by the Internet Corporation For Assigned Names and Numbers (ICANN). Special-Use Domain Names have special considerations documented as part of their registration. Some of these names may sound familiar, such as .local which is widely deployed by Apple and others for Multicast Domain Name Service (mDNS).

During our long journey which began in the Summer of Snowden, Alec Muffett and I were encouraged to split out .onion from the list of other peer to peer names and to make a separate draft to register .onion as a Special-Use Domain Name. In this draft we listed security and privacy considerations that we believe will help to protect end users from targeted and mass-surveillance. We're happy to say that the first name reservation was just published as RFC7686.

Our internet standard reflects on considerations for handling .onion names on the internet as well as officially reserving .onion as a Special-Use-Domain-Name with the Internet Assigned Numbers Authority (IANA). With this registration, it is should also be possible to buy Extended Validation (EV) SSL/TLS certificates for .onion services thanks to a recent decision by the Certification Authority Browser Forum. We hope that in the future we'll see easy to issue certificates from the Let's Encrypt project for .onion services. We also hope to see more Peer to Peer names such as .gnu registered as Special-Use-Domain-Names by the IETF.

It is now easier than ever to deploy, share and use Tor Hidden Services.

We greatly enjoyed our efforts with the IETF and plan to continue actively participate with the IETF in the future. We'd also like to thank everyone who helped with this process including but not limited to Mark Nottingham, Roger Dingledine, Linus Nordberg, Seth David Schoen, Leif Ryge, Helekin Wolf, Matthias Wachs and Dr. Christian Grothoff.

Tor Weekly News — October 24th, 2015

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

Tails 1.6 is out

Tails 1.6, a minor release of the anonymous live operating system, was put out one month ago on September 22, following a Firefox security announcement. As well as Tor Browser 5.0.3, this release includes updates to key software, and fixes to important security issues. All Tails users must upgrade as soon as possible, if they haven’t already done so; see the announcement for download instructions.

Orfox reaches Beta

The Orfox team released the first beta version of the Tor Browser-like Android web browser on Google Play and the Guardian Project F-Droid repos. This is a public testing release, so as usual please do not rely on it for strong anonymity just yet.

If you want to stay updated with this effort, keep an eye on the team’s homepage. The project is trying to improve communications with both Mozilla and the Tor Browser team in order to have as much work merged upstream as possible!

Final Tor Summer of Privacy reports

The “southern hemisphere” schedule for Tor’s first-ever Summer of Privacy came to an end, and the two remaining students submitted their final progress reports. Israel Leiva’s revamp of GetTor, the alternative Tor software distributor, now supports additional content delivery networks including Github and Google Drive, xmpp requests (with Twitter compatibility on the way), multiple languages, and more. Israel will continue to work on GetTor as a regular contributor, so expect more progress reports from this important project.

Cristóbal Leiva’s relay web status dashboard, erebus, now includes core frontend and backend functionality, along with a basic UI and full code documentation. Cristóbal will also be continuing to work on his project over the coming months. Congratulations to both on finishing the season with their projects in such good shape!

Monthly status reports for September 2015

Tor Project members submitted their regular monthly status reports for September. Griffin Boyce gave an account of his activities over the summer; Pearl Crescent worked on development of Tor Browser; Karsten Loesing helped organize the Tor Metrics team and develop the network tools; Sebastian Hahn worked on donation- and outreach-related website improvements; Georg Koppen coded and reviewed for the latest Tor Browser releases; Damian Johnson worked on Nyx, Stem, DocTor, and code review for metrics-lib; Leiah Jansen completed graphic designs for Tor’s website and for a campaign T-shirt; Colin Childs organized the new support team and coordinated translations; the Tor Browser team put out new alpha and stable releases; and George Kadianakis worked on Tor network security.

George also sent out the report for SponsorR, while Isabela Bagueros sent out a progress report for SponsorU.

Miscellaneous news

David Fifield sent out the regular summary of costs for the meek pluggable transport. David also announced that the Microsoft Azure backend for meek is now rate-limited to the same speed as the Amazon and Google bridges, as the free grant has expired.

Karsten Loesing announced that the upcoming version 3.0 of the Onionoo protocol will support searching for relays by space-separated fingerprints (e.g. “9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31”) in addition to unseparated ones.

There is currently no standard definition of “membership” in the Tor Project, although there are various “membership-like” features such as internal mailing lists, LDAP accounts, and email addresses. Now that the Tor community is growing much more rapidly, a discussion was held at the recent Tor dev meeting to try and come up with some criteria against which a contributor can be categorized as a Tor Project “member”. Discussion is still ongoing, but a summary of the ideas so far is available on the wiki.

On Thursday, Jacob Appelbaum, Trevor Paglen, and Leif Ryge unveiled the latest exhibit at the Edith-Russ-Haus für Medienkunst in Oldenburg, Germany — an “Autonomy Cube”, comprising a fast Tor exit relay housed in a transparent case. Until January 3rd, visitors to the gallery can use the Cube’s network to access the Internet over Tor, or just contemplate all the encrypted traffic passing right under their noses on its way around the world. In the basement below the exhibition space, a reading room and video gallery will explore some of the installation’s themes in greater depth, and the whole exhibition will be accompanied by a book of essays.

This issue of Tor Weekly News has been assembled by Harmony, Lunar, Amogh Pradeep, teor, Karsten Loesing, and the Tails developers.

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

Tor is the second release candidate in the 0.2.7 series. It fixes some important memory leaks, and a scary-looking (but mostly harmless in practice) invalid-read bug. It also has a few small bugfixes, notably fixes for compilation and portability on different platforms. If no further significant bounds are found, the next release will the the official stable release.

NOTE: This is a release candidate. We think we've squashed most of the bugs, but there are probably a few more left over.

You can download the source from the usual place on the website.
Packages should be up in a few days.

Changes in version - 2015-10-21
  • Major bugfixes (security, correctness):
    • Fix an error that could cause us to read 4 bytes before the beginning of an openssl string. This bug could be used to cause Tor to crash on systems with unusual malloc implementations, or systems with unusual hardening installed. Fixes bug 17404; bugfix on
  • Major bugfixes (correctness):
    • Fix a use-after-free bug in validate_intro_point_failure(). Fixes bug 17401; bugfix on

  read more »

Tor Open Hack Day in Berlin (for everyone)


We are very happy to tell you that the Tor meeting in Berlin is currently underway!

During the past days we've been busy discussing the future of Tor as an organization and designing the protocols and features that we want to see in the future.

We would like to inform you that tomorrow (Thursday, October 1st) we will be
having an open day where everyone is welcome to come and discuss Tor
with us. People interested in Tor are welcome regardless of their
background or skills.

The meeting is taking place at Betahaus in Berlin all day, and you can find more information in the wiki.

Looking forward to see you here!

Thank you!

Tor is released

Tor is the first release candidate in the 0.2.7 series. It contains numerous usability fixes for Ed25519 keys, safeguards against several misconfiguration problems, significant simplifications to Tor's callgraph, and numerous bugfixes and small features.

This is the most tested release of Tor to date. The unit tests cover 39.40% of the code, and the integration tests (accessible with "make test-full-online", requiring stem and chutney and a network connection) raise the coverage to 64.49%.

NOTE: This is a release candidate. We think we've squashed most of the bugs, but there are probably a few more left over.

Changes in version - 2015-09-25

  • Major features (security, hidden services):
    • Hidden services, if using the EntryNodes option, are required to use more than one EntryNode, in order to avoid a guard discovery attack. (This would only affect people who had configured hidden services and manually specified the EntryNodes option with a single entry-node. The impact was that it would be easy to remotely identify the guard node used by such a hidden service. See ticket for more information.) Fixes ticket 14917.
  • Major features (Ed25519 keys, keypinning):
    • The key-pinning option on directory authorities is now advisory- only by default. In a future version, or when the AuthDirPinKeys option is set, pins are enforced again. Disabling key-pinning seemed like a good idea so that we can survive the fallout of any usability problems associated with Ed25519 keys. Closes ticket 17135.

  read more »

Syndicate content