New Release: Tor Browser 10.5

by antonela | July 6, 2021

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.

Comments

Please note that the comment area below has been archived.

FX124 (not verified) said:

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.

DonJoe (not verified) said:

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 (not verified) said:

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://jqlsbiwihs.oedi.net/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.

Unknown (not verified) said:

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://jqlsbiwihs.oedi.net/misc/bug-or-feedback/

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

OPTIMZR (not verified) said:

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.

sb (not verified) said:

July 06, 2021

Permalink

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

Anonymous (not verified) said:

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.

Anonymous (not verified) said:

July 14, 2021

Permalink

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 (not verified) said:

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 (not verified) said:

July 07, 2021

Permalink

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

Anonymous (not verified) said:

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?

Stefan (not verified) said:

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?

snowflake (not verified) said:

July 07, 2021

Permalink

Should I open webrtc in Tor browser when using snowflake? In the about:flags, webrtc is closed by Tor browser.

No, in general you should not change any settings in `about:config`. Snowflake does not use webrtc in the browser, snowflake is a separate program and contains its own webrtc. Webrtc should not be enabled in the browser.

deserving shad… (not verified) said:

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.

deserving shad… (not verified) said:

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 (not verified) said:

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.

Unfortunately this is difficult due when the new url is associated with the current tab and how Tor Browser learns about the associated circuit, but your suggestion is a good UX improvement.

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.

Allen (not verified) said:

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

Chuck (not verified) said:

July 08, 2021

Permalink

For tor browser 10.5, the change in connecting to TOR is not leaving the cursor in the address bar, which is inconvenient (but not quite so inconvenient as the failure of saved passwords, which you have an open bug for).

Also, it would be really helpful for anyone reviewing this page if the Known Bugs had the bug title next to them so they don't waste time opening each one to see if it of relevance to them.

HTH,

Chuck

poorenglish (not verified) said:

July 08, 2021

Permalink

All my password storage lists are gone
If you turn it off and on again, it is reset even if you input a new

StartledStan (not verified) said:

July 09, 2021

Permalink

Hello. Sorry if this is the wrong place to ask, but is the torrc file ignored by the current built or is that just me? Thank you for your time.

Ted (not verified) said:

July 10, 2021

Permalink

My saved logins and passwords were deleted during the update, what happened? Is it possible to get them back?

Anonymous (not verified) said:

July 11, 2021

Permalink

2 issues in 10.5:

1. "DuckDuckGoOnion" search provider is still using the v2 address.

2. Tor browser windows size is "1052 x 714" upon launch, but it is "1054 x 715" after using the "new identity" button. (Ubuntu 18.04.5 LTS / Xfce 4.12)

For number 2, check your window size dimensions here:
- https://fpcentral.tbb.torproject.org/ -- Do "Run JavaScript Tests". Look for screen.width, height and screen.availHeight, Width.
- https://arkenfox.github.io/TZP/tzp.html -- Look under the header labeled "screen".

The dimensions that a website sees should be a multiple of 200x100 px. The outer size that I think you are talking about should not matter in terms of fingerprinting. Did you change the vertical size of the inner content panel by, for example, enabling a toolbar?

You performance may vary depending on your location and your local network setup. Some users with very restrictive firewalls on their home networks, or users connecting over a mobile network, experience a long delay in the initial bootstrapping of the Tor connection. We're continuing to work on improving the performance of Snowflake.

Anon (not verified) said:

July 13, 2021

Permalink

I have two questions =) first) why i had to configure addons(noscript+https) icons manually(so they can be shown on a toolbar), and second all pages in fullscreen mode opening with white borders on both corners of browser's window. I'll be very thankful if you will be able to find some time to answer my questions. Thank you

Anon (not verified) said:

July 13, 2021

Permalink

Big thanks for your answer. I got exactly that amount of information that i was hoping for. Good luck to you and thanks for a feedback!

Anonymous (not verified) said:

July 13, 2021

Permalink

OnionCircuits does not work after updating to 10.5.
Console shows 'Tor requires a password to authenticate'.
but nyx works fine without password.
I'm on ubuntu.

Anonymous (not verified) said:

July 14, 2021

Permalink

Snowflakes are more ephemeral than other bridges. If the snowflakes offered to a client go offline while the client is in a session, does the client automatically request new snowflakes in that session? Is such a request made to the front domain, or is it anticipated by the client and requested through the remaining snowflakes before the last one known to the client goes offline?

Anonymous (not verified) said:

July 17, 2021

Permalink

Tor Browser 10.5.2 on linux doesn't follow system theme as before.
I have a dark desktop and before Tor Browser follows the dark theme, now it has its default light theme.