New Release: Tor Browser 10.5

Tor Browser 10.5 is now available from the Tor Browser download page and also from our distribution directory.

This new Tor Browser release is focused on improving the internet access of users connecting through Tor in censored contexts.

What's new?

V2 Onion Services Deprecation

Tor Browser 10.5 V2 onion addresses warning

As we announced last year, v2 onion services will be completely unreachable once Tor Browser moves to Tor 0.4.6.x in October 2021. From now until then, Tor Browser will warn you when visiting a v2 onion site of its upcoming deprecation.

Snowflake is now available as a bridge

Tor Browser 10.5 Snowflake bridge

With Snowflake, censored users can rely on proxies run by volunteers to connect to the internet.

During Q1 this year, the UX team ran a survey on Tor Browser Alpha to better understand Snowflake’s user experience. The survey received 1,795 complete responses, of which 726 participants confirmed they use Snowflake as a pluggable transport. The majority of Snowflake users who completed the survey began using Tor Browser several times a week within the past year. 75% of users had a positive view of Snowflake, although many experienced connection troubles and slow speeds while browsing. These facts and the stable network of volunteers allow us to make it available on this release.

› Read more about Snowflake's stable release

Improving the user experience of connecting to Tor

Tor Browser 10.5 about:connect

Tor Launcher has acted as the options panel for advanced Tor network configurations over the years. It also serves as a control point for users who are in censored networks. The UX and the Anti-Censorship teams joined efforts to improve the connecting flow for Tor Browser users. This release is the first in the upcoming series of helping censored users seamlessly access the open internet by simplifying the connection flow, detecting censorship and providing bridges.

› Read more about the new connection experience

Known Issues

Tor Browser 10.5 comes with a number of known issues:

 

Changelog

The full changelog since Tor Browser 10.0.18

  • All Platforms
    • Update NoScript to 11.2.9
    • Update Tor Launcher to 0.2.30
    • Translations update
    • Bug 25483: Provide Snowflake based on Pion for Windows, macOS, and Linux
    • Bug 33761: Remove unnecessary snowflake dependencies
    • Bug 40064: Bump libevent to 2.1.12
    • Bug 40137: Migrate https-everywhere storage to idb
    • Bug 40261: Bump versions of snowflake and webrtc
    • Bug 40263: Update domain front for Snowflake
    • Bug 40302: Update version of snowflake
    • Bug 40030: DuckDuckGo redirect to html doesn't work
  • Windows + OS X + Linux
    • Bug 27476: Implement about:torconnect captive portal within Tor Browser [tor-browser]
    • Bug 32228: Bookmark TPO support domains in Tor Browser
    • Bug 33803: Add a secondary nightly MAR signing key [tor-browser]
    • Bug 33954: Consider different approach for Bug 2176
    • Bug 34345: "Don't Bootstrap" Startup Mode
    • Bug 40011: Rename tor-browser-brand.ftl to brand.ftl
    • Bug 40012: Fix about:tor not loading some images in 82
    • Bug 40138: Move our primary nightly MAR signing key to tor-browser
    • Bug 40209: Implement Basic Crypto Safety
    • Bug 40428: Correct minor Cryptocurrency warning string typo
    • Bug 40429: Update Onboarding for 10.5
    • Bug 40455: Block or recover background requests after bootstrap
    • Bug 40456: Update the SecureDrop HTTPS-Everywhere update channel
    • Bug 40475: Include clearing CORS preflight cache
    • Bug 40478: Onion alias url rewrite is broken
    • Bug 40484: Bootstrapping page show Quickstart text
    • Bug 40490: BridgeDB bridge captcha selection is broken in alpha
    • Bug 40495: Onion pattern is focusable by click on about:torconnect
    • Bug 40499: Onion Alias doesn't work with TOR_SKIP_LAUNCH
  • Android
    • Bug 30318: Integrate snowflake into mobile Tor Browser
    • Bug 40206: Disable the /etc/hosts parser
  • Linux
    • Bug 40089: Remove CentOS 6 support for Tor Browser 10.5
  • Build System
    • All Platforms
      • Update Go to 1.15.13
      • Bug 23631: Use rootless containers [tor-browser-build]
      • Bug 33693: Change snowflake and meek dummy address [tor-browser]
      • Bug 40016: getfpaths is not setting origin_project
      • Bug 40169: Update apt package cache after calling pre_pkginst, too
      • Bug 40194: Remove osname part in cbindgen filename
    • Windows + OS X + Linux
      • Bug 40081: Build Mozilla code with --enable-rust-simd
      • Bug 40104: Use our TMPDIR when creating our .mar files
      • Bug 40133: Bump Rust version for ESR 78 to 1.43.0
      • Bug 40166: Update apt cache before calling pre_pkginst in container-image config
    • Android
      • Bug 28672: Android reproducible build of Snowflake
      • Bug 40313: Use apt-get to install openjdk-8 .deb files with their dependencies
    • Windows
    • Linux
      • Bug 26238: Move to Debian Jessie for our Linux builds
      • Bug 31729: Support Wayland
      • Bug 40041: Remove CentOS 6 support for 10.5 series
      • Bug 40103: Add i386 pkg-config path for linux-i686
      • Bug 40112: Strip libstdc++ we ship
      • Bug 40118: Add missing libdrm dev package to firefox container
      • Bug 40235: Bump apt for Jessie containers

     

    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.

