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
zoobab

June 03, 2020

Permalink

NoScript 11.0.26 or 11.0.29 not functional on my 32-bit version of Tor Browser 9.5 on Linux. When clicking on any of the buttons in the NoScript drop down menu, that particular line just flashes yellow and won't change from the DEFAULT setting. NoScript worked fine up to TB 9.0.10.
Should I reinstall Tor Browser or even try an older version of NoScript?
Thanks for the hard work everyone is putting in to the Tor Browser.

zoobab

June 03, 2020

Permalink

In the article, you link to a Cloudflare blog post (https://blog.cloudflare.com/cloudflare-onion-service/) where they talk about supporting alt-svc with .onions as an alternative to captchas. This seems pretty exciting, as Tor has been plagued for many years by Cloudflare blocking it, sometimes even with malicious unsolvable never-ending captchas that just waste the user's time.

Unfortunately, I tried visiting a few Cloudflare sites, and I'm not seeing the ".onion available" banner. (I do see it on torproject.org so it's not my setup.)

Any idea what the status of this is? The Cloudflare blog post is over a year old.

The Cloudflare configuration allows Tor users to bypass one layer of abuse-detection when the connection uses the (alt service) .onion address. Cloudflare still shows a CAPTCHA in some situations, even if the connection is using the .onion address (because some shitty people still use Tor for abusive behavior).

Cloudflare shouldn't be blamed for the unsolvable captchas. Those came from a system provided by Google. Recently, Cloudflare switched to a new captcha provider, and hopefully the captchas will be better now, in general.
https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptcha/

Cloudflare does not use the onion-location header we discussed in this blog post. They use the invisible alternative services method. This is a better option for them because Tor Browser user will continue seeing the website they expect in the url bar (https://example.com) but the browser will transparently connect to a .onion address instead.

> [the "alt-svc" header] is a better option for them because Tor Browser user will continue seeing the website they expect in the url bar (https://example.com) but the browser will transparently connect to a .onion address instead.

If alt-svc works for cloudflare, and has for some time already, then why was the recent onion header feature developed, or even desirable? The alt-svc header seems like a superior solution to me, for the reasons you explained. The only exception I can think of is if users bookmark the .onion and use it long-term, it could be more trustworthy/authentic than the site's domain name and TLS certificate.

The only benefits (I know about) are 1) as a person visiting the site, you are given a choice about how you connect (through an Exit node, or via onion service), 2) it gives website operators a way of advertising they support Tor ("support" in that they have an onion service and they are Tor-friendly (presumably)), and 3) advocacy/awareness.

There is some debate about whether website operators should require consent before redirecting connections through an onion service (do you need consent before upgrading connections to a more secure protocol?). However, this is an important educational moment, as well. Many Tor users do not really understand onion services, and we are hoping this feature brings more awareness about it. In addition, as more sites adopt this feature, it shows that Tor and onion services are used/available around the web, where they were completely invisible before.

Ah, I understand, and completely agree with #2 and #3.

I think #1 is a valid but rather weak argument. a) Users of the web are already subjected to all kinds of things without their consent or choice. Tracking, malvertising, whether or not to connect via Cloudflare/Cloudfront/Akamai/etc in the first place. Upgrading to .onion is probably the most benign - if not benevolent - of anything. I agree with user control and consent, but b) if the site can still silently send alt-svc, there's really no consent to begin with. It's a tough call. Thanks for the reply!

Thanks for this. It's been years since I've even bothered trying to solve a Cloudflare captcha (or even enable javascript on their pages for the captcha to appear) due to having had my time wasted by neverending captchas in the past, so I hadn't even noticed they'd changed to a good provider.

zoobab

June 03, 2020

Permalink

In recent versions I've been having an issue where if I go to Options -> Privacy & Security -> Cookies and Site Data and click "Manage Permissions...", and I "Allow" a few sites where I want to save a login cookie, these settings get deleted when restarting the browser. This used to work. Not sure exactly what version it stopped working - possibly 9.0. Now, every time I restart the browser, I have to go into those settings and re-apply them to prevent the cookies being deleted on next restart.

To be clear: it's not the cookies that get deleted (at least not initially), it's my cookie settingsthat get cleared.

I realise this is a non-default configuration, but is there any chance you could fix this?

Now that you've moved to a publically-searchable issue tracker (thanks for that, btw), I've found this has already been reported: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/335…

Unfortunately for "ordinary" web users (as opposed to dissidents in oppressive states), the answer is that allowing the user to configure this is intentionally unsupported. Oh well.

zoobab

June 03, 2020

Permalink

How do the tor.onion URLs work? How were they created and is there a plan for them to be more widely adopted? What's the difference between the v2 and v3 onions?

This is a loaded question/comment :)

1) Tor Browser includes a hard-coded list of *.tor.onion domains. Currently this list only includes SecureDrop instances under *.securedrop.tor.onion and the list is provided by Freedom of the Press Foundation. We are interested in expanding this for other organizations/people, but we don't know exactly how we can do this safely (this is why we only have one at this time).

