Blogs

Tor 0.3.0.6 is released: a new series is stable!

Tor 0.3.0.6 is the first stable release of the Tor 0.3.0 series.

With the 0.3.0 series, clients and relays now use Ed25519 keys to authenticate their link connections to relays, rather than the old RSA1024 keys that they used before. (Circuit crypto has been Curve25519-authenticated since 0.2.4.8-alpha.) We have also replaced the guard selection and replacement algorithm to behave more robustly in the presence of unreliable networks, and to resist guard- capture attacks.

This series also includes numerous other small features and bugfixes, along with more groundwork for the upcoming hidden-services revamp.

Per our stable release policy, we plan to support the Tor 0.3.0 release series for at least the next nine months, or for three months after the first stable release of the 0.3.1 series: whichever is longer. If you need a release with long-term support, we recommend that you stay with the 0.2.9 series.

If you build Tor from source, you can find it at the usual place on the website. Packages should be ready over the next weeks, with a Tor Browser release in late May or early June.

Below are the changes since 0.2.9.10. For a list of only the changes since 0.3.0.5-rc, see the ChangeLog file.

Changes in version 0.3.0.6 - 2017-04-26

  • Major features (directory authority, security):
    • The default for AuthDirPinKeys is now 1: directory authorities will reject relays where the RSA identity key matches a previously seen value, but the Ed25519 key has changed. Closes ticket 18319.
  • Major features (guard selection algorithm):
    • Tor's guard selection algorithm has been redesigned from the ground up, to better support unreliable networks and restrictive sets of entry nodes, and to better resist guard-capture attacks by hostile local networks. Implements proposal 271; closes ticket 19877.

  read more »

Transparency, Openness, and our 2015 Financials

After completing the standard audit, our 2015 state and federal tax filings are available. We publish all of our related tax documents because we believe in transparency.

I'm sorry for the delay in posting them: we had everything ready in December, but we had a lot going on at the end of the year (if you haven't seen it yet, check out the Tor at the Heart of Internet Freedom blog post series!), and then time got away from me after the new year.

But the delay brings you something new! Linus Nordberg, one of our new board members, has gathered together a bunch of corporate documents, like the Articles of Organization from founding the organization, our Form 1023 where we applied for non-profit status, and our IRS determination letter where they confirmed it. I've put links to these documents on the same financials page.

From a development perspective, transparency doesn't just mean that we show you our source code (though of course we do). The second layer to transparency is publishing specifications to explain what we thought we implemented in the source code. And the layer above that is publishing design documents and research papers to explain why we chose to build it that way, including analyzing the security implications and the tradeoffs of alternate designs. The reason for all these layers is to help people evaluate every level of our system: whether we chose the right design, whether we turned that design into a concrete plan that will keep people safe, and whether we correctly implemented this plan. Tor gets a huge amount of analysis and attention from professors and university research groups down to individual programmers around the world, and this consistent peer review is one of our core strengths over the past decade.

