New Release: Tor Browser 10.5a7

by sysrqb | January 19, 2021

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

Note: This is an alpha release, an experimental version for users who want to help us test new features. For everyone else, we recommend downloading the latest stable release instead.

This release updates Firefox to 78.6.1esr for desktop and Firefox for Android to 85.0.0-beta.7. Additionally, we update Tor to 0.4.5.3-rc. This versions also fixes a crash seen by macOS users on the new M1 processor.

Note: We are investigating a build reproducibility issue for the Android packages. We identified where the packages from different builders differ and we are working on a fix for the next version.

Note: We are aware that default bridges are not currently working in recent Tor Browser Alpha versions and Tor Browser does not start, as a result. The issue is being actively investigated.

Update: The issue impacting default bridges should now be resolved in recent Tor Browser Nightly versions.

Note: Tor Browser 10.5 does not support CentOS 6.

The full changelog since Tor Browser 10.5a6 is:

  • All Platforms
    • Update NoScript to 11.1.8
    • Bug 40204: Update Tor to 0.4.5.3-rc
    • Translations update
  • Windows + OS X + Linux
    • Update Firefox to 78.6.1esr
    • Bug 40287: Switch DDG search from POST to GET
    • Bug 40297: Rebase 10.5 patches onto 78.6.1esr
  • Android
  • OS X
    • Bug 40262: Browser tabs crashing on the new Macbooks with the M1 chip
  • Build System
    • All Platforms
      • Bug 40194: Remove osname part in cbindgen filename
    • Android
      • Bug 40162: Build Fenix instrumented tests apk
      • Bug 40190: Update toolchain for Fenix 85
      • Bug 40191: Update Fenix and dependencies to 85.0.0-beta1
      • Bug 40193: Build all mobile Rust targets in a single step
      • Bug 40195: repo.spring.io is not usable anymore
Tags
tor browser
tbb
tbb-10.5
Jason

Concerned Tor User (not verified) said:

January 19, 2021

Permalink

"Bug 40287 fix" (Switch DDG search from POST to GET) is a hit on our privacy and an errosion of anonymity of all TorBrowser users, since DDG is the default search engine.

The GET method discloses the search keywords clearly in the URL request, as the URL is not encrypted by means of HTTPS. The Tor encryption is great, but a malicious Tor node can "see" the search queries in clear, and collect information on Tor users, in time leading to corellation and deanonymization. I protest.

Even the justifying reason for this "improvement fix" is quite weak (see https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/402… ):
To help that coder, simply tell him/her to open the needed links as the browser's New Tabs while keeping the original search results Tab until finished!
Is not this a natural solution we've already came to use while browsing?

That is not correct. The path and query strings are encrypted by HTTPS. When using HTTPS (which is enforced for duckduckgo.com) the url is not visible to the exit node. We are assuming that DuckDuckGo logs all post requests, so the POST method does not provide any additional security or privacy over GET, and it only hurts the usability of Tor Browser.

In my TB (10.0.8), when I click back in the DDG search scenario described above, a box pops up asking if I want to "Resend" (do the POST again) because the results are no longer cached.

I think it is probably not that big of a deal from a privacy perspective. There is a difference that POSTed search terms don't get logged in detail in webserver logs because the search terms are not part of the URL, so they are less visible to an attacker who manages to get the URL logs. However, that is not the threat model being described, and it is muted by other privacy protections built into Tor Browser while using Tor.

On that note, it would be nice if you could bring back DuckDuckGo SSL Lite and DuckDuckGo Onion SSL Lite search engines. I modify my search.json.mozlz4 file to use those non-javascript versions - they render much faster on slower hardware, although there is some functionality loss without javascript.

Also, thanks to the Tor Browser and Tor teams for all of your hard work! :-)

> DuckDuckGo SSL Lite and DuckDuckGo Onion SSL Lite

Variations of the same engine increase the entropy (uniqueness, trackability) of your browser fingerprint. If you want non-javascript, use Safest security level, and DDG will redirect to those non-JS versions.

From the Answer #12 here: https://security.stackexchange.com/questions/7705/does-ssl-tls-https-hide-the-urls-being-accessed

Yes and no.

The url is encrypted properly, so query parameters should never be revealed directly.
However, traffic analysis can get the length of the URL often - and knowing the server and the length of the url is often enough to eavesdrop what pages are being accessed, especially if assuming that links on a page are clicked.
Google for "traffic analysis ssl browsing" or something similar if the topic interests you. [...]

That answer is a little deceiving. That information is similarly included when you send a query via POST. The only real difference between GET and POST from the perspective of a network adversary is the location of the query within the message.

URL is not encrypted by means of HTTPS

yes it is?
If you do any DDG search directly on the website, that already uses a GET request. GET and POST don't differ when it comes to encryption. In this context the only difference between them is your search terms appearing in the url.

> The GET method discloses the search keywords clearly in the URL request

That bit is true. Parameters such as query keywords are disclosed to the client's device and to the web server, but thanks to HTTPS which envelopes both GET and POST, parameters are not disclosed to eavesdroppers. As alluded by "Anonymous IT Security Guy" and the coder on gitlab, POST interferes with the Back button and with saving parameters in URLs of the client's bookmarks and history, but POST makes parameters a bit harder to log by the web server.

Hits on privacy of GET and POST in HTTPS are based on who controls the logging capability. Software is able to log URLs which include parameters sent via GET, but it's trivial to log parameters sent via POST. Tor Browser defaults to not saving history to disk, but it allows users to save bookmarks to disk at their own risk. So in Tor Browser, POST improves privacy of the bookmarks of that search engine on the client's device at the cost of degrading usability, but it does not assuredly improve privacy of logs on the server.

Jason

opaipa (not verified) said:

January 19, 2021

Permalink

Downloaded 10.5a7 - win10 pro 64b

- Installed portable/new: after configurating bridge (obfs4) - TOR doesn't start.
- Updating portable 10.5a4 - TOR doesn't start

Log:
1/20/21, 07:03:13.305 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
1/20/21, 07:03:13.305 [WARN] Bridge line with transport obfs4 is missing a ClientTransportPlugin line
1/20/21, 07:03:13.305 [ERR] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.4.5.3-rc e5c47d295bd3dc35)

As written yesterday - please don't make this version broadly available - stop and retract/withdraw from distribution channels - fix this nogo-bug first!
What's up with (automated) testing?

Thank you,
seems more complicated than expected. It also evaded testsuites...

Re: "Let's try remembering this for 10.5a8."
Would you mind writing/telling as soon as there are nightlies which you are assuming to fix this?

Thanx
Yes, it's alpha, but since the update ruins existing configurations (rendering TBa unusable) - shouldn't you stop the update process until there's is a viable solution for updating?
And/or add a red CAVEAT at the announcing blog-statement above?

Jason

Tyler (not verified) said:

January 22, 2021

Permalink

The .dmg download links for most of the MacOS releases do not exist, there is only the one for TorBrowser-10.5a7-osx64_ar.dmg.