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
Anonymous

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.

Anonymous

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.

Anonymous

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

Anonymous

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

Anonymous

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.

Anonymous

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.

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.

Anonymous

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

Anonymous

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.

Anonymous

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.

Anonymous

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

Anonymous

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.

Anonymous

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.

Anonymous

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.

Anonymous

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.