New Release: Tor Browser 8.5.4

by boklm | July 9, 2019

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

Comments

Please note that the comment area below has been archived.

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).

July 12, 2019

In reply to gk

Permalink

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 ?

July 15, 2019

In reply to gk

Permalink

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

July 13, 2019

In reply to gk

Permalink

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.

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.

July 10, 2019

Permalink

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..

July 10, 2019

Permalink

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.

July 10, 2019

Permalink

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

July 10, 2019

Permalink

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.

July 13, 2019

In reply to gk

Permalink

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

¯\_(ツ)_/¯

July 18, 2019

In reply to gk

Permalink

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.

July 10, 2019

Permalink

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.

July 15, 2019

In reply to gk

Permalink

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?

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.

July 10, 2019

Permalink

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.

July 10, 2019

Permalink

Tor Help Please

I seem to be having a problem with the new update. I am timed out most of my attempts to navigate to a website. I have tried several times with each url alternating them.

I reinstalled an older version of Tor and I am able to open the web pages without difficultly.

I am using Windows 10 64bit OS. What am I doing wrong?

Thank you in advance.

July 11, 2019

Permalink

Update related to https://blog.torproject.org/comment/282424#comment-282424

Also Tor Browser 8.5.4

Unable to retrieve settinngs.

and immediately replaced with

Tor unexpectly exited.

------------------

Jul 11 08:42:06.000 [notice] New control connection opened from 127.0.0.1.
Jul 11 08:42:07.000 [notice] Owning controller connection has closed -- exiting now.
Jul 11 08:42:07.000 [notice] Catching signal TERM, exiting cleanly.

Problem with tor launcer first message is that it is not possible
to read all text because closing of controller connection causes
message that Tor unexpectly exited.

Ubuntu 16.04.6 LTS

with small memory

MemTotal: 1013216 kB
MemFree: 95716 kB
MemAvailable: 378772 kB
Buffers: 189616 kB
Cached: 243924 kB
SwapCached: 6868 kB
Active: 406268 kB
Inactive: 384508 kB

I suspect that this error is timing related.

July 11, 2019

Permalink

Since downloading this Tor update I am unable to connect to Topic Links 2.0...also none of my bookmarks work ????

What does "none of my bookmarks work" mean? On which operating system are you? Do you have any antivirus/firewall software installed that could be responsible for this problem?

July 11, 2019

Permalink

Hi guys,

you have removed some bridges and the current bridges available obsf4 and meek-azure have slowed the browser it a lot, until I have got this update the speed was totally fine even for Tor but now I had to switch to VPN, I hope these circumstances are just temporarily and that we will get improved bridges with good speed

July 11, 2019

Permalink

For Your interest: The Tor project Developers PGP key is poisoned. I was unable to verify the downloaded
tor browser because the key contains more then 100000 signatures which makes pgp inoperable.
Please do something, e.g. upload the key to hkps://keys.openpgp.org or make it available via some other means
then the keyservers. For details see for example https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

I tried to look up the key with short name 0x4E2C6E8793298290 at pgp.mit.edu and got a timeout which might be consistent with the claim that 10^4 signatures have been maliciously added to this key in order to make it unusable. If that is true, presumably Tor Project can get the problem fixed?

The copy here works for me: https://raw.githubusercontent.com/Whonix/tb-updater/master/usr/share/to…

hamburger menu -> Save Page As (Ctrl+S)
or copy/paste into a new blank text file.
$ gpg --import [saved_file]

Compare the fingerprint in your gpg to these --
https://2019.www.torproject.org/docs/signing-keys
https://support.torproject.org/tbb/how-to-verify-signature/
https://2019.www.torproject.org/docs/verifying-signatures.html.en

Text for SEO:
0x4E2C6E8793298290
Key fingerprint = EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290
Tor Browser Developers (signing key)

No, the SKS keyserver system cannot be fixed. So we need Best Practice advice from Tor Project on a safe way to obain signing keys as needed to verify the latest Tor Browser tarball, the latest Tails ISO image, etc.

GPG people describe this attack as "devastating". Daniel Kahn Gillmor says he thought about leaving the software world.

