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
Tags
tor browser
tbb
tbb-9.5

https://support.torproject.org/tbb/maximized-torbrowser-window/
the Tor border was noticed for some time at start up
https://www.zdnet.com/article/firefox-to-add-tor-browser-anti-fingerpri…
the Firefox border does not show when I start my home page

The Youtube border was not shown or at least noticed until I updated to this version, ie yesterday not noticed today as soon as I used youtube border noticed.

Thus not sure why Youtube border would not show in 9.010 but does show in 9.5

Thank you for prompt reply.

Before that version, Tor Browser used to show a message every time you went fullscreen advising you not to do so because your browser's width and height could be unique and therefore trackable. Letterboxing rounds your browser's width and height down to a round number like this so there's less entropy.

In addition the Youtube border does not show when I am not using Tor ie web browser without Tor So, the Youtube border is because of Tor and not the web browser

Thank you

Workaround: consider using https://invidio.us - an alternative frontend to Youtube. It has .onion addresses, and even works without javascript. See https://github.com/omarroth/invidious

Use any of the following addresses (Taken from https://instances.invidio.us)

name version type users signup location health
invidio.us 0.20.1-6435c7b https 29827 US 99.771
invidious.snopyta.org 0.20.1-6435c7b https 1302 FI 100.00
yewtu.be 0.20.1-8305af8 https 310 FR 100.00
invidious.13ad.de 0.20.1-8305af8 https 242 DE 99.984
invidious.ggc-project.de - https - - DE 99.910
yt.maisputain.ovh - https - - DE 100.00
invidious.toot.koeln - https - - DE 100.00
invidious.fdn.fr - https - - - -
watch.nettohikari.com - https - - DE -
owxfohz4kjyv...a.b32.i2p - i2p - - - -
axqzx4s6s54s...iid.onion - onion - - - -
4l2dgddgsrkf...gyd.onion - onion - - - -
kgg2m7yk5aybusll.onion - onion - - - -
fz253lmuao3s...cad.onion - onion - - - -
qklhadlycap4cnod.onion - onion - - - -
c7hqkpkpemu6...oid.onion - onion - - - -
mfqczy4mysscub2s.onion - onion - - - -

cheers looks interesting I will use invidio much appreciated we live and learn

Just so I am not misunderstood the youtube border is only slim, small and the film can still be clearly viewed

Thank you

Anonymous

Anonymous (not verified) said:

June 02, 2020

Permalink

You still didn't fix self-signed https onionsite. Why is this? This nightmare started since TBB version 8.

Can't you just ignore self-sign certificate if it's name and expiration is valid?

99% chance you shouldn't be adding self-signed certificates to your onion services. https://matt.traudt.xyz/posts/dont-https-your-o44SnkW2.html

It's not making you any safer unless you check it every time, which you're not. Oh you are? Okay. Do you have other users? They aren't checking it.

No one will notice when your certificate is replaced with an attackers. The attack that was already supposed to be impossible wasn't even stopped.

I disagree. Latest technology requires HTTPS connection. HTTP/2 cannot be used on http:. Mozilla add-on updates requires HTTPS connection.

> which you're not. Oh you are?
Yeah, I do this on my onionsite. Problem?

> No one will notice when your certificate is replaced with an attackers.

This is just silly. If the attacker can replace my certificate they must attack .onion first.
If you claim http onion is so secure, then you must accept that https onion is also secure because it is on onion system.

I know plenty of onionsites sitting on https for a good reason, and their owners do provide proof on their clearnet site.

>> which you're not. Oh you are?
>Yeah, I do this on my onionsite. Problem?

If you're already going to the trouble of checking the certificate hash of your site, then is it that much of an inconvenience for you to bypass the warning? The other points you make seem like they might be valid however. I'll have to look into it some more. Thanks for bringing this up. You should open a bug report and explain these problems and arguments in detail.

If the connection between Tor Browser and onion server cannot be MitMed like you advertised in support.tpo page, how do you explain the scenario that the hacker replace the onionsite's certificate? If you can do that, the connection to onionsite is not safe at all.

I have forum onionsite and it's https://.

Anonymous

Passerby (not verified) said:

June 02, 2020

Permalink

Regarding the onion names, wouldn't it be more effective to take the generated Onion URL and run it through a dictionary of words so that the end result would be:

wordsrandomlygenerated.onion

Named services (while conceptually useful for humans) would imply an inevitable centralized governance for deciding who gets what name for their onion service.

Yes, and this has been discussed a few times. One difficult problem is "which dictionary?". Tor users speak dozens of languages, so onion service addresses shouldn't be only some-combination-of-English-words, meanwhile using different word combinations for each language *and* those word-combinations being (likely) completely unrelated to each other would be terrible for usability.

Why don't you use emojis? They're universal across all languages.

According to https://emojipedia.org/faq/, there are currently 3,304 emojis in the Unicode Standard. That means you can reduce the number of characters for the domain name dramatically!

Something like [EMOJI_1][EMOJI_2][...]][EMOJI_n-1].onion would be awesome. <3<3

----
Sadly this forum software doesn't support emojis... I wanted to post them for illustration purposes.