Version 2 onion addresses rely on cryptography that was standardized in the 1990s and its strength is based on assumptions that made it secure "for the next 10-20 years". Unfortunately, that was (approximately) 20 years ago. This does not mean version 2 onion services are broken (there doesn't exist any evidence that this is true), but the underlying cryptography is not as strong as we need. This prompted the development of version 3 onion services (v3). v3 onion services use modern cryptographic primitives and they protect against other network-level attacks. Unfortunately, v2 onion addresses are much shorter than v3 onion addresses. While shorter addresses are more memorable, they provide significantly less protection and they are much less secure today. (Nearly) Everyone should use v3 onion services now, whenever possible.

zoobab

June 03, 2020

Permalink

(#8) Error Killing GPU process due to IPC reply timeout
(#9) Error Failed to connect GPU process
(#10) Error Receive IPC close with reason=AbnormalShutdown
(#11) Error Receive IPC close with reason=AbnormalShutdown
(#12) Error Receive IPC close with reason=AbnormalShutdown
(#13) Error Receive IPC close with reason=AbnormalShutdown
(#14) Error Receive IPC close with reason=AbnormalShutdown
(#15) CP+[GFX1-]: Receive IPC close with reason=AbnormalShutdown
(#16) CP+[GFX1-]: Receive IPC close with reason=AbnormalShutdown
(#17) CP+[GFX1-]: Receive IPC close with reason=AbnormalShutdown

zoobab

June 04, 2020

Permalink

How difficult would it be for a particular extension maker/hoster shipping with TBB to identify the update request as coming from an exit node and serve a different, poisoned update strictly for TBB users?

I'm not suggesting this happens, I'm asking because I'm curious.

Tor Browser includes two extensions, by default: HTTPS Everywhere and NoScript.

For NoScript, this would require collusion between Mozilla and the NoScript developer.
For HTTPS Everywhere, this only requires collusion between EFF developers and EFF sysadmins.

zoobab

June 04, 2020

Permalink

Is it safe to use fullscreen with the browser's built-in video player or does it give away the resolution?
By "browser's built-in video player" I mean the player that is used when you open a video file (.mp4, .webm...) directly instead of using the website's player (youtube, vimeo...).

zoobab

June 04, 2020

Permalink

Hi everybody. I am new to Tor. Why when I use search bar I still get browser I used before Tor? Thank you.

Hi, welcome! Tor Browser is simply a modified version of Mozilla Firefox. When you use the search bar, your query is sent to DuckDuckGo (by default) which is a competitor of Google. Tor Browser is simply a safer agent of you as you browse the Internet.

zoobab

June 04, 2020

Permalink

Thanks a lot for all Tors instructors and customers! Real good program! If it'll be much more money, will send it to you brothers!

zoobab

June 04, 2020

Permalink

When the problem with android bridges will get fixed ino the stable Tor browser?
It is impossible to use custom obsf4 bridges...

Hi, another Anonymous! It's hard to understand what you want to say without proper grammar. But NoScript is a pet project of Giorgio Maone, and it is his sole decision when to update (usually, many times a month).

What is wrong with my grammar? Getting tired of being ignored, so I don't put much effort in sorry. This among many other reasons is why the functions should be included in the browser instead.

Then there appears to be some bug. Possibly because I have automatic updates for add-ons set to Off. I checked the add-on manifest page and indeed it appears to say version 11.0.26 is the version installed. However the add-on details page says 11.0.25.

zoobab

June 04, 2020

Permalink

"I am fine logging this as a bug [...]"
Pretty lovely nice.

What's the reason for this easy to fix bug -a character string?- is not solved after this long -19 months ago!- time?
Why Torbrowser must report the real system OS?
Who really need this?

zoobab

June 05, 2020

Permalink

Is there any particular reason as to why https://blog.torproject.org doesn't have a .onion address? As well as the fact that https://trac.torproject.org has an onion address listed here https://onion.torproject.org/ but it currently doesn't have Onion-Location setup on the server, though I'm guessing this one will be fixed soon? Also why exactly doesn't tor use a single unified .onion address using subdomains like the torproject.org domain for clearnet? The only domain I see having an issue in that list is 2019.www.torproject.org.

> Also why exactly doesn't tor use a single unified .onion address using subdomains like the torproject.org domain for clearnet?

I can't speak for TP or anyone else specifically, but generally speaking:

1) The browser would send the same "Host:" header, where it would otherwise be different for each subdomain, so it makes webserver configuration difficult, and could break server-side code that relies on subdomains
2) The private key has to be shared by every site that uses the .onion. If any one site or service compromised, all of them are compromised. There's no security separation or hierarchy. If blog.torproject.org were compromised, then so would be ftp.torproject.org.
3) With a regular domain name, the webserver is separated from the domain name (registrar). Even if your site is hacked and SSL private key is stolen, the attacker cannot control your domain name (assuming your registrar account wasn't also hacked). With a .onion there is no such separation; a .onion is permanently associated with its private key in a 1-to-1 fashion. Unlike a regular domain name, once compromised, a .onion can never be made trustworthy again. Therefore it's more important to use different .onion addresses for different services (compared to regular domain names), in order to limit the scope of the potential damage.

Yes, you could probably come up with a sophisticated proxying key-sharing load-balancing scheme for using the same user-facing .onion to access multiple independent backends securely, but there's no simple solution as far as I know.

zoobab

June 05, 2020

Permalink

It would be so much easier were you to create a web forum for people to access.

Yes, I know there are options available, unofficial ones. I want to see an official one, and I know about the ML. This would solve so much if you would just implement this idea. Thank you.

zoobab

June 05, 2020

Permalink

Is there a way to turn the pink .onion available thing off? When I click on it, it just disappears, nothing happens.