New Release: Tor Browser 9.5

Update [06/03 15:40 UTC]: Added developers docs for enabling onion-location and client authentication.

Tor Browser 9.5 is now available from the Tor Browser download page and also from our distribution directory. The Android version is also available from Google Play and should be available from F-Droid within the next day.

This release includes important security updates to Firefox.

This new Tor Browser release is focused on helping users understand onion services.

Tor's onion routing remains the best way to achieve end-to-end anonymous communication on the Internet. With onion services (.onion addresses), website administrators can provide their users with anonymous connections that are metadata-free or that hide metadata from any third party. Onion services are also one of the few censorship circumvention technologies that allow users to route around censorship while simultaneously protecting their privacy and identity.

For the first time, Tor Browser users on desktop will be able to opt-in for using onion sites automatically whenever the website makes them available. For years, some websites have invisibly used onion services with alternative services (alt-svc), and this continues to be an excellent choice. Now, there is also an opt-in mechanism available for websites that want their users to know about their onion service that invites them to upgrade their connection via the .onion address.

What is new?

Onion Location

Website publishers now can advertise their onion service to Tor users by adding an HTTP header. When visiting a website that has both an .onion address and Onion Location enabled via Tor Browser, users will be prompted about the onion service version of the site and will be asked to opt-in to upgrade to the onion service on their first use.

If you are a developer, learn how to enable onion-location in your onion service.

Onion Location Propublica

 

Onion Authentication

Onion services administrators who want to add an extra layer of security to their website can now set a pair of keys for access control and authentication. Tor Browser users can save keys and manage them via about:preferences#privacy in the Onion Services Authentication section.

If you are a developer, learn how to secure your onion service using client auth.

Onion Authentication

Improved URL Bar Security Indicators

Browsers traditionally rendered sites delivered via a secure transport protocol with a green lock icon. But in mid-2019, the formerly green lock icon became gray, intending to de-emphasize the default (safe) connection state and, instead, putting more emphasis on broken or insecure connections. Major browsers as Mozilla Firefox and Google Chrome understood that it is a benefit for the entire user base if they deploy familiar experiences for both users. We are following Firefox on this decision, and we have updated Tor Browser security indicators to make it easier for users to understand when they are visiting a non-secure website.

Tor Browser 9.5 URL Bar Update

Error Pages for Onion Services

Sometimes users have a hard time reaching onion sites. In previous versions of Tor Browser, when there was an error connecting to an onion service, users received a standard Firefox error message, with no information about why they were unable to connect to the onion site.

In this release, we have improved the way Tor Browser communicates with users about service-, client-, and network-side errors that might happen when they are trying to visit an onion service. Tor Browser now displays a simplified diagram of the connection and shows where the error occurred. We want these messages to be clear and informative without being overwhelming.

Error Page for Onion Pages

Onion Names