Updates:

2021-07-06 1900 UTC: Due to Bug 40324, Android Tor Browser 10.5 should not be installed.

2021-07-06 20:50 UTC: We are aware of issues related to saved passwords becoming unavailable after upgrading to Tor Browser 10.5. Please see tpo/applications/tor-browser#40506 for more information about the investigation.

2021-07-07 18:00 UTC: Tor Browser 10.5.1 is now available for Android as a fix for Bug 40324.

Anonymous

July 06, 2021

Permalink

You should add Firefox multi account container add-on support so that user can log in to a multiple accounts on the same website at the same time through a different Tor circuit.

Anonymous

July 06, 2021

Permalink

Great work. Unfortunately, the default DuckDuckGo Onion Search Engine is hardcoded still to their v2 onion, please update it to their v3 onion ! Now every time I want to search, it shows me that neat warning :(

Anonymous

July 06, 2021

Permalink

Thanks for your hard work, and thanks for accepting various kinds of donations!

FYI: When you open Proton Mail's v3 onion login page
protonmailrmez3lotccipshtkleegetolb73fuirgj7r4o4vfu7ozyd.onion/login
a 1x1 transparent GIF is dynamically sent from v2 address
protonirockerxow.onion/assets/host.png
It's a kind of "mixed content" and TB doesn't worn about this... I asked PM to fix this 2 weeks ago, and they're not exactly quick... (they did say they're working on it)

Can you write an issue ticket to ProtonMail describing that bug?
https://github.com/ProtonMail/WebClient/issues

Small transparent GIFs are almost always used to log metadata about users' visits. Usually, this is done through a third party analytics service whose JavaScript or images the first party site embeds into their HTML. But you said the GIF is from the first party site, so the metadata is sent directly to ProtonMail's developers. Ask ProtonMail why they use transparent GIFs and if the data they collect is made viewable to the public. (In comparison, Tor Project provides access to its various data sources and data services from a Metrics website and is extraordinarily hesitant, scrupulous and deferential to its users about collecting data.)

> It's a kind of "mixed content" and TB doesn't worn about this

Did Tor Browser display an icon as a warning? I don't know if the triggers for these icons cover the situation you describe. (Do they, sysrqb?)
https://support.torproject.org/onionservices/onionservices-5/

ProtonMail is serving the 1x1 transparent GIF from the v3 domain now, so Tor Browser wouldn't display warnings for that anymore if it did when you saw it.

Anonymous

July 06, 2021

Permalink

When switch from Obfs4 to Snowflake, Then firewall message pop up and warning that can cause issue on internet. So, I have to switch back to Obfs4 is no issue so far since I use Obfs4 for many years.

> Snowflake, Then firewall message pop up and warning that can cause issue on internet.

Is it safe for you to paste the firewall message here to us? What type of firewall? Is the firewall software running on your device or on a different device on the network? Are you able to reconfigure the firewall? If you feel it is not safe for you to paste the message here, you could send it by PGP-encrypted e-mail from a temporary e-mail address: https://support.torproject.org/misc/bug-or-feedback/

To blog moderators: Make sure to redact bridge IP addresses, fingerprints, etc.

Anonymous

July 06, 2021

Permalink

