This release fixes many security issues and users should upgrade as soon as possible.
We installed OnionShare, a tool for anonymous file sharing.
We enabled the circuit view in Tor Browser.
Upgrades and changes
Upgrade Tor to 0.2.9.9.
Upgrade Tor Browser to 6.5.
Upgrade Linux to 4.8. This should improve the support for newer hardware (graphics, Wi-Fi, etc.)
Upgrade Icedove to 45.6.0.
Replace AdBlock Plus with uBlock Origin.
Configure the APT package manage to use Debian's Onion services.
Install the AMDGPU display driver. This should improve the support for newer AMD graphics adapters.
Renamed the Boot Loader Menu entries from "Live" to "Tails", and replaced the confusing "failsafe" wording with "Troubleshooting Mode".
Add support for exFAT.
Remove Nyx (previously called arm).
Rewrite Tor control port filter entirely. Now Tails can safely support OnionShare, the circuit view of Tor Browser, and similar. This also enabled Whonix to replace their own similar piece of software with this one.
- Made OnionCircuits compatible with the Orca screen reader.
For more details, read our changelog.
None specific to this release.
See the list of long-standing issues.
Get Tails 2.10
To install, follow our installation instructions.
To upgrade, an automatic upgrade is available from 2.7 and 2.9.1 to 2.10.
If you cannot do an automatic upgrade or if you fail to start after an automatic upgrade, please try to do a manual upgrade.
What's coming up?
Tails 2.11 is scheduled for March 3rd.
Have a look at our roadmap to see where we are heading to.
Support and feedback
For support and feedback, visit the Support section on the Tails website.
Tor 0.3.0.2-alpha fixes a denial-of-service bug where an attacker could cause relays and clients to crash, even if they were not built with the --enable-expensive-hardening option. This bug affects all 0.2.9.x versions, and also affects 0.3.0.1-alpha: all relays running an affected version should upgrade.
Tor 0.3.0.2-alpha also improves how exit relays and clients handle DNS time-to-live values, makes directory authorities enforce the 1-to-1 mapping of relay RSA identity keys to ED25519 identity keys, fixes a client-side onion service reachability bug, does better at selecting the set of fallback directories, and more.
You can download the source code from https://dist.torproject.org/ but most users should wait for the upcoming 7.0a Tor Browser alpha release, or for their upcoming system package updates.
Changes in version 0.3.0.2-alpha - 2017-01-23
- Major bugfixes (security, also in 0.2.9.9):
- Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes--and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.
- Major features (security):
- Change the algorithm used to decide DNS TTLs on client and server side, to better resist DNS-based correlation attacks like the DefecTor attack of Greschbach, Pulls, Roberts, Winter, and Feamster. Now relays only return one of two possible DNS TTL values, and clients are willing to believe DNS TTL values up to 3 hours long. Closes ticket 19769.
Tor 0.2.9.9 fixes a denial-of-service bug where an attacker could cause relays and clients to crash, even if they were not built with the --enable-expensive-hardening option. This bug affects all 0.2.9.x versions, and also affects 0.3.0.1-alpha: all relays running an affected version should upgrade.
This release also resolves a client-side onion service reachability bug, and resolves a pair of small portability issues.
You can download the source code from https://dist.torproject.org/ but most users should wait for the upcoming Tor Browser release, or for their upcoming system package updates.
Changes in version 0.2.9.9 - 2017-01-23
- Major bugfixes (security):
- Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes -- and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.
- Major bugfixes (client, onion service):
- Fix a client-side onion service reachability bug, where multiple socks requests to an onion service (or a single slow request) could cause us to mistakenly mark some of the service's introduction points as failed, and we cache that failure so eventually we run out and can't reach the service. Also resolves a mysterious "Remote server sent bogus reason code 65021" log warning. The bug was introduced in ticket 17218, where we tried to remember the circuit end reason as a uint16_t, which mangled negative values. Partially fixes bug 21056 and fixes bug 20307; bugfix on 0.2.8.1-alpha.
- Minor features (geoip):
- Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2 Country database.
- Minor bugfixes (portability):
- Avoid crashing when Tor is built using headers that contain CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix on 0.2.9.1-alpha.
- Fix Libevent detection on platforms without Libevent 1 headers installed. Fixes bug 21051; bugfix on 0.2.9.1-alpha.
The Tor Project is looking for a Communications Director!
This senior level position will report directly to the Executive Director and will be part of the organization's leadership team. The Communications Director will set and guide the strategy for all communications and public relations messages to consistently articulate the Tor Project's mission. This job includes working closely with this diverse, international community of people who make Tor and related software products. This is a hands-on position for a highly skilled communications professional.
This is a full-time position. The Tor Project’s main office is in Seattle, and we’d be delighted to supply a desk for the Communications Director there, however, this job can be done remotely. Knowledge of media and press contacts within the United States is essential.
The job description, including instructions on how to apply, can be viewed here: https://www.torproject.org/about/jobs-comm-director.html.en
If you know someone who would be awesome at this job, please direct them to the job posting!
carml is a command-line, pipe-friendly tool for exploring and controlling a running Tor daemon. Most of the sub-commands will be interesting to developers and tinkerers; a few of these will be interesting to end users. This post concentrates on the developers and tinkerers.
carml is a Python program written using Twisted and my library txtorcon. If you're familiar with Python, create a new virtualenv and pip install carml. There are more verbose install instructions available. Once this works, you should be able to type carml and see the help output.
Connecting to Tor
carml works somewhat like git, in that a normal invocation is carml followed by some global options and then a sub-command with its own options. The most-useful global option is --connect <endpoint> which tells carml how to connect to the control-port. Technically this can be any Twisted client endpoint-string but for Tor will be one of tcp:<port> (or simply a port) or unix:/var/run/tor/control for a unix-socket.
For Tor Browser Bundle, use carml --connect 9151. Typically a "system" Tor is reachable at carml --connect 9051 or carml --connect unix:/var/run/tor/control. You may need to enable the control-port in the configuration and re-load (or re-start) Tor. More details are in the documentation.
The most interesting general purpose command is probably carml monitor -- try running it for a while and you can see what your Tor client is doing. This gives some good insight into Tor behavior.
A (very basic) usage graph is available via carml graph to see what bandwidth you're using (this needs work on the scaling -- PRs welcome!)
Sometimes, you want to use a particular circuit. For example, you're trying to confirm some possibly-nefarious activity of an Exit. We can combine the carml circ and carml stream commands:
carml circ --build "*,*,4D08D29FDE23E75493E4942BAFDFFB90430A81D2"
This means make a 3-hop circuit through any entry-guard, any middle and then one particular exit (identified by ID). You can*= identify via name (only if it's unique!) but hashes are highly recommended. Of course, you could explicitly choose the other hops as well. Note that the stars still leave the selection up to carml / txtorcon which cannot (and does not) use Tor's exact selection algorithm.
Next, you'll want to actually attach circuits to that stream. It will have printed out something like "Circuit ID 1234". Now we can use carml stream:
carml stream --attach 1234
This will cause all new streams to be attached to circuit 1234 (until we exit the carml stream command). In another terminal, try torsocks curl https://www.torproject.org to visit Tor Project's web site via your new circuit. Once you kill the above carml stream command, Tor will select circuits via its normal algorithm once again.
Note that it's not currently possible to attach streams destined for onion services (this is a Tor limitation, see connection_edge.c).
The control protocol reveals all Tor events, which includes INFO and DEBUG logging events. This allows you to easily turn on DEBUG and INFO logging via the carml events command:
carml events INFO DEBUG
This can of course be piped through grep or anything else. You can give a --count to carml events, which is useful for some of the other events.
For example, if you want to "do something" every time a new consensus document is published, you could do this:
carml events --once NEWCONSENSUS
This will wait until exactly one NEWCONSENSUS event is produced, dump the contents of it to stdout (which will be the new consensus) and exit. Using a bash script that runs the above (maybe piped to /dev/null) you can ensure a new consensus is available before continuing.
Events that Tor emits are documented in torspec section 4.1. You can use carml to list them, with carml events --list.
Another example might be that you want to ensure your relay is still listed in the consensus every hour. One way would be to schedule a cron-job shortly before the top of each hour which does something like:
carml events --once NEWCONSENSUS | grep
# log something useful if grep didn't find anything
You can issue a raw control-port command to Tor via the carml cmd sub-command. This takes care of authentication, etc. and exits when the command succeeds (or errors). This can be useful to test out new commands under development etc (as the inputs / outputs are not in any way validated).
Every argument after cmd is joined back together with spaces before being sent to Tor so you don't have to quote things.
carml cmd getinfo info/names carml cmd ADD_ONION NEW:BEST Port=1234
Briefly, the commands intended to be "end-user useful" are:
carml pastebin: create a new hidden service and serve a directory, single file, or stdin at it. You can combine with carml copybin or simply torsocks curl ... on the other side. Still an "exercise to the reader" to securely distribute the address.
carml tbb: download, verify and run a new Tor Browser Bundle. This pins the public-key of torproject.org and bundles the keys of likely suspects that sign the bundles. It is less useful now that TBB auto-updates.
carml newid: sends the NEWNYM signal, which clears the DNS cache and causes Tor to not re-use any existing circuits for new requests.
carml monitor shows you what Tor is doing currently. Similarly, carml graph shows you just the current in/out bandwidth.
Commands that can provide hours of entertainment include:
- carml xplanet
- carml tmux
I hope you find carml useful. Suggestions, bugs, and fixes all welcome on carml's GitHub page.
If you haven’t noticed already, https://metrics.torproject.org/ has a new look. The underlying data, graphing engine, and graphs remain the same.
The goal for this project was to make Tor metrics easier to use and more useful. Our process involved usability inspections, feature brainstorming, rough wireframes, and iterative prototypes. This page documents our process in detail.
We restructured, redesigned, and added content to:
- Alleviate pain points in using the interface for better workflow and navigation.
- Aggregate resources for journalists, developers, relay operators, and researchers.
- Increase compatibility with phones and tablets through responsive design.
It’s truly a place where you can learn interesting facts about the Tor network! We’re especially excited about the news page, which lists various world events with measured anomalies. We hope that the operation, development, and research pages help our many valued Tor community members to find the resources they need. Feel free to email email@example.com with suggestions.
This work was sponsored by Mozilla's Open Source Support. The objectives were to 1) determine the usability of Tor Metrics and 2) address the most pressing usability issues identified (milestone 6.1 and 6.2 of this contract).
Throughout the month of December, we've highlighted a few of our fellow travelers on the road to Internet freedom in a series of blog posts titled "Tor at the Heart." We wanted to show some of the many other projects out there and their connection to us. Just like a heart, Tor helps to fortify these projects as they provide Internet freedom around the world.
This past year we saw very dangerous trends of Internet censorship growing around the world. Activists in Brazil, China, Greece, India, Indonesia, Iran, Russia, Saudi Arabia, Sudan, and Turkey all experienced serious censorship events. The entire African continent saw a spike of censorship events, especially in Uganda, Chad, Ethiopia, Zimbabwe, Congo and Burundi.
Technological tools like Tor are often the only way people within those countries can communicate to the outside world.
Tor is also important for those of us lucky enough to live in countries without major censorship events. Journalists use Tor to communicate more safely with whistleblowers and dissidents. Everyday people use Tor to keep their Internet activities concealed from advertisers, ISPs, and web sites. Tor is important for anyone who doesn't want their browsing habits linked to them.
2016 has been a very busy year at the Tor Project. We created our own UX team to improve our tools usability, we fixed zero-days in less than 12 hours, we have started to apply very strong sandboxing to Tor Browser, we kicked off the next generation of onion services project, and we have done many other important updates on our network and applications.
And 2017 is shaping up to be even more intense. We are working to deploy new features, including better mobile connectivity and better visualizations of our data so that others can easily explore and learn from them. We are working to improve the user interface on our website and various apps. And we’re working on better ways to safeguard our users, including sandboxing Tor at the application level and investigating quantum computing.
As we wind down our 2016 end-of-year fundraising campaign, won't you take a minute to contribute a financial donation? Giving is easy, and you'll get the warm glow of knowing that you've done your small part to help someone in an oppressive part of the world be able to get her story out to the rest of us. We'll even throw in a t-shirt and/or other swag, if you choose, so you can show the world how cool you are and that you care about digital freedom.
Thanks for your help. Here's wishing you and yours a healthy, happy 2017!
During the month of December, we're highlighting other organizations and projects that rely on Tor, build on Tor, or are accomplishing their missions better because Tor exists. Check out our blog each day to learn about our fellow travelers. And please support the Tor Project! We're at the heart of Internet freedom.
Firefox <3 Tor Browser
by Ethan Tseng and Richard Barnes
If you’ve used Tor, you’ve probably used Tor Browser, and if you’ve used Tor Browser you’ve used Firefox. By lines of code, Tor Browser is mostly Firefox -- there are some modifications and some additions, but around 95% of the code in Tor Browser comes from Firefox. The Firefox and Tor Browser teams have collaborated for a long time, but in 2016, we started to take it to the next level, bringing Firefox and Tor Browser closer together than ever before. With closer collaboration, we’re enabling the Tor Browser team to do their jobs more easily, adding more privacy options for Firefox users, and making both browsers more secure.
The Tor Browser team builds Tor Browser by taking Firefox ESR and applying some patches to it. These changes add valuable privacy features for Tor Browser users, but having these changes also means that every time the Tor Browser team wants to use a new version of Firefox, they have to update the patches to work with the new version. These updates take up a substantial fraction of the effort involved in producing Tor Browser.
In 2016, we started an effort to take the Tor Browser patches and “uplift” them to Firefox. When a patch gets uplifted, we take the change that Tor Browser needs and we add it to Firefox in such a way that it’s disabled by default, but can be enabled by changing a preference value. That saves the Tor Browser team work, since they can just change preferences instead of updating patches. And it gives the Firefox team a way to experiment with the advanced privacy features that Tor Browser team is building, to see if we can bring them to a much wider audience.
Our first major target in the uplift project was a feature called First Party Isolation, which provides a very strong anti-tracking protection (at the risk of breaking some websites). Mozilla formed a dedicated team to take the First Party Isolation features in Tor Browser and implement them in Firefox, using the same technology we used to build the containers feature. The team also developed thorough test and QA processes to make sure that the isolation in Firefox is as strong as what’s in Tor Browser -- and even identified some ways to add even stronger protections. The Mozilla team worked closely with the Tor Browser team, including weekly calls and an in-person meeting in September.
First Party Isolation will be incorporated in Firefox 52, the basis for the next major version of Tor Browser. As a result, the Tor Browser team won’t have to update their First Party Isolation patches for this version. In Firefox, First Party Isolation is disabled by default (because of the compatibility risk), but Firefox users can opt in to using First Party Isolation by going to about:config and setting “privacy.firstparty.isolate” to “true”.
We’re excited to continue this collaboration in 2017. Work will start soon on uplifting a set of patches that prevent various forms of browser fingerprinting. We’ll also be looking at how we can work together on sandboxing, building on the work that Yawning Angel has done for Tor Browser and the Firefox sandboxing features that are scheduled to start shipping in early 2017.
Finally, we should recognize the value of the continued collaboration between Mozilla and the Tor Project with regard to security vulnerabilities. The importance of this collaboration was on display only a few weeks ago, when we were both simultaneously notified of a zero-day exploit targeted at Tor Browser using a vulnerability in Firefox. Working together, we were able to develop, test, and ship a fix to both browsers in under 24 hours.
The collaboration between the Firefox and Tor Browser teams is a great example of how Mozilla’s principles of openness and participation can help advance security and privacy in the Internet. We’re proud of all we’ve accomplished together with the Tor Project in 2016, and we’re looking forward to continuing to making the web more secure and more private.