>The website encountered an unexpected error. Please try again later.
>Drupal\Core\Entity\EntityStorageException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value:
>...

Translated lists for every supported language could do. The related word combinations in different languages would point to the same onion service. There will be some overlap for the words: A translated word could be written the same as a word in another language. As long as it still refers to the same word there is no problem (e.g en:"machine" = fr:"machine" = word #52759). Else this could be fixed with adding the language code to the whole URL (e.g "en" , "fr").

Most work would be in generating the translations. That could probably be automated. The checks for profanity and splitting apart words that were translated to the same word or refer to diffrent word # could be crowdsourced. The final check for unambiguousness can be automated again. After that the lists are fixed and few support is needed. Additionally those lists are highly reusable for other projects.

New languages can be added through the same process. But if the word combinations are not marked with a language code, they will need to work around the existing lists.

It's not inevitable. Not easy, but not inevitable. See "squaring zokoo's triangle" by the late Aaron Swartz. Case in point: "Namecoin" is a fork of bitcoin that has managed to completely decentralize the .bit namespace. It uses a blockchain, proof-of-work, digital signatures, etc, just like bitcoin, but instead of deciding on who is the rightful owner of some coins, it decides what is the rightful address of a .bit name. There are other similar, and not-so-similar, approaches for decentralized name systems. This was discussed on the Tor blog back in 2017: https://blog.torproject.org/cooking-onions-names-your-onions

Anonymous

Anonymous (not verified) said:

June 02, 2020

Permalink

amazing

Anonymous

Anonymous (not verified) said:

June 02, 2020

Permalink

[06-03 04:07:38] Torbutton WARN: Version check failed! JSON parsing error: SyntaxError: JSON.parse: expected ',' or ']' after array element at line 19 column 1 of the JSON data

Anonymous

Anonymous (not verified) said:

June 02, 2020

Permalink

But in mid-2019, the formerly green lock icon became gray

We are following Firefox on this decision

Is the green lock icon going to change to grey? For me it's still green, e.g. right now on this page it's green.

Anonymous

Anonymous (not verified) said:

June 03, 2020

Permalink

This might be a niche and pedantic complaint, but when you visit an onion site that requires authentication (as in this screenshot) and you click cancel, then you click the circled-i button to the left of the URL, it says connection is not secure.

But there is no connection, and any handshake-type stuff that happens is all secure, right? Maybe it's not an issue but I thought I'd just bring it up.

Anonymous

site blocket o… (not verified) said:

June 03, 2020

Permalink

Hello! While trying to access riseup.net on Tor, I got a screen with a 'Site blocked' message, served by a company called Neustar. It is the first time that it happens and I am wondering what is going on here. Why do they act on Tor network? Thank you.

Anonymous

Anonymous (not verified) said:

June 03, 2020

Permalink

I have a question about the Onion Location Header. Aside from being easier for site admins to configure, how is this better than detecting when the remote address is a Tor exit node, and sending a 301-Redirect header containing the .onion? The latter works even if the client is not a Tor Browser, for example in the case of Debian package mirrors, chat clients, and any other HTTP-based protocol. Is it expected that HTTP client libraries like cURL and wget will eventually begin to honor the onion header, too? Thanks.

I presume it's because users should be given the freedom to decide whether the want to be redirected to the onion site. My concern however is about the possibility of a MITM attack intercepting Onion Location Headers and replacing real .onions with malicious ones. I wonder if this possibility has been considered?

Yes, it is about consent. Regarding modification of the header in-transit, the situation is no worse than any other HTTP header provided on the connection (either for 'alt-svc' or 'location' redirection). In this case, onion-location is only accepted over "secure" connections (https and http+.onion).

Therefore, I don't suggest you trust an onion-location advertisement when you visit a website and click-through an invalid certificate warning - but this isn't something Tor Browser can decide on its own.

Anonymous

Anonymous (not verified) said:

June 03, 2020

Permalink

Playing video is still broken.

NotSupportedError: The media resource indicated by the src attribute or assigned media provider object was not suitable.

Anonymous

Anonymous (not verified) said:

June 03, 2020

Permalink

When we will the problem with the custom android bridges get fixed?
When we will be able to use them?

but "sdt.onion" is not human meaningful. "securedrop.tor.onion" is long and less user-friendly, but it tells the user exactly which group is defining the name mapping.

I want to write a blog post describing the trade-offs we considered and why we are trying this naming scheme. I hope that will be written/published in the next few weeks so we can get feedback on it.

Anonymous

584Bbrw2 (not verified) said:

June 03, 2020

Permalink

On the android version of tor 9.5 in Settings>Privacy why is the box for clearing tor data on user clicking "Exit" not selected by default, does tor clear all data if user just exits app without clicking "exit"?

As this could put people without much browser knowledge at risk.

This is a massive upgrade compared to 9.0 well done tor team!.

Tor Browser on Android clears all data when you explicitly exit the app and when the app is killed/closed for any other reason (including opening the Recent Apps list and swipping the app "away").

Android is not an easy platform for developing privacy-oriented apps, but we are trying to make Tor Browser safe-by-default.

Thanks for the kind words!