Please optimize the images in your blog posts.
That banner at top of this is >1MB, one pass in optipng cuts off 40%!
Even then such a simple banner doesn't need to be 600KB.

Thanks for the nudge! It looks like you've actually discovered a bug with the blog, as the image itself in the back-end is only a few kb large. I've applied an ad hoc fix to reduce it to a more reasonable size here.

Anonymous

July 06, 2021

Permalink

why new tb doesn go automatically to home pages set, but remains in the new "always connect" page???

Anonymous

July 07, 2021

Permalink

"Snowflake currently uses domain fronting for the initial connection to match users with Snowflake proxies, and to allow each peer to exchange the connection information necessary for WebRTC."

Does domain fronting use DNS? Can eavesdroppers learn that you are using Tor bridges that are unlisted by reading the eavesdropped packets of Snowflake's initial connection and peer exchanges? Can eavesdroppers inject valid counterfeit versions of those packets? Obfs4 doesn't use domain fronting or DNS.

The only DNS request that clients issue when connecting to snowflake are for the front domain (cdn.sstatic.net) which does not correspond to or leak private bridge usage. The point of domain fronting is to hide censorship circumvention behind large front domains and edge services. To learn more, check out the original domain fronting academic paper: https://www.icir.org/vern/papers/meek-PETS-2015.pdf.

All connections in Snowflake are end-to-end encrypted, so eavesdroppers cannot decrypt/inject/modify packets or otherwise man-in-the-middle any of these connections. The initial domain-fronted connection is end-to-end encrypted using TLS, and the peer connections are end to end encrypted using DTLS.

So eavesdroppers could observe that metadata of connections to a static number (3?) of initial snowflakes (unlisted relays intended not to be known that they run Tor) always will be preceded by metadata of a connection to cdn.sstatic.net. The front domain's DNS hopefully should not reply with a long-term IP used exclusively by the bootstrap server. If it does, or if an adversary considers the servers that share the IP as acceptable losses, then the bootstrap server could be IP-blocked or censored, or its IP could be logged as metadata to identify client IPs that use unlisted bridges and to identify possible unlisted snowflakes that register with the bootstrap server and client IPs that connect to those. Employees of the front domain's CDN hopefully should not be able to modify the bootstrap daemon or interrupt it which would let them discover that it is the bootstrap server.

Spoofing of DNS is mitigated by E2E encryption certificates in the signed client. Those certificates authenticate the front domain and hopefully the bootstrap server in the domain's CDN. The bootstrap daemon replies through the encrypted tunnel with certificates of snowflakes that, among other purposes, authenticate those snowflakes which mitigates an adversary attempting to redirect the client to a counterfeit snowflake-Tor network. Snowflakes hopefully do not register themselves on the bootstrap server by their domain name but by their IP, so spoofing the DNS of individual snowflakes should not have an effect. However, the absence of a DNS request from a client is metadata that could be used for identification. Spoofing IP addresses is much more expensive than spoofing DNS but is mitigated by authenticating certificates.

> So eavesdroppers could observe that metadata of connections to a static number (3?) of initial snowflakes (unlisted relays intended not to be known that they run Tor) always will be preceded by metadata of a connection to cdn.sstatic.net.

Snowflakes don't run Tor, they are merely proxies that copy data from the client to the Snowflake bridge. You can read more about Snowflake in this thesis chapter, and the technical writeup. And a client only makes a connection to a single Snowflake at the moment (not 3).

But, more to your point, I believe you're trying to say that it would be easy for a censor to see that someone is using Snowflake and block it. What is easy or hard for censors in the anti-censorship space is not always immediately intuitive. It's much more complex than simply identifying a pattern that all Snowflake connections share as you've done here. We have no evidence up to this point of censors being able to track the use of circumvention tools over multiple flows as you've described. And furthermore, the pattern you've identified is something at all WebRTC applications have in common. So if a censor is looking for an HTTPS connection to a major cloud provider and then a P2P connection that follows and decides to block all P2P connections that fit this pattern, they will end up blocking as collateral damage most other WebRTC applications.

> The front domain's DNS hopefully should not reply with a long-term IP used exclusively by the bootstrap server. If it does, or if an adversary considers the servers that share the IP as acceptable losses, then the bootstrap server could be IP-blocked or censored