Because of cryptographic protections, onion service URLs are not easy for humans to remember (ie, https://torproject.org vs. http://expyuzz4wqqyqhjn.onion/). This makes it hard for users to discover or return to an onion site. We found that organically, developers have approached this problem in different ways, mostly with solutions tailored for their service. Given that there is no solution that works perfectly for all our user groups, we also approached this problem from a broad angle. For this release, we partnered with Freedom of the Press Foundation (FPF) and the Electronic Frontier Foundation's HTTPS Everywhere to develop the first proof-of-concept human-memorable names for SecureDrop onion services addresses:

Freedom of the Press Foundation has reached out to a small number of additional media organizations for participation, and Tor and FPF will jointly consider next steps based on feedback on this initial proof-of-concept.

Onion Names

 

Known Issues

Tor Browser 9.5 comes with a number of known issues.

Give Feedback

If you find a bug or have a suggestion for how we could improve this release, please let us know. Thanks to all of the teams across Tor, and the many volunteers, who contributed to this release.

Full Changelog

The full changelog since Tor Browser 9.0.10 is:

  • All Platforms
    • Update Firefox to 68.9.0esr
    • Update HTTPS-Everywhere to 2020.5.20
    • Update NoScript to 11.0.26
    • Update Tor to 0.4.3.5
    • Translations update
    • Bug 21549: Disable wasm for now until it is properly audited
    • Bug 27268: Preferences clean-up in Torbutton code
    • Bug 28745: Remove torbutton.js unused code
    • Bug 28746: Remove torbutton isolation and fp prefs sync
    • Bug 30237: Control port module improvements for v3 client authentication
    • Bug 30786: Add th locale
    • Bug 30787: Add lt locale
    • Bug 30788: Add ms locale
    • Bug 30851: Move default preferences to 000-tor-browser.js
    • Bug 30888: move torbutton_util.js to modules/utils.js
    • Bug 31134: Govern graphite again by security settings
    • Bug 31395: Remove inline script in aboutTor.xhtml
    • Bug 31499: Update libevent to 2.1.11-stable
      • Bug 33877: Disable Samples and Regression tests For Libevent Build
    • Bug 31573: Catch SessionStore.jsm exception
    • Bug 32318: Backport Mozilla's fix for bug 1534339
    • Bug 32414: Make Services.search.addEngine obey FPI
    • Bug 32493: Disable MOZ_SERVICES_HEALTHREPORT
    • Bug 32618: Backport fixes from Mozilla bugs 1467970 and 1590526
    • Bug 33342: Avoid disconnect search addon error after removal
    • Bug 33726: Fix patch for #23247: Communicating security expectations for .onion
    • Bug 34157: Backport fix for Mozilla Bug 1511941
  • Windows + OS X + Linux
    • Update Tor Launcher to 0.2.21.8
      • Translations update
      • Bug 19757: Support on-disk storage of v3 client auth keys
      • Bug 30237: Add v3 onion services client authentication prompt
      • Bug 30786: Add th locale
      • Bug 30787: Add lt locale
      • Bug 30788: Add ms locale
      • Bug 33514: non-en-US Tor Browser 9.5a6 won't start up
    • Bug 19251: Show improved error pages for onion service errors
    • Bug 19757: Support on-disk storage of v3 client auth keys
    • Bug 21952: Implement Onion-Location
    • Bug 27604: Fix broken Tor Browser after moving it to a different directory
    • Bug 28005: Implement .onion alias urlbar rewrites
    • Bug 30237: Improve TBB UI of hidden service client authorization
    • Bug 32076: Upgrade to goptlib v1.1.0
    • Bug 32220: Improve the letterboxing experience
    • Bug 32418: Allow updates to be disabled via an enterprise policy.
    • Bug 32470: Backport fix for bug 1590538
    • Bug 32645: Update URL bar onion indicators
    • Bug 32658: Create a new MAR signing key
    • Bug 32674: Point the about:tor "Get involved" link to the community portal
    • Bug 32767: Remove Disconnect search
    • Bug 33698: Update "About Tor Browser" links in Tor Browser
    • Bug 33707: Swap out onion icon in circuit display with new one
    • Bug 34032: Use Securedrop's Official https-everywhere ruleset
    • Bug 34196: Update site info URL with the onion name
    • Bug 34321: Add Learn More onboarding item
  • Windows
    • Bug 22919: Improve the random number generator for the boundaries in multipart/form-data
    • Bug 29614: Use SHA-256 algorithm for Windows timestamping
    • Bug 33113: Bump NSIS version to 3.05
  • OS X
    • Bug 32505: Tighten our rules in our entitlements file for macOS
  • Linux
    • Bug 27903: Tor Browser 8 does not respect gtk3 settings
    • Bug 34315: Avoid reading policies from /etc/firefox on Linux
  • Android
    • Bug 26529: Notify user about possible proxy-bypass before opening external app
    • Bug 30767: Custom obfs4 bridge does not work on Tor Browser for Android
    • Bug 32303: Obfs4 is broken on Android Q
    • Bug 33359: Use latest Version of TOPL and Remove Patches
    • Bug 33931: obfs4 bridges are used instead of meek if meek is selected in Tor Browser for Android alpha
  • Build System
    • All Platforms
      • Update Go to 1.13.11
      • Bug 33380: Add *.json to sha256sums-unsigned-build.txt
    • Windows
      • Bug 33802: --enable-secure-api is not supported anymore in mingw-w64
    • Linux
    • Android
      • Bug 28765: LibEvent Build for Android
      • Bug 28766: Tor Build for Android
      • Bug 28803: Integrate building Pluggable Transports for Android
      • Bug 30461: Clean up tor-android-service project
      • Bug 32993: Package Tor With Tor Android Service Project
      • Bug 33685: Add Support for Building zlib for Android

We are considering a security broken scenario primarily when the onion service is serving mixed content from an insecure URL.

You can learn more about our discussion in our former ticket about security indicators for onion services

https://trac.torproject.org/projects/tor/ticket/23247

and in our latest iteration

https://trac.torproject.org/projects/tor/ticket/32645

I think "security broken" means the URL specifies https://, but the TLS certificate is bad. You're still protected by the .onion crypto, but not necessarily TLS. Mixed content means that a site, http(s)://xyz.onion loads content from a clearnet site, like http(s)://xyz.com. I'm just guessing here. Please read the docs and/or source code to be sure. Maybe the developers would like to clarify.

zoobab

June 02, 2020

Permalink

Tor NOTICE: Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6305/6321). That's ok. We will try to fetch missing descriptors soon.
---
That's ok. But it delays the bootstrap for several seconds.

zoobab

June 02, 2020

Permalink

uncaught exception: 2147746065 SessionStore.jsm:1325:22
(this bug was reported as fixed,iirc)

"fooooooooooo.onion is requesting your private key" is misleading. Dangerous sounding, even. It's **not** dangerous, but it sounds like the onion service is trying to do something bad to you.