Some observations to help you read through the 2015 financial documents:

  • Tor's annual revenue in 2015 was up from 2014, at almost $3.3 million. That's good news because it shows our stability in the year where I was interim executive director. At the same time, you should be careful reading too much into yearly (calendar) numbers, because they can vary quite a bit if, say, we finish a big milestone on Dec 15 vs on Jan 15. So you really want to look at many years at a time—and by that metric, we're doing ok.
  • Tor's budget remains modest considering the number of people involved and the impact we have. And it is dwarfed by the budgets that our adversaries are spending to make the world a more dangerous and less free place.
  • Income from individual donations and other non-government things is higher, and also a higher percentage, in 2015 than 2014, but it's still in the 10-15% range. We have more work to do.
  • Check out the comment sections on the previous posts for previous years' versions of the usual "omg government funding" and "omg transparency" discussions. You might find this comment more useful than the rest.
  • A brief crash course on two common contract models for organizations that take government funding: Some of our funding (NSF, State Dept) is what's called the "cost reimbursement" model, where we have to show that we've spent the money in order to get paid (which is designed to make sure organizations spend the money in the way they've agreed to spend it), whereas others of our funding (RFA/OTF, SRI) is what's called the "milestone based" model, where we give the funder a set of deliverables and prices, and when we tell them a deliverable is done, they pay us that amount. The milestone based model gives us more flexibility to do all the things that need to get done (e.g. we can choose prices that accurately reflect the maintenance costs too), but it can also be more risky because it's on us if we underestimate costs.
  • More generally, I should take a brief moment to explain how funding proposals work, for those who worry that governments come to us wanting to pay us to do something bad. The way it works is that we try to find groups with funding for the general area that we want to work on, and then we go to them with a specific plan for what we'd like to do and how much it will cost, and if we're lucky they say ok. There is never any point where somebody comes to us and says "I'll pay you $X to do Y."
  • In 2015 we counted $498000 in "donated services", that is, volunteers helping with translations, website hosting, and so on. So far we have been quite limited in what donated services we count, because our past accounting people told us to be conservative. Other people have told us that we don't have to be that conservative, so I am excited to try harder in future financial documents to count many more aspects of volunteering—activism and education, sysadmin time, relay operation, finding and analyzing bugs, providing user support, etc.

In closing, remember that there are many different ways to get involved with Tor, and we need your help. For examples, you can donate, volunteer, and run a Tor relay.

Discontinuing the hardened Tor Browser series

When we started with the hardened Tor Browser series 18 months ago, we had two main purposes in mind:

  • It should give users an even more secure Tor Browser, especially at higher security levels where JavaScript is partially or completely disabled.
  • It should help us to identify issues earlier, therefore allowing to develop and backport fixes to the Tor Browser alpha and stable series.

The hardened series was a non-stable series on purpose, aimed at experienced users. The reason for that was not only the heavy performance impact of the hardening and debugging features we deployed. Rather, the impact of mixing both in Tor Browser seemed to be not well understood either: for example, does compiling Tor Browser with Address Sanitizer really lead to a more secure browser, given that the sanitizer is mainly intended as a debugging tool? Moreover, just using the hardening options provided by the toolchain seemed to be an incomplete solution to the problem—a bandaid until we could provide a more complete approach to hardening.

Looking again at its purposes above, we think it is safe to say that the hardened series indeed helped us identifying issues early on: with it we found bugs both in Firefox and tor and they got resolved quickly.

The picture is not so clear with respect to the promised security benefits. Part of the problem is that "more secure" can mean a wide variety of things. Another part is that we did not measure if we were indeed adding a security benefit to Tor Browser with all the techniques we deployed. What we learned over the course of the past 18 months, however, is that enabling expensive hardening can aid in making Tor Browser crashes much more reliable.

But that's not the only thing we learned. It seems we underestimated the confusion among users caused by labeling the series as "hardened" while at the same time including features for debugging purposes as well. The resulting experimental character of this series made it hard for users to decide whether that's actually the Tor Browser they wanted to have or not.

Where does that leave us? We've decided to stop having a "hardened" browser series, and instead we'll provide separate tools for the two purposes that it aimed to solve:

Users that are currently on the hardened update channel will get an update to the most recent Tor Browser alpha with a note to use Sandboxed Tor Browser instead for enhanced security. While the Sandboxed Tor Browser is currently in an experimental state itself, we feel that it provides much better safeguards against exploitation than the features we shipped in the hardened series.

Having Sandboxed Tor Browser for hardening the browser experience allows us to do an even better job with finding problems earlier in our Tor Browser patches or code in Tor Browser generally: we can include more debugging aids into special debug builds. We plan to do so and get back to dedicated debug nightly builds when we switch to our reproducible builds manager (rbm), which is happening soon.

Finally, thanks to all users of the hardened Tor Browser series. We hope Sandboxed Tor Browser and the upcoming debug builds will provide an even better match to your needs. If not, please make sure to file a bug in our bug tracker and we'll look into it.

Tor Browser 7.0a3 is released

Update (Apr 24 8:36 UTC): Thanks to all for testing this alpha release so far. It turns out there are a number of issues that are affecting a lot of our alpha users. The following list should give an overview and help to avoid duplicate bug reports:

  • Tor Browser is crashing when opening/downloading files that need an external application to handle them. This is bug 21766.
  • Tor Browser is crashing on about:addons with the security slider set to "high" and does not show any preferences on about:preferences ticked. This issue is tracked in bug 21962.
  • The canvas prompt is not shown anymore in Tor Browser. This issue is tracked in bug 21778.
  • There is no sound on Linux systems without PulseAudio anymore. This is bug 1247056. Check this one out for Mozilla's reasoning behind dropping ALSA support.

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

This release features important security updates to Firefox.

This is the first alpha release which is based on Firefox ESR 52. We updated all of our patches that did not get upstreamed yet and made Torbutton and Tor Launcher multiprocess (e10s) compatible. After the first nightly build based on ESR52 went out we already fixed a number of bugs associated with this switch. But more remain, please help!

We hope having e10s and Mozilla's content sandbox enabled will be one of the major new features in the upcoming Tor Browser 7.0 series, both security- and performance-wise. While we are still working on the sandboxing part for Windows, both Linux and macOS have e10s and content sandboxing enabled by default in Tor Browser 7.0a3. There are already a number of bugs related to that on our radar which can be found on our bug tracker and which are tagged with the `tbb-e10s` keyword. If you find more, please report them!

The switch to Firefox ESR 52 raises the system requirements for Tor Browser on Windows and macOS. Computers running Windows and are not SSE2-capable are not supported anymore. On Apple computers with OS X < 10.9 Tor Browser won't run anymore either. Update (Apr 24 8:41 UTC): Only the browser part of Tor Browser is affected by these new constraints. If you are e.g. on Windows and are using the expert bundle or are extracting tor from Tor Browser it should run on any computer it used to run. The same holds for macOS with one exception: tor we ship in Tor Browser won't run on Apple computers with OS X 10.6 anymore either.

We updated our toolchains during the ESR transition as well. In particular we retired the old GCC-based one for our macOS cross-compilation and rely solely on clang/cctools now. As with previous releases building 7.0a3 is fully reproducible on all three supported platforms, even though we needed to deploy a last minute patch for Linux bundles this time.

Apart from switching to the new ESR and dealing with related issues we included a new Tor alpha (0.3.0.5-rc) and updated our NoScript (5.0.2) and HTTPS-Everywhere versions (5.2.14). The Sandboxed Tor Browser for Linux got updated to 0.0.6 making sure it is compatible with Firefox ESR 52.

As in Tor Browser 6.5.2 we provide a fix for Tor Browser crashing on github.com on Windows and for Twitter issues that got reported already a while ago. We update our security slider as well taking newer JIT preferences into account.

A note to Windows users: We signed the .exe files with a new codesigning certificate as the old one is about to expire. If there are issues with that new certificate, e.g. scary warnings showing up after downloading a Tor Browser .exe file and double-clicking on it, please let us know.

The full changelog since Tor Browser 7.0a2 is:

  • All Platforms
    • Update Firefox to 52.1.0esr
    • Tor to 0.3.0.5-rc
    • Update Torbutton to 1.9.7.2
      • Bug 21865: Update our JIT preferences in the security slider
      • Bug 21747: Make 'New Tor Circuit for this Site' work in ESR52
      • Bug 21745: Fix handling of catch-all circuit
      • Bug 21547: Fix circuit display under e10s
      • Bug 21268: e10s compatibility for New Identity
      • Bug 21267: Remove window resize implementation for now
      • Bug 21201: Make Torbutton multiprocess compatible
      • Translations update
    • Update Tor Launcher to 0.2.12
      • Bug 21920: Don't show locale selection dialog
      • Bug 21546: Mark Tor Launcher as multiprocess compatible
      • Bug 21264: Add a README file
      • Translations update
    • Update HTTPS-Everywhere to 5.2.14
    • Update NoScript to 5.0.2
    • Update sandboxed-tor-browser to 0.0.6
      • Bug 21764: Use bubblewrap's `--die-with-parent` when supported
      • Fix e10s Web Content crash on systems with grsec kernels
      • Bug 21928: Force a reinstall if an existing hardened bundle is present
      • Bug 21929: Remove hardened/ASAN related code
      • Bug 21927: Remove the ability to install/update the hardened bundle
      • Bug 21244: Update the MAR signing key for 7.0
      • Bug 21536: Remove asn's scramblesuit bridge from Tor Browser
      • Add back old MAR signing key to not break updating Tor Browser stable
      • Add `prlimit64` to the firefox system call whitelist
      • Fix compilation with Go 1.8
      • Use Config.Clone() to clone TLS configs when available
    • Update Go to 1.7.5 (bug 21709)
    • Bug 21555+16450: Don't remove Authorization header on subdomains (e.g. Twitter)
    • Bug 21887: Fix broken error pages on higher security levels
    • Bug 21876: Enable e10s by default on all supported platforms
    • Bug 21876: Always use esr policies for e10s
    • Bug 20905: Fix resizing issues after moving to a direct Firefox patch
    • Bug 21875: Modal dialogs are maximized in ESR52 nightly builds
    • Bug 21885: SVG is not disabled in Tor Browser based on ESR52
    • Bug 17334: Hide Referer when leaving a .onion domain (improved patch)
    • Bug 3246: Double-key cookies
    • Bug 8842: Fix XML parsing error
    • Bug 16886: 16886: "Add-on compatibility check dialog" contains Firefox logo
    • Bug 19192: Untrust Blue Coat CA
    • Bug 19955: Avoid confusing warning that favicon load request got cancelled
    • Bug 20005: Backport fixes for memory leaks investigation
    • Bug 20755: ltn.com.tw is broken in Tor Browser
    • Bug 21896: Commenting on website is broken due to CAPTCHA not being displayed
    • Bug 20680: Rebase Tor Browser patches to 52 ESR
    • Bug 21917: Add new obfs4 bridges
    • Bug 21918: Move meek-amazon to d2cly7j4zqgua7.cloudfront.net backend
  • Windows
    • Bug 21795: Fix Tor Browser crashing on github.com
    • Bug 12426: Make use of HeapEnableTerminationOnCorruption
    • Bug 19316: Make sure our Windows updates can deal with the SSE2 requirement
    • Bug 21868: Fix build bustage with FIREFOX_52_0_2esr_RELEASE for Windows
  • OS X
    • Bug 21723: Fix inconsistent generation of MOZ_MACBUNDLE_ID
    • Bug 21724: Make Firefox and Tor Browser distinct macOS apps
    • Bug 21931: Backport OSX SetupMacCommandLine updater fixes
    • Bug 15910: Don't download GMPs via the local fallback
  • Linux
    • Bug 21907: Fix runtime error on CentOS 6
    • Bug 21748: Fix broken Snowflake build and update bridge details
    • Bug 21954: Snowflake breaks the 7.0a3 build
    • Bug 15910: Don't download GMPs via the local fallback
  • Build system
    • Windows
      • Bug 21837: Fix reproducibility of accessibility code for Windows
      • Bug 21240: Create patches to fix mingw-w64 compilation of Firefox ESR 52
      • Bug 21904: Bump mingw-w64 commit to help with sandbox compilation
      • Bug 18831: Use own Yasm for Firefox cross-compilation
    • OS X
      • Bug 21328: Updating to clang 3.8.0
      • Bug 21754: Remove old GCC toolchain and macOS SDK
      • Bug 19783: Remove unused macOS helper scripts
      • Bug 10369: Don't use old GCC toolchain anymore for utils
      • Bug 21753: Replace our old GCC toolchain in PT descriptor
      • Bug 18530: ESR52 based Tor Browser only runs on macOS 10.9+
    • Linux
      • Bug 21930: NSS libraries are missing from mar-tools archive
      • Bug 21239: Adapt Linux Firefox descriptor to ESR52 (use GTK2)
      • Bug 21960: Linux bundles based on ESR 52 are not reproducible anymore
      • Bug 21629: Fix broken ASan builds when switching to ESR 52

Tor Browser 6.5.2 is released

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

This release features important security updates to Firefox.

This should be the last minor release in the 6.5 series. This release updates Firefox to 45.9.0esr, Noscript to 5.0.2, and HTTPS-Everywhere to 5.2.14.

Moreover, we included a fix for the broken Twitter experience and worked around a Windows related crash bug. To improve our censorship resistance we additionally updated the bridges we ship.

Here is the full changelog since 6.5.1:

  • All Platforms
    • Update Firefox to 45.9.0esr
    • Update HTTPS-Everywhere to 5.2.14
    • Update NoScript to 5.0.2
    • Bug 21555+16450: Don't remove Authorization header on subdomains (e.g. Twitter)
    • Bug 19316: Make sure our Windows updates can deal with the SSE2 requirement
    • Bug 21917: Add new obfs4 bridges
    • Bug 21918: Move meek-amazon to d2cly7j4zqgua7.cloudfront.net backend
  • Windows
    • Bug 21795: Fix Tor Browser crashing on github.com

Tails 2.12 is out

This release fixes many security issues and users should upgrade as soon as possible.

New features

  • We installed again GNOME Sound Recorder to provide a very simple application for recording sound in addition to the more complex Audacity. Sound clips recorded using GNOME Sound Recorder are saved to the Recordings folder.

Upgrades and changes

  • We removed I2P, an alternative anonymity network, because we unfortunately have failed to find a developer to maintain I2P in Tails. Maintaining software like I2P well-integrated in Tails takes time and effort and our team is too busy with other priorities.

  • Upgrade Linux to 4.9.13. This should improve the support for newer hardware (graphics, Wi-Fi, etc.).

For more details, read our changelog.

Known issues

None specific to this release.

See the list of long-standing issues.

Get Tails 2.12

What's coming up?

Tails 3.0 is scheduled for June 13th.

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.

Statement regarding Dmitry Bogatov

The Tor Project has been following with interest the case of Dmitry Bogatov in Russia, but we have no insight or information other than what we've been reading on publicly available websites.

The Tor Project does not collect any information or data that can be used to identify users of the Tor network. We do collect and publish information about Tor exit nodes and relays when relay operators voluntarily choose to send such information to the Tor Project servers. Data about individual Tor relays and the Tor network can be explored through the following sites:

  • Metrics Portal provides analytics for the Tor network, including graphs of its available bandwidth and estimated userbase;
  • Atlas is a web application to learn about currently running Tor relays; and
  • ExoneraTor answers the question of whether there was a Tor relay running on a given IP address on a given date.

What we know right now is that serious accusations of wrongdoing have been made against a valued member of our community, a person who has, among other things, been a Tor relay operator, Debian Developer, GNU developer, and privacy activist. We are collecting facts, monitoring the situation closely, and sharing information with allied organizations and individuals.

Tor 0.3.0.5-rc is released: almost stable!

Tor 0.3.0.5-rc fixes a few remaining bugs, large and small, in the 0.3.0 release series.

This is the second release candidate in the Tor 0.3.0 series, and has much fewer changes than the first. If we find no new bugs or regressions here, the first stable 0.3.0 release will be nearly identical to it.

You can download the source code from the usual place on the website, but most users should wait for packages to become available over the upcoming weeks. There should be a new Tor Browser alpha release containing Tor 0.3.0.5-rc some time later this month.

Please note: This is a release candidate, but not a stable release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Changes in version 0.3.0.5-rc - 2017-04-05

  • Major bugfixes (crash, directory connections):
    • Fix a rare crash when sending a begin cell on a circuit whose linked directory connection had already been closed. Fixes bug 21576; bugfix on 0.2.9.3-alpha. Reported by Alec Muffett.
  • Major bugfixes (guard selection):
    • Fix a guard selection bug where Tor would refuse to bootstrap in some cases if the user swapped a bridge for another bridge in their configuration file. Fixes bug 21771; bugfix on 0.3.0.1-alpha. Reported by "torvlnt33r".

  read more »

Syndicate content Syndicate content