This is exactly the purpose of domain fronting: to provide a front that has high collateral damage (if a censor blocks the front domain, they block access to many other services). In practice we've found that this works and that our choices and configuration of the front domain have been good. The front domain we use for Snowflake has not been blocked anywhere to our knowledge.

Anonymous

July 07, 2021

Permalink

"During Q1 this year, the UX team ran a survey on Tor Browser Alpha to better understand Snowflake’s user experience."

The fact that 70% of those Tor Browser users were on Android, not desktop, has not been mentioned in the blog posts, but I think it's particularly important.

Anonymous

July 07, 2021

Permalink

In known issues, tpo/applications/fenix#40324 links to 40115, and 40324 points to a 404 Page.

Anonymous

July 07, 2021

Permalink

Hi
I have a question
I always check for updates and keep Torbrowser updated, but even with version 10.5 when I typing something in the address bar section and choose to search with "DuckDuckGo Onion" I'ts redirecting me to v2 version of DDG and in my "Torbrowser Preferences" section is only v2 version of DDG Onion. I had to search for DDG v3 Onion on their official channels and found it only on their Twitter here: https://twitter.com/DuckDuckGo/status/1412045351880626179 (I leave this tweet here if someone like me will looking for v3 Onion DDG because it's not so obvious where to looking for it. I can't see that info about v3 on their website or blog and because I want official address directly from DDG I'm glad to found it on their Twitter) So, my question is: Does Torbrowser is not updating DuckDuckGo v2 to v3 address in "Preferences" section and we must manually change it in the settings?

Anonymous

July 07, 2021

Permalink

Hello... After official update (directly done by Tor Browser itself) to 10.5, Windows defender stopped TOR with file: C:\Users\Stefan\Desktop\Tor Browser\Browser\TorBrowser\Tor\PluggableTransports\snowflake-client.exe would be Trojan:Win32/Zpevdo.B. My Windows 10 version 2004, 19041.1052 I think this is a typically false alert from defender, but it would be interesting, if other people also getting this defender alert?

Anonymous

July 08, 2021

Permalink

After the update from the previous version to this 10.5 with the builtin updater my logins and passwords database seems to be gone, which is unfortunate.
Data for non-password fields is still remembered (like old terms typed into the search fields of websites is still suggested to be entered again), but passwords are not anymore and about:logins shows an empty list.
Also if a new password is saved now, the list will be empty again the next time Tor Browser is launched. This never happened on previous versions or version updates.

Anonymous

July 08, 2021

Permalink

Another minor ux thing:
When the option "restore previous session" is used, the new connecting to tor tab will replace the tab that was last open in the previous session.
As in I have torproject.org and eff.org open in two tabs, with eff.org being the active one when I close the browser.
On starting the browser again I will have one tab still being torproject.org, but what was the eff.org tab will be first the connecting to tor window, and then empty.
This used to work as expected before.

Anonymous

July 08, 2021

Permalink

Great job as always, I just have one suggestion.

It'd be nice if the user could reset the circuit to the currently connecting destination instead of the page that is already opened. The way it's now the user has to wait for the connection to timeout (1min30s?) and Firefox's error page to appear before being able to reset the circuit to the failed destination. (I'm guessing resetting the circuit then finally works because Firefox's error page works as a placeholder for the destination.)

An example: you use duckduckgo to search for something, then click on some result link. The linked page doesn't load at all for quite a while, so you try resetting the circuit, but instead the duckduckgo result page is reset.

That reminds me of how when Youtube decides to block your circuit, they redirect you to an error page on google.com. It doesn't help to hit the button to create a new circuit for Youtube because the tab goes goes to google immediately, so it creates a circuit for google. You either have to close the whole browser, or wait 10 minutes, or use a proxy like Invidious. It isn't the same as your issue, but it reminds me of it.

Anonymous

July 08, 2021

Permalink

Since updating to version 10.5 I can no longer use the address bar for search navigation.
My search parameters populate in the address bar but nothing renders in the tab.
This functionality is not broken on my other system (version 10.0.18).
I have toggled this setting in Preferences to test, does not resolve.
I've tried reinstalling, does not resolve.
For now I am having to duplicate the default page if I want to access websites in multiple tabs.

System: arch
Helper: pacman
Source: https://github.com/micahflee/torbrowser-launcher
Name : torbrowser-launcher
Version : 0.3.4-2

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

3 + 12 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.