From R.J. Hansen, the maintainer of the GPG FAQ, whose personal key was poisoned in last week of June:

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.

Tor, Tails, Debian Project should all issue immediate warnings to users to prevent users who have not heard about the issue (e.g newbies, the very people Tor Project needs to attract to survive) from naively trying to download the signing keys from an SKS keyserver and immediately breaking their GPG keyring in ways which will be hard to fix, and are likely to cause newbies to stop using Tor and to be very annoyed with Tor Project (not understanding that this problem was not caused by TP and is well beyond TP's ability to fix).

It seems that Debian Project has NOT yet issued a security patch for GPG incorporating the latest code from Werner Koch which should at least prevent a GPG keyring from being rendered unusable from an autoupdate from an SKS keyserver. Making matters worse, the rollover to the new Debian stable (Buster, a now ironic nickname) occured in the same time frame as the keyspamming attacks. (AFAIK the debian keyring deb available at the Debian repos is not poisoned, but hope others will help me check.)

It seems that some experimental keyservers which only serve the self-signed parts of signatures added to a key are available (but I fear may crash under sudden high demand); Hansen mentions one in his post.

Before the next Tor Browser version and the next Tails edition are issued, users must be informed of how they can use GPG to verify the integrity of the code (sort of) without poisoning their GPG keyrings. It is not enough to say "never again import a key you obtained from an SKS server because we will need to obtain new signing subkeys etc. somehow somewhere.

So far we know that the personal keys of RJH and DKG were poisoned, as was the Tor Browser developers signing key. We must anticipate that all security-critical and widely used GPG signing keys will soon be poisoned in the SKS keyservers. It follows that users will need some other way to obtain the signing keys to verify new versions of things we need such as the latest Tor Browser.

Who is responsible? Too early to speculate very far, but the attack appears timed to cause maximal damage because of Debian stable rollover. We know that it coincides with the Russian government adopting a version of Debian as the official OS for government use. That is vaguely suggestive, but only vaguely so.

> No, the SKS keyserver system cannot be fixed.

Incorrect. It can, but not soon because the network propagates changes of keys to all other vulnerable nodes, and there isn't yet a system to revert or "clean" keys in the network that have been attacked. There are many issues to resolve which will take time. Now that it's in the wild, it will be too long of a time to be without the system. The best fallback solution, as repeated in their posts, is to host read-only backups of the keys on multiple servers and incorporate the openpgp.org keyserver. The first thing SKS volunteer servers could do is temporarily restrict the abilities to upload and synchronize.

> trying to download the signing keys from an SKS keyserver and immediately breaking their GPG keyring
> without poisoning their GPG keyrings.

So far, every report I've read and every test I've performed and repeated has simply resulted in timeouts or rejection as corrupt files. "immediately breaking" is speculation at best and misinformation at worst. Stop jumping to conclusions.

> AFAIK the debian keyring deb available at the Debian repos is not poisoned

Correct, keyrings distributed in repository packages are static copies and thus immune unless the person who packages it exports a key+signatures after it was attacked.

> some experimental keyservers

Some? The FAQ on keys.openpgp.org says they aren't federated and "will probably never have an "open" federation model like SKS, where everyone can run an instance and become part of a "pool"." In other words, they're probably the only one. Regrettably, I'm unable to import their copies of Tor Project keys because gpg returns an error about missing IDs, but other good copies were linked in other comments here.

> users will need some other way to obtain the signing keys to verify new versions of things we need

Nobody needs a new key to verify a new thing. Stop spreading disinformation. The only time a new key is needed is if the release team decides to create a new (sub)key and sign using that one rather than the one they use to sign things now. Any backup copy of the (sub)key that has the correct fingerprint no matter how old will verify new things until then. Please study how PGP and the web of trust are used.

I strongly agree that users should be informed and instructions should be revised.

Is this kind of presumed attack (adding a huge number of signatures in hope of making the key unusable) known to the tech world? If so, does anyone know when the malicious signatures were added? Any idea who the possible actors might be? It seems rather unsubtle but we know that in recent months of a number of presumed state-sponsored cyberwar groups have been acting very aggressively.

July 12, 2019

Permalink

Ever since the update, Tor is somehow defaulting to "Remember browsing and download history". (IE: I have to go into preferences every time I restart tor to turn it off.) This seems counter-intuitive to how tor is supposed to function. Is there some setting in config that got bricked during the update that I can fix by hand? It's really annoying to have to change that setting every time. I'm on OSX 10.14.5, tor 8.5.4.

Thanks in advanced.

August 09, 2019

In reply to gk

Permalink

Sorry for the delay in reply, I was travelling.

Due to some sites that use specific cookies, I have "Use Custom Settings" selected (so that those cookies can be remembered for the session I'm using TOR). Then I uncheck "always use private browsing mode". And DO check "clear history when TOR exits"

Ever since this upgrade, after I close TOR and later reopen it, the settings have "Remember Browsing and History" checked. Which it shouldn't do, since I had it unchecked before. How do I prevent this change from somehow happening automatically?

I have not had this problem with earlier releases.

July 14, 2019

Permalink

Keyserver Problem: gpg --keyserver pool.sks-keyservers.net --recv-keys 0x4E2C6E8793298290
does not work. Terminal continues to try but not response. What is the problem?

This is very serious. Tor users must immediately cease using SKS keyservers and make sure that their GPG will not try to autoupdate from an SKS keyserver. The cited key has been poisoned and will break your GPG keyring in hard to fix ways, which means you will not be able to verify any sigs with GPG or to send encrypted email.

There are some workarounds which might decrease the chance that you will poison your GPG keyring but I have no idea how any of us are supposed to verify anything using GPG signatures going forward. It is not encouraging that Tor Project, Tails Project, and Debian Project are all ignoring the issue entirely. Incredible but true (at least to gauge from public non-statements).

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

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

July 16, 2019

Permalink

Hi tor, just letting you know about the trouble having with youtube signing in..the page turns white and says tor not responding then I get this notice saying this.... NoScript detected a potential Cross-Site Scripting attack

from https://accounts.google.com to https://accounts.youtube.com.

Suspicious data:

then again when entering my password signing into google and it will not sign me in at all...
NoScript detected a potential Cross-Site Scripting attack

from https://accounts.google.com to https://accounts.youtube.com.

Suspicious data:

Error: Exceeded 20000ms timeout,(URL) https://accounts.youtube.com/accounts/SetSID?ssdc=1&sidt=ALWU2cs0m8sHAS…

Error: Exceeded 20000ms timeout,(URL) https://accounts.youtube.com/accounts/CheckConnection?pmpo=https://acco…

Cross-site scripting is most likely the site's problem, not Tor Browser's. Send a message to Google and Youtube help, and search NoScript's forums to see if anyone else had the problem. Tell Google and Youtube you are using NoScript and what version.

July 17, 2019

Permalink

The keyspamming attack on the SKS keyserver network is devastating and apparently unfixable. (Don't believe it because I said, believe it because R. J. Hansen said it.)

Stop using SKS keyservers immediately and make sure your GPG is configured to not refresh keys from any SKS keyserver!

This is not Tor Project's fault, any Linux distro's fault, the OpenPGP developer's fault, Werner's fault, Phil's fault or anyone's fault really, but we Tor and Linux users all have a terrible problem because it is not clear how we can obtain new signing subkeys safely in order to verify downloads (which is how most Linux users and Tor users mostly use GPG, probably), which is obviously critical for our cybersecurity.

It appears that there are some specialized keyservers which do not serve the additional signatures which can be used by any attacker (including "script kiddies") to poison any key at any time, but this is not likely to prove a practical solution, especially not once everyone and his brother starts trying to use them all at once to verify the new Debian stable DVD #1 ISO image for example.

Would Tor Project please post an explanation of the problem together with updated Best Practice advice for using GPG to verify Tor Browser tarballs from the detached signature? In particular, next time you create a new subkey to sign a new edition, how are we users supposed to obtain the new subkey?

Stop duplicate, triplicate, quadruplicate posting. Tor Project and we commenters got it the first time. Speaking of spamming.

Verifying hasn't changed. Obtaining most of their keys has changed. All they have to do is upload a clean copy somewhere it won't be signed by someone unauthorized.

July 19, 2019

Permalink

Can noScript addon details be read in Tor? If you whitelist a site with the noScript settings so that you do not have to repeatedly input them, can these be read in Tor and thus identify the user or use these settings to follow the user?

As far as we know, the settings can't be read unless there is a major bug that hasn't been reported, but they can identify you. There is a traffic pattern of which URLs your browser accesses when it loads a webpage and an availability pattern of which features in the page's code become enabled when the set of accessed things are loaded. If the URLs your browser accesses are different from the URLs accessed under normal configuration, that difference can single you out to people logging your traffic or to scripts on the webpage. So your NoScript settings under the Per-Site Permissions tab can indirectly be determined or reverse-engineered.

If you do find a major bug, please report it. If you find a security issue, you can send an encrypted email.

Cheers I don't understand it all but going by your reply it means that it is best not to whitelist any sites I hope I have understood this I also understand that it is still ok to use NoScript thanks again

July 19, 2019

Permalink

Is there anything that can fix what's happening on twitter with their forced new interface where we can't upload any pictures via twitter web client? When uploaded it's just a blank white square. This happens too only on Tor when I want to upload a new avatar or new header image.

Tor Browser 8.5.4, Windows 10, desktop.

I finally found why uploading pictures to twitter while using Tor showed up either as a blank white square or nothing at all. When I try to upload, this appears showing 'All Supported Types." They few it shows are the few pictures I have saved as png. I have thousands of pictures saved as jpg. Why would twitter only now allow png this only happens when I'm using Tor? Before the forced interface this problem only happened when uploading avatars and header images while using Tor. But now the forced interface won't let me upload jpg images when I'm tweeting randomly. This is also happening on tweetdeck too when using Tor. Is there any way to fix this? Thank you.

https://imgur.com/a/IFfNK7O

Tor Browser 8.5.4, Windows 10, desktop.

July 19, 2019

Permalink

Three questions:

1. Why isn't Privacy Badger incorporated into Tor Browser instead of (or in addition to) UBlock-Origin?

https://www.eff.org/deeplinks/2019/07/sharpening-our-claws-teaching-pri…

2. How does choosing "New Identity" now differ from closing and restarting Tor Browser?

To judge from my experience using recent editions of TB, it seems that "New Identity" is no longer equivalent to closing and restarting.

3. Will TP make any response to the key poisoning?

1. UBlock-Origin isn't incorporated into Tor Browser. You're probably using the version in Tails. Those two add-ons make different users' traffic more distinguishable than using the Security Level shield to change NoScript, and dynamically updating blocklists, if enabled, are very hard to review for security and breakage.

July 20, 2019

Permalink

I am testing a new YT vid downloader ‘Keepvid’.

Security level – Safest

About:config – Javascript enabled – False

Under NoScript options all checkboxes are unchecked.

I put the vid URL into the searchbox, it appears and I start to download it.

I then press New Idenity, TOR refreshes and I am back to original start page – About:TOR

I then call up the Keepvid page expecting to see a blank searchbox but NO – the previously searched for URL is still there. Why?
I thought that by choosing New Identity all cookies etc would be deleted and I would start with a new identity.

Even after restarting TOR, the previous URL is still there!

Help please.
Thank you. Obrigado.

July 21, 2019

Permalink

In about:preferences#privacy History section, choose Use custom settings for history and check out Remember my browsing and download history. if you exit and open TBB, Remember my browsing and download history is checked.

Anonymous

Thanks for your response.

However, I don’t understand what you mean by “if you exit and open TBB, Remember my browsing and download history is checked.” Please explain.

Also, at the location you state, “Remember my browsing and download history” has always been unchecked, so I don't need to uncheck it now..

I have just (the first time in 2 weeks) opened my Keepvid bookmark and the search box is not empty – It still has the same YT url in it.

Do you, or anyone else, have any other ideas. Thanks

July 21, 2019

Permalink

Under ‘Options’ on the browser, under Privacy & Security there is the option to “Prevent accessibility services from accessing your browser”.
This option is not ticked. When ‘Learn more’ is clicked Mozilla says:
“Firefox Accessibility Service is a technology built into Firefox that provides 3rd party applications running on the same device the ability to inspect, monitor, visualize, and alter web page content hosted within Firefox.”

For greater privacy, wouldn’t it be best to have the box “Prevent accessibility services from accessing your browser” ticked by default?

Please advise.
Thanks

July 22, 2019

Permalink

Is there a way to turn on javascript for each instance that I visit a new website? On my other Mac, an older OS version is running, which limits me to an old version of Tor browser, which has a control at the top left of the browser window to turn javascript on. I don't see this type of control on the current version of Tor browser.

Read the descriptions of each security level in the shield icon --> Advanced Security Settings. "Safer" and "Standard" enable javascript. On "Safest" or to fine-tune javascript access, learn how to configure the NoScript add-on. Change the Security Level again when you start a New Identity to reset NoScript.

July 23, 2019

Permalink

Umm, I don't think you should be fetching keys from keyservers at all unless you intend to verify them through the web of trust. You should get the key from the project's website, over HTTPS, and probably double check the TLS cert, or get them over keybase. The problem is that an 8 digit key ID is not a unique id. Anyone can make a spoofed key with the same key ID, same name and email, and upload it to the keyservers. So maybe all this key poisoning is a good thing, actually?

Also, for now, maybe just pay attention and try not to download any multi-gigabyte keys?

Yes, verifying them through the web of trust is good, but you have to start somehow, which usually means comparing the full 40-digit key fingerprints "out of band" through multiple avenues if you're unable to meet in person to do it and optionally confirm government-issued documents if the key's userIDs include a real name.

> You should get the key from the project's website, over HTTPS... [or keybase].

If the site is hacked and the hacker changed the key, HTTPS won't mean a thing.

> or get them over keybase

In other words, a more cumbersome and commercial server of keys that leverages social pressures on newbies through their interface to link all of their online identities and not explain the privacy consequences. Get keys and verify identities? Sure. Sign up, participate, and legitimize their pressure on newbies to cross-link identities? Only very carefully if at all.

The keys can be anywhere over any protocol as long as the fingerprints are always the same, and at least one of the userIDs is what you're expecting. (And that the crypto algorithms that made the key are in good standing and the private key hasn't been compromised.) Most keyservers, and for that matter, software repositories, don't have encrypted interfaces and don't need them because the cryptographic structure of the key file ensures its integrity.

> The problem is that an 8 digit key ID is not a unique id.

What problem? Tor Project's documentation and support reference them by their long 16-digit keyID and full 40-digit fingerprints. It isn't Tor Project. It's default installations of most PGP programs that display short 8-digit keyIDs. Configure yours to display 16 and/or the fingerprint, and find if it's possible to search your program or keyserver by 16 or by the fingerprint.

> Anyone can make a spoofed key with the same key ID, same name and email, and upload it to the keyservers.

Yes, which is why people and programs should confirm full 40-digit key fingerprints and not simply their 8 or 16-digit keyIDs.

> So maybe all this key poisoning is a good thing, actually?

No, it's catastrophic and has nothing to do with the problems you said.

> try not to download any multi-gigabyte keys?

I haven't ever seen an interface that shows the filesize of keys to be able to know if a key is tens of megabytes or not. PGP doesn't do that. Normally, they're stored on keyrings.

* "tens of megabytes" is closer to the size of keys attacked by certificate flooding than "multi-gigabyte." For now anyway.

July 27, 2019

Permalink

Just noticed today the some bookmarks are gone. The two I am currently aware of have been on the system for at least three years. I will have to do more research. Has anyone noticed bookmarks disappearing?

July 29, 2019

Permalink

hello guys i have been trying downloading 32bit for windows but it always keep downloading me the 64 bit. Please any one can put me a link to download 32 bit, thanks in advance.

August 02, 2019

Permalink

I just got this while trying to sign into youtube NoScript detected a potential Cross-Site Scripting attack

from https://accounts.google.com to https://accounts.youtube.com. and had to go to noscript to allow google and youtube temp permission to sign into their sites and still tor freezes up and then unfreezes and it takes a while to sign in and then up pops something that says you computer has been detected as having too much traffic and try again later to sign in...google is not wanting any tor users in...

Suspicious data:

August 02, 2019

Permalink

I am getting this message on both of your new tor browser NoScript detected a potential Cross-Site Scripting attack

from https://accounts.google.com to https://accounts.youtube.com.

Suspicious data: and this is at the bottom of message
Block this request
Always block document requests from https://accounts.google.com to https://accounts.youtube.com
Allow this request
Always allow document requests from https://accounts.google.com to https://accounts.youtube.com

I have allowed google and youtube temp permission and still I get these messages..am using a USB stick free of viruses each time and this has never happened before this new browser release so something is wrong here or with google??

August 03, 2019

Permalink

Tor won't open. It says Tor is already running and I should restart, I try everything but same always. I close Tor, even uninstall and download a new one. Same thing. I even think Microsoft has hijacked your download page because a new window now comes up saying try a Microsoft App instead! The only way so far to use Tor has been to download a very old version, then let it update and then it sometimes works, but the next day when I want to use it again, it is the same problem? There seems to be no help to solve this problem and I see others have it as well. Frustrating!!!!

August 11, 2019

Permalink

I am a relatively new user of TOR and have just downloaded 8.4.5. I also downloaded and installed GPG.

In order to check the signatures I followed the instructions at
https://support.torproject.org/tbb/how-to-verify-signature/

However when I followed the first instruction and went to cmd and input
gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@torproject.org

all I got was
“C:\Users\my name>gpg --auto-key-locate nodefault,wkd --locate-keys torbrowser@tor
project.org
gpg: error retrieving 'torbrowser@torproject.org' via WKD: No inquire callback i
n IPC
gpg: error reading key: No inquire callback in IPC”

Can we not have instructions as full and clear as found at:
https://2019.www.torproject.org/docs/verifying-signatures.html.en
which does not appear to have been updated since TOR 8.0.8

Many users of TOR are not computer experts or geeks and need step by step instructions to use it.

Thank you

August 14, 2019

Permalink

I've checked my connection through TOR with ip-check.info and I've got Delaware 169.197.97.34 ExitNode but torrc was restricted not taking US and forced CH and CH was declared in (i) as the ExitNode. Then I blocked 169.197.97.34 as ExitNode and after that ip-check.info declared the same IP as shown inside (i). What's going on? How can the ExitNode be changed to Delaware without taking {us} restriction into account and declaring CH as ExitNode?

August 14, 2019

Permalink

8.5.4 reproducibly crashes on MacOS Catalina beta 5. I'll file a bug report too but thought I'd post it here as well.

August 14, 2019

Permalink

I registered and tried to login so I could file a bug report (see my previous post on 8.5.4 crashing on MacOS Catalina beta 5) but the captcha kept failing to let me in after several attempts so I'm giving up on that.

August 23, 2019

Permalink

I have been blocked from downloading your browser by the DISGUSTING internet police I have circumvented their nonsense AGAIN. I truly would like to run a relay but due to "persons unknown" blocking my download facility I'm trying to find out if it's still at all possible?

From the support FAQ: How do I download Tor Browser if the torproject.org is blocked? GetTor is one method.

Tor Browser is not meant for running a relay. Use the tor binary to run a relay. Read about relays on Support FAQ: Operators, Community site: Relay Operations, and the old General FAQ. From the download page, click "Download Tor Source Code" to find the expert bundle, or if you use Linux, add Tor Project's repository as instructed in the FAQ guides.

August 23, 2019

Permalink

ja, schön - aber was nutzt mir das wenn das hier alles in Kinesisch geschrieben wird ... - ich bin leider ein Deutscher ...

August 28, 2019

Permalink

I have downloaded the installer, but when I click on Sig to download the signature, it just opens in a new page and displays the physical signature, instead of downloading the .asc file. Is there something I'm missing here?