I seem to remember a ticket or comment in a ticket stating as much. I can't find it. So I'm making this comment here in the hopes that I make change happen :)

Thanks for the hard work, TB devs!

Thanks for this - I was slightly horrified when I saw the screenshot. Anyone with a little knowledge of public-key cryptography would know that you never send your private key to anyone. So I'd be reluctant to fill it in that dialog.

Went to comment but saw this has already been raised :)

zoobab

June 02, 2020

Permalink

> Go to 1.13.11
Sounds like GOTO ;)
"Updated Go to 1.13.11" is better. First time you do security update of compiler as a usual update. Go ahead!

zoobab

June 02, 2020

Permalink

>Onion Names

What stops the US government from forcing you to take down / unlist certain hard-coded addresses or even silently swapping them out for MITM attacks? What if other governments use this as a reason to ban Tor Browser altogether? After all, these services encourage people to leak confidential information.

Also, will you allow more people to register *.tor.onion domains at some point in the future? You wrote that it's a proof-of-concept... If so, I can already predict that you would be pressured to take down certain domains even if they're completely legal. I don't like where this is going to tbh.

This is not available for general use because we haven't found answers for these questions. This is a hard problem with bad solutions. We're starting with something simple and we'll improve it based on feedback we receive. There will be many more conversations about this before anything is built or deployed - so stay tuned for those.

But if the same .onion services are already available on the regular internet what difference would it make to government? Methinks all it would mean is better anonymity for the user if they chose to use Tor and the .onion address to visit the site, but the service itself is already available on the regular internet. Hence it's not a "hidden service" if it's mirrored from the regular internet.

Possibly. The internet-accessible site equally could be a "mirror" of the onion service. Onion services are not necessarily location-hidden, and location hiding is only one (minor) property of them. Using the .onion address is generally safer, but it is less usable because the name is none sense and/or it is "easily" phish-able (against end users). Unfortunately, the current solutions rely on first connecting to internet-accessible website, so you can learn about the onion address, and then connecting to the onion address you learned.

Yeah, it's not good or appropriate for the 501c3 regulated Tor Project to get into becoming a centralized naming authority, a whitelist operator, and effectively bundling a list of suggested websites to visit that are not part of Tor Project itself.

zoobab

June 02, 2020

Permalink

I thought Tor Browser's design was opposed to filter-like lists. Who maintains the distributed lists of onion domain translations? Who determines if an onion is truly operated by the clearnet mirror it claims to be?

For this release, we partnered with Freedom of the Press Foundation (FPF) and the Electronic Frontier Foundation's HTTPS Everywhere to develop the first proof-of-concept human-memorable names for SecureDrop onion services addresses:
[...]
Freedom of the Press Foundation has reached out to a small number of additional media organizations for participation, and Tor and FPF will jointly consider next steps based on feedback on this initial proof-of-concept.

Sorry, I meant the lists that redirect to onions. Torproject.org redirects to expyuzz4wqqyqhjn.onion. Do FPF and EFF also control the redirection lists?

But as for the human-memorable names, aren't they "for SecureDrop onion services addresses" for now as it says, whereas the redirection lists are applied more widely?

Ah. the redirection is advertised by the website. When you visit the first website (such as torproject.org), the webserver includes a "hint" that the website it also available at a .onion address. Tor Browser recognizes this and shows the ".onion available" button. There is not a list for this feature.

The human-meaningful short-names are only available for SecureDrop at this point in time, correct. Meanwhile, anyone can use the onion-location redirection.

zoobab

June 02, 2020

Permalink

It happened again... After a new version of NoScript is included in TorBrowser, NoScript's author almost right away replaces it with his even newer version (like v. 11.0.29 now), via an automated update that TorBrowser is set to accept.
While the updates always sound justified (and they may be), watch: this happens shortly after almost every TorBrowser release. Why?

TorBrowser devs, please close this potential security hole - disable the automated add-on updates, at least from NoScript. I think it's configured so in the Tails' TorBrowser.

A repeating coincidence... Check it out yourselves the few next times when TBB ships the new NoScript.

Thanks for looking up the existing ticket for this. It's opened 6 years ago!

Someone's suggestion to disable the auto add-on update by the individual users is probably not a good idea.

You can set them to Off in about:addons

Add-on Details - Allow automatic updates: Off

I have done this, so once again no automatic update here.

Come on Tor team PLEASE fix this security hole already....

Other than that everything seems to be working great, Thank you.

NoScript buttons are now greyed out for permanent site settings, preventing us from changing them per site. How do we get these buttons back without reverting to an earlier version of NoScript?

zoobab

June 02, 2020

Permalink

Great release.

The changelog is missing the gsettings workaround for #27903 that was added in this release.

zoobab

June 02, 2020

Permalink

when I use youtube I get a thin white border in the youtube display ie not my screen display that was not there before this version ie ver 9.0.10

Has anyone else noticed this?

should it be there? why was it not there before?

Thank you