New Release: Tor Browser 8.5.4

Tor Browser 8.5.4 is now available from the Tor Browser Download page and also from our distribution directory.

Tor Browser 8.5.4 contains updates to a number of its components. Above all, we include Firefox 60.8.0esr which contains important security fixes. Moreover, after some testing in the alpha series, we start shipping Tor 0.4.0.5 and update OpenSSL to 1.0.2s for the desktop platforms.

Finally, we add a fundraising banner to help us getting more donations. Please donate if you can!

The full changelog since Tor Browser 8.5.3 is:

  • All platforms
    • Update Firefox to 60.8.0esr
    • Update Torbutton to 2.1.12
      • Bug 30577: Add Fundraising Banner
      • Bug 31041: Stop syncing network.cookie.lifetimePolicy
      • Translations update
    • Update HTTPS Everywhere to 2019.6.27
    • Bug 31055+31058: Remove four default bridges
    • Bug 30712: Backport fix for Mozilla's bug 1552993
    • Bug 30849: Backport fixes for Mozilla's bug 1552627 and 1549833
  • Windows + OS X + Linux
    • Update Tor to 0.4.0.5
    • Update OpenSSL to 1.0.2s
    • Bug 29045: Ensure that tor does not start up in dormant mode
  • OS X
    • Bug 30631: Blurry Tor Browser icon on macOS app switcher
k239

July 09, 2019

Permalink

The obfs4 bridges IP addresses are listed in the file torrc. On my Mac the file produces 13 OBFS4 bridges and there IP addresses. When I deleted the file the same obfs4 files appeared with a change in order. In version 8.53 of Tor comments that this IP address should be hidden. Should I expect different torrc files when reinstalling or opening Tor ?

The IP addresses should not be hidden in your torrc file. They should just not get publicly posted on the Internet. If you are using the default bridges we ship, no, they stay the same within your torrc file (if we don't remove them from the bundle).

On my Mac with Tor configured to "Tor censored in my country" if I open the torrc file it has 11 OBFS4 files starting with "Bridge obfs4" then the IP address of each bridgeis listed. This makes the obfs4 bridges visible. These are the only bridges the Tor browser uses and this occurs on 2 Mac OS's.

If "Tor censored in my country" is not selected the torrc file is bank.

how many obfs4 bridges exist? should the 11 obfs4 bridges in the torrc file change ?

You can find the list of default bridges at https://gitweb.torproject.org/builders/tor-browser-build.git/tree/proje…. The list you see in the Tor configuration file should match that one.

My torrc fle does not match the file you provided. For example there are bridges for "snowflake" I have never seen that bridge even when I go to "https://bridges.torproject.org/" also all the bridges are obfs4 your example also has meek. Since the upgrade to 8.5.4 the bridge list is different.

# Tor Launcher preferences (default bridges):
pref("extensions.torlauncher.default_bridge_recommended_type", "obfs4");

// Default bridges.
pref("extensions.torlauncher.default_bridge.obfs4.1", "obfs4 192.95.36.142:443 CDF2E852BF539B82BD10E27E9115A31734E378C2 cert=qUVQ0srL1JI/vO6V6m/24anYXiJD3QP2HgzUKQtQ7GRqqUvs7P+tG43RtAqdhLOALP7DJQ iat-mode=1");
pref("extensions.torlauncher.default_bridge.obfs4.2", "obfs4 85.17.30.79:443 FC259A04A328A07FED1413E9FC6526530D9FD87A cert=RutxZlu8BtyP+y0NX7bAVD41+J/qXNhHUrKjFkRSdiBAhIHIQLhKQ2HxESAKZprn/lR3KA iat-mode=0");
pref("extensions.torlauncher.default_bridge.obfs4.3", "obfs4 38.229.1.78:80 C8CBDB2464FC9804A69531437BCF2BE31FDD2EE4 cert=Hmyfd2ev46gGY7NoVxA9ngrPF2zCZtzskRTzoWXbxNkzeVnGFPWmrTtILRyqCTjHR+s9dg iat-mode=1");
/**/pref/**/(/**/"extensions.torlauncher.default_bridge.obfs4.4"/**/, /**/"obfs4 38.229.33.83:80 0BAC39417268B96B9F514E7F63FA6FBA1A788955 cert=VwEFpk9F/UN9JED7XpG1XOjm/O8ZCXK80oPecgWnNDZDv5pdkhq1OpbAH0wNqOT6H6BmRQ iat-mode=1");
pref("extensions.torlauncher.default_bridge.obfs4.5", "obfs4 [2001:470:b381:bfff:216:3eff:fe23:d6c3]:443 CDF2E852BF539B82BD10E27E9115A31734E378C2 cert=qUVQ0srL1JI/vO6V6m/24anYXiJD3QP2HgzUKQtQ7GRqqUvs7P+tG43RtAqdhLOALP7DJQ iat-mode=1");
pref("extensions.torlauncher.default_bridge.obfs4.6", "obfs4 37.218.240.34:40035 88CD36D45A35271963EF82E511C8827A24730913 cert=eGXYfWODcgqIdPJ+rRupg4GGvVGfh25FWaIXZkit206OSngsp7GAIiGIXOJJROMxEqFKJg iat-mode=1");
pref("extensions.torlauncher.default_bridge.obfs4.7", "obfs4 37.218.245.14:38224 D9A82D2F9C2F65A18407B1D2B764F130847F8B5D cert=bjRaMrr1BRiAW8IE9U5z27fQaYgOhX1UCmOpg2pFpoMvo6ZgQMzLsaTzzQNTlm7hNcb+Sg iat-mode=0");
pref("extensions.torlauncher.default_bridge.obfs4.8", "obfs4 85.31.186.98:443 011F2599C0E9B27EE74B353155E244813763C3E5 cert=ayq0XzCwhpdysn5o0EyDUbmSOx3X/oTEbzDMvczHOdBJKlvIdHHLJGkZARtT4dcBFArPPg iat-mode=0");
pref("extensions.torlauncher.default_bridge.obfs4.9", "obfs4 85.31.186.26:443 91A6354697E6B02A386312F68D82CF86824D3606 cert=PBwr+S8JTVZo6MPdHnkTwXJPILWADLqfMGoVvhZClMq/Urndyd42BwX9YFJHZnBB3H0XCw iat-mode=0");
pref("extensions.torlauncher.default_bridge.obfs4.10", "obfs4 216.252.162.21:46089 0DB8799466902192B6C7576D58D4F7F714EC87C1 cert=XPUwcQPxEXExHfJYX58gZXN7mYpos7VNAHbkgERNFg+FCVNzuYo1Wp+uMscl3aR9hO2DRQ iat-mode=0");
pref("extensions.torlauncher.default_bridge.obfs4.11", "obfs4 144.217.20.138:80 FB70B257C162BF1038CA669D568D76F5B7F0BABB cert=vYIV5MgrghGQvZPIi1tJwnzorMgqgmlKaB77Y3Z9Q/v94wZBOAXkW+fdx4aSxLVnKO+xNw iat-mode=0");

pref("extensions.torlauncher.default_bridge.meek-azure.1", "meek 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com");

pref("extensions.torlauncher.default_bridge.snowflake.1", "snowflake 0.0.3.0:1 2B280B23E1107BB62ABFC40DDCC8824814F80A72");

I noticed that you posted my torrc file for 8.5.4 while in 8.5.3 the IP address was removed with others reporting it discloses bridges which are in the torrc file itself.

What happened that is different between 8.5.3 and 8.5.4

Blog entries looks raw like with no Page Style recently.

Yeah, we have issues with out Drupal setup (if you know someone who could help with that let us know!), which is tracked at https://trac.torproject.org/projects/tor/ticket/31114.

Good to know you know about the blog issue (I noticed it also but didn't report it).

But the allegations that a key Tor Project GPG key has been "poisoned" (see below) seems quite serious.

Posts from Daniel Kahn Gilmore and R. J. Hansen make it clear that the key poisoning is very serious and has the potential to make it difficult for anyone to use GPG/PGP keys to verify the integrity of Tor Browser bundle downloads, Tails ISO images, Debian install ISO images, etc. Coming at a time when many Debian users are installing Buster (new stable) this attack has the potential to be particularly damaging. Unfortunately, it seems that debian.org has not yet posted prominent warnings to avoid trying to download the latest version of signing keys from the SKS keyserver network.

IMO, Tor Project needs to address this issue with a dedicated blog post offering detailed advice on how to obtain and maintain a keyring holding the (public half of) the signing keys.

The actors are unknown but it seems particularly vicious that they targeted DKG who has been trying to fix this vulnerability for years. But we know that in recent weeks the viciousness of apparently state sponsored cyberattacks has dramatically increased.

Long-winded but basically "address this issue with a dedicated blog post". Yes, +1.

how close are you to fixing the current DDoS issues? they're very annoying.

hey, for some reason i found obs3 to work faster. i've seen they were removed - is it permanent? thanks

I would like to know the difference between obs3 and os 4

obfs4 > obfs3
obfs3 is deprecated.

If we get new default bridges we might ship them again, not sure. That said, you can still use obfs3 bridges if you get them e.g. from BridgeDB, just the default bridges are gone for now at least.

When Will The new version Come to Android?

8.5.4 is already available on our website, F-Droid, and Google Play.

Anyone else having issues logging in to their YouTube account? Seems stuck in the welcome screen after putting the password. I'm on Trisquel 8 x86 by the way..

FYI, I just downloaded the 8.5.4 release. My current 8.5.3 release also automatically updated to 8.5.4. When I restarted tor, Norton anti-virus threw a firewall error - "tor does not have a valid digital signature". I deleted my current tor installation and installed a new copy from the 8.5.4 release and had no error. Support may encounter this problem.

Thanks for the heads-up!

Hello. First off, thank you for the TOR Browser. :-) This is a much-needed tool in a world which is quickly becoming a surveillance society (why the Hell were we fighting against those like Stalin and Hitler who wanted to place everyone under surveillance if we were just going to allow it to be done to ourselves a few decades later?!). Been using encryption for quite some time, and, in the mid-1990s, used 4,096bit encryption for my e-mails when most of the population believed that governments or corporations would never, ever spy upon people. LOL

However, I'm writing to you today to ask why it is now taking around four to five minutes to load the keyring. Noticed this when typing out "torbrowser-launcher" (without the quotes, naturally) in Terminal and waited . . . and waited . . . until, finally, my patience was rewarded with the launch of the TOR Browser.

Just curious as to why it's now taking longer to load than micro$haft winblows 3.1 did (and, before you ask, I no longer have the (non-)floppy installation disks).

> why it is now taking around four to five minutes to load the keyring.

Sounds like your keyring may have been poisoned. Did you import the signing key from an SKS keyserver? Or did your GPG possibly autoupdate from an SKS keyserver?

See this post from R.J. Hansen, the maintainer of the GPG FAQ:

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

> In the last week of June 2019 unknown actors deployed a certificate spamming attack against two high-profile contributors in the OpenPGP community (Robert J. Hansen and Daniel Kahn Gillmor, better known in the community as "rjh" and "dkg"). This attack exploited a defect in the OpenPGP protocol itself in order to "poison" rjh and dkg's OpenPGP certificates. Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways. Poisoned certificates are already on the SKS keyserver network. There is no reason to believe the attacker will stop at just poisoning two certificates. Further, given the ease of the attack and the highly publicized success of the attack, it is prudent to believe other certificates will soon be poisoned.
>
> This attack cannot be mitigated by the SKS keyserver network in any reasonable time period. It is unlikely to be mitigated by the OpenPGP Working Group in any reasonable time period. Future releases of OpenPGP software will likely have some sort of mitigation, but there is no time frame. The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network.

> ...

> Any certificate may be poisoned at any time, and is unlikely to be discovered until it breaks an OpenPGP installation.

> The number one use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. If someone were to poison a vendor's public certificate and upload it to the keyserver network, the next time a system administrator refreshed their keyring from the keyserver network the vendor's now-poisoned certificate would be downloaded. At that point upgrades become impossible because the authenticity of downloaded packages cannot be verified. Even downloading the vendor's certificate and re-importing it would be of no use, because GnuPG would choke trying to import the new certificate. It is not hard to imagine how motivated adversaries could employ this against a Linux-based computer network.

> At present I (speaking only for myself) do not believe the global keyserver network is salvageable. High-risk users should stop using the keyserver network immediately.

It seems that there may be workarounds which may decrease the chance that a user will import a poisoned key, but once that happens your GPG is broken and cannot easily be fixed, which is devastating for those who always follow past TP Best Practice advice by using GPG detached signatures to verify the latest Tor Browser bundle before unpacking on our machine.

But I have yet to find anything which tells users how to obtain safely (?) the latest subkey of a signing key, which we will need to verify future editions of Tor Browser, Tails, etc. Not from an SKS keyserver, certainly, but if not there, where? I have been using Tor since well before the introduction of Tor Browser bundle and I have no idea how to address this. And Tor Project, Tails Project, Debian Project, are not saying anything at all, not even warning newbies to avoid breaking their GPG keyring by importing the TB signing key from an SKS keyserver. This is not good.

> there may be workarounds

Upload the key to hkps(or https)://keys.openpgp.org, but that keyserver is experimental and strips all signatures and unverified UIDs, so you can't depend on the web-of-trust to verify them (relevant only if you were connected well enough in the web of trust to use it before, and many users weren't and aren't). Upload a recent good copy of the keys somewhere else such as a torproject site, keybase, github, or all places. Block uploads of new signatures from anyone except the key owner, or set permissions to read-only until the situation is resolved.

To strip signatures (except the most recent self-signature on each user ID) and unverified UIDs:
$ gpg -ao keyout.asc --export-options export-minimal --export '[keyID]'

> how to obtain safely (?) the latest subkey

Servers for downloading keys will be a makeshift patchwork for quite a while, but these copies appear to work for now:
0xEE8CBC9E886DDD89
0x4E2C6E8793298290


in the mid-1990s, used 4,096bit encryption for my e-mails

No you weren't kid stop making up stories.
Because that's a bit early in time for 4096 to be available.

Is there a change to the ExcludeExitNodes directive?
Connection stalled while Tor Browser tried to connect to an exit in the blocked country, according to the Tor Circuit display.

Good question. I *think* nothing changed here. Is this issue reproducible?

I have country Z under ExcludeExitNodes. One established circuit had: Guard - Z - Z.

¯\_(ツ)_/¯

My tor proxy client is also doing this.
I excluded 4 countries using ExcludeNodes and set StrictNodes 1 in my torrc file and I am still exiting from 2 of the Excluded countried regularly.

Also maybe not related I get an establisehd connection to the same IP every time I do service tor start through my ethernet interface instead of 127.0.0.1 like every other established connection that uses the proxy which is also a coutnry I don't feel comfortable connecting to and makes no sense why I would just connect to this IP every time I start tor for no reason I can find.

Very hard to research anything since every result comes up as the browser amd that is not what I need.

I also understand that what I am doing is NOT reccomended but I am very careful to only use soxable(is that a word?) tcp connections through it.

I thought the idea was NOT to keep track of what you do. If so, please explain what is under

.../tor-browser_en-US/Browser/.local

The file recently-used.xbel is particularly troubling, though some of the others are, too.

Can someone answer this please?

Running strings on /tor-browser_en-US/Browser/.local/share/gvfs-metadata/home reveals all Downloads (including URL) I ever made made with Tor Browser.

Is this intended behaviour? Looking at https://2019.www.torproject.org/projects/torbrowser/design/#disk-avoida… implies it should not?

It's not intended but a bug. See: https://trac.torproject.org/projects/tor/ticket/17560. We are happy to take contributions and to review patches, so you are more than welcome to help fixing this problem. Thanks!

Yeah sorry, I found the ticket straight after asking.

Also, just because I know how to run strings doesn't mean I can code properly sadly :(

Counter-proposal: Have you ever considered to implement a list of long-standing known issues, link to it in your release announcements and, if possible, provide some workarounds, like Tails does: https://tails.boum.org/support/known_issues/index.en.html ?

If considered as a threat, the bug mentioned above is trivial for the end user to "solve" by just changing permissions of /tor-browser_en-US/Browser/.local/share to prevent Tor Browser to write to it, the directory is superfluous for Tor Browser to function.

To give you another example: I also ran blindly into the fact that beginning with Tor Browser 8.0 "New Identity" no longer resets NoScript's temporary permissions. Surely it's not too much of a hassle to just toggle the permissions back manually or simply close and reopen Tor Browser, prerequisites are, however, that people are aware of it.

I'd be more than happy to help out with documenting the most significant long term issues and searching for potential workarounds, provided that there's interest on your end.

And while I'm here: In the "ABOUT US" section of your website "free software" probably refers to libre software and not free of cost I guess? The German translation "kostenlose Software" implies otherwise. Minor nitpick: BROWSE FREI just sounds wrong to me, other than the glaringly obvious strange choice of word order, maybe "freely" would be better translated to "uneingeschränkt" or "ungehindert" in this context.

Possible to make an account on TRANSIFEX and make suggestions to already existing translations?

Thanks for the suggestions. Could you open a bug on Trac (https://trac.torproject.org/projects/tor) for each so we don't forget about them?

Addressing just this part:
> beginning with Tor Browser 8.0 "New Identity" no longer resets NoScript's temporary permissions.

That's bug 27732.

I'm aware of this ticket, in fact I opened it, so the example was badly chosen, at least as far as I'm concerned.

My point was that it might be helpful to implement a brief description of the most relevant long-term issues on https://tb-manual.torproject.org/known-issues/ and maybe link to it on the tor browser release announcement to help users to keep track of those, which - with trac.torproject.org as the only source, is rather cumbersome right now, to put it mildly .

The ticket about Tor Browser writing to gvfs-metadata for instance is 4 years old, still, a lot of users won't know about it. About #27732 was asked more than once on previous Tor Browser release announcements and without excessive research I could name you at least 5 more which gets asked about repeatedly here.

> To give you another example: I also ran blindly into the fact that beginning with Tor Browser 8.0 "New Identity" no longer resets NoScript's temporary permissions.

Noticed same thing.

TP, please fix it.

i double this. there are downloads, file-paths (local), last visited (web), last used (local) etc. inside.

Is their a bug ?
Tor Browser 8.5.4 updated July 9 2019
Every time i visit ' YouTube ' In the address bar, i have grey lock with an orange triangle. Mixed content is not blocked not secure. I have to reload each page to have HTTPS Green Secure Connection. Before this latest update, their was always a green lock for a fully secure page. I never had to keep reloading the same page.

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.

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