Tor Browser 6.0.5 is released

Tor Browser 6.0.5 is now available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox including the recently disclosed extension update vulnerability. All users should upgrade as soon as possible.

That vulnerability allows an attacker who is able to obtain a valid certificate for addons.mozilla.org to impersonate Mozilla's servers and to deliver a malicious extension update, e.g. for NoScript. This could lead to arbitrary code execution. Moreover, other built-in certificate pinnings are affected as well. Obtaining such a certificate is not an easy task, but it's within reach of powerful adversaries (e.g. nation states).

Thanks to everyone who helped investigating this bug and getting a bugfix release out as fast as possible.

We are currently building the alpha and hardened bundles (6.5a3 and 6.5a3-hardened) that will contain the fix for alpha/hardened channel users. We expect them to get released at the beginning of next week. Until then users are strongly encouraged to use Tor Browser 6.0.5.

Apart from fixing Firefox vulnerabilities this release comes with a new Tor stable version (0.2.8.7), an updated HTTPS-Everywhere (5.2.4), and fixes minor bugs.

Here is the full changelog since Tor Browser 6.0.4:

  • All Platforms
    • Update Firefox to 45.4.0esr
    • Update Tor to 0.2.8.7
    • Update Torbutton to 1.9.5.7
      • Bug 19995: Clear site security settings during New Identity
      • Bug 19906: "Maximizing Tor Browser" Notification can exist multiple times
    • Update HTTPS-Everywhere to 5.2.4
    • Bug 20092: Rotate ports for default obfs4 bridges
    • Bug 20040: Add update support for unpacked HTTPS Everywhere
  • Windows
    • Bug 19725: Remove old updater files left on disk after upgrade to 6.x
  • Linux
    • Bug 19725: Remove old updater files left on disk after upgrade to 6.x
  • Android
    • Bug 19706: Store browser data in the app home directory
  • Build system
    • All platforms
      • Upgrade Go to 1.4.3
Anon

September 19, 2016

Permalink

Choosing New Identity (nor closing Torbrowser) is not cache-cleaning everything

The old Torbrowser versions 4 and earlier did something Torbrowser nowadays does not do anymore.
Torbrowser is keeping information in its memory cache (placing it in computer memory cache) after choosing new identity.
If you for example copy an url from the url bar or other text information from Torbrowser, Torbrowser is keeping that information in its cache after choosing new identity.

Even when you are closing down Torbrowser and opening another standard browser like Firefox you can still past that information.
So the Torbrowser cache is not cleaned anymore like the older (4 and 3) versions did.
Now the only way to get rid of the Torbrowser copy-cache is by overriding information by copying some other non important information.
That is not a really practical procedure.

Please make the cache cleaning after renewal or closing down Torbrowser work again.

Err... that is the desktop clipboard, which TBB (Firefox) does not (and should not) control.

What is in the desktop clipboard needs to stay there until the user clears or overwrites it, because the user might want to paste the contents multiple times. There is no way your system can ever guess when you've finished with the clipboard's current contents. You must clear it yourself.

Anyway, I like the current clipboard behaviour: if I want to visit a link I just read on one website, I can copy it, change identity, then paste it straight into a fresh browser instance. Your way would make that a pain to do.

It's my experince too, just clicking "new identity" doesn't minimize the browser memory usage at all.
Cleaning out all cache and surfing history, and flushing the memory (about:memory) doesn't help either.
Restarting the browser (Ctrl+Alt+R) is the only way I know which get the browser down to its initial memory footprint.

Anon

September 16, 2016

Permalink

What's been happening to the obfs4 bridges? Can't seem to get them lately on the bridge website.

Anon

September 19, 2016

Permalink

Https everywhere toolbar menu does refer to nothing after the arrow.

Why isn't the Https everywhere add-on visible in the toolbar menu so users can directly access its preferences, settings and can be aware that the add-on status is actually active?

Not sure what you mean with "refer to nothing after the arrow". Do you have HTTPS-Everywhere visible on your about:addons page? The icon is e.g. not visible in the toolbar if the width of your screen is not sufficient.

Torbrowser MacOS (X)
Main Torbrowser menu at the top
-> Tools -> HTTPS Everywhere -> (arrow) ... (empty)

I cannot remember changing window screen, 'we do not do that as been told, right?'
But I cannot check it now because I am not using the 6 version anymore because I am very highly dissatisfied with the mayor changes you made for MacOS after the 5 version.

But because I do like the main concept for making this browser and other people probably use this browserversion 6 I just wanted to point at this.

(Just think of MacOS if you see other comments overhere about bugs you may not understand directly)

Many thanks and praise to all the devs for the great work they have one and are doing on this wonderful thing called Tor :)

Bug (also in Firefox)

Printing preferences are not remembered even within the same browser session.
Just give a print order and change a value in the standard setting in "Page headers", "Page footers" or "Appearance values".
The next print order will not remember that setting which is highly annoying if you have to print or save a lot of information.

It always remembered changed printing page values but now it is broken here too.

By the way, the standard setting of date/timeprinting information within the document is also maybe dangerous from a privacy point of view.
You can remove time metadata but you cannot remove this from a pdf document itself when saved as pdf (you would need a pdf editor for that).

Please look at this standard values omissions.

Thanks for keeping us safe!

Annoying urlbar search suggestion cant be disabled

Even with this setting
browser.urlbar.suggest.searches;false
Is that a bug?

Very annoying because search suggest appearing above bookmarked suggestions when typing something (there is no need for that search suggestion field overthere).
There is a separate search field for searches in the right above corner so there is no reason to make the urlbar as a search(suggestion)field too.

If you go to about:preferences#search, you'll see under your chosen default search engine two tick boxes, the first marked "Provide search suggestions", and the second (conditional to that) marked "Show search suggestions in location bar results". Check that second tick off.

Note that if you went to about:preferences#privacy, and set History to Tor Browser will: "Never remember history", the second tick box will have a warning below: "Search suggestions will not be shown in location bar results because you have configured Tor Browser to never remember history."

ок

Thank you all !!! Special thanks to @movrcx and @flyryan for pointing out the mozilla bug. Thanks to flyryan for working so long with the dev team while they fixed it.

Despite differences of opinion all worked together towards the common good. I am proud of the good work !

Ok, so I arrived to this page looking for this shasum in duckduckgo:

d79e18d691a407c9cc06ec508701bff2283d73b65d4321e254763b17d0a13a09

Which is not the same as the one I found in your link for verifying shasums:

https://dist.torproject.org/torbrowser/6.0.5/sha256sums-unsigned-build…

In summary :

d79e18d691a407c9cc06ec508701bff2283d73b65d4321e254763b17d0a13a09 ≠ 83af8ec2f8f56770a0a18bfe099cd4bf32e204bdcec8583575fb13a4f69b208a

I am doing all the process of verification well. What's the problem? Where are the comments referring the same problem? Is Tor able to continue guarantying our fundamental rights? If not, please do just tell us for us to take appropriate measures.

Thanks.

"Update Firefox to 45.4.0esr"

On mozilla.org, 45.4.0esr doesn't exist! ?

Could you explain what you have been doing? I am not sure what issue you are describing exactly.

Mozilla plans to release 45.4.0esr on September 20th. This was also the plan for Tor Browser 6.0.5 but we released it earlier due to the vulnerability.

That person has a question about sha checking as well.

I asked that question as a first poster in the former (comments-version #1) of the article-blog "Tor Browser 6.0.5 is released" .

This was the initial question:

"Downloaded TorBrowser-6.0.5-osx64_en-US.dmg sha256
d79e18d691a407c9cc06ec508701bff2283d73b65d4321e254763b17d0a13a09
Sha 256 on dist.torproject.org_torbrowser_6.0.5_sha256sums-unsigned-build
83af8ec2f8f56770a0a18bfe099cd4bf32e204bdcec8583575fb13a4f69b208a
No match, please put the easy to check and correct hashes back on that page as long as you dont explain in your long ago promised how to.
Making things not work and more difficult will only result in not checking at all anymore."

And this was the aswer (thanks to web.archive.org):

The hash does not match because the sha256sums-unsigned-build.txt file has the hashes from the builds without the code signing that is included in the final dmg files. We did not yet write instructions to remove the code signing to check that it matches the hashes from sha256sums-unsigned-build.txt, but it is still planned to do it:
https://trac.torproject.org/projects/tor/ticket/18925

However, sha256sums-unsigned-build.txt is maybe not what you want to use, depending on what you want to check. If you want to reproduce a build and check that it matches what is distributed, you will get a sha256sums-unsigned-build.txt file that you can compare with ours, and then the code signing needs to be removed from the dmg files we distribute (or added to the build you made) to check that it matches. We are working on ticket #18925 to make that easier. However if you just want to check that the dmg files you downloaded is really what we released, then you should not use the sha256sums-unsigned-build.txt file, but use the gpg signature (each dmg file is signed individually)."

web.archive.org
18 september 2016 snapshot with all the comments just right before the blog went down :
https://web.archive.org/web/20160918123532/https://blog.torproject.org/…

Thankyou, I found the SHA256 checksum of the downloaded .dmg didn't match and this answered my question why.

He downloaded the TBB, googled the hash, and the sha256 for that file matched one somewhere on this page (although not that I can find), but the hash did not match the one released along with the TBB files (the URL he mentioned above). Until there is an explanation, I would be very alarmed about a hash mismatch.

Most importantly, to the OP,
Please spend some time learning how to verify the PGP signatures distributed with all Tor Browser releases. It is a much more secure procedure than comparing hashes, even without participating in the web of trust, and prevents you from ending up in a situation like this (where it is unclear what the correct hash is). PGP might look intimidating at first, but it's not as hard as you might think. The time to start is before compromise, not after.

same here ;)
sha256sum
d79e18d691a407c9cc06ec508701bff2283d73b65d4321e254763b17d0a13a09

same here, sha256sum:
d79e18d691a407c9cc06ec508701bff2283d73b65d4321e254763b17d0a13a09

good

I have the same TOR update problem with my AVG antivirus for an IDP.ARES.Generic detect! I've seen at least 4 more post in this regard. Does anybody know what's going on? It's is only related to AVG or does any other Antivrus Program has the same issue? Please, some information would be really appreaciated. Thanks.

Is there an about:config option which can mitigate this temporarily on systems where an upgrade is not feasible at the moment?

What about "extensions.update.enabled"?

By the way, I'm using TAILS OS. Tails developers make further tweaks to TBB. The above option defaults to "false" in TAILS, so the claim by @movrcx in:

https://hackernoon.com/tor-browser-exposed-anti-privacy-
implantation-at-mass-scale-bd68e9eb1e95

that "The list of vulnerable deployments to this attack includes ... Tails ..." is false.

As far as I can see this is only AVG freaking out.

Excellent

Recent months is tough time, Tbb is very difficult to connect to Chinese websites, which their servers locate in Chinese mainland. Have Chinese Party limited Tor users very hard or every other country who is trying to connect to Chinese?

Going by my own anecdotal experience, there was recently a change in the Great Firewall, such that it now blocks Tor exit nodes in addition to entry nodes (before, it only blocked entry nodes). The blocks go in both directions, so an exit node outside of China cannot reach a server inside of China.

For example, http://cnnic.cn/ times out for me when using Tor, but works when not using Tor. I think the change happened some time in August, 2016. We could probably find out exactly when by looking at OONI reports.

On my computer AVG antivitrus detects new version of tor.exe as IDP.ARES.Generic virus.

hey guys is something wrong hier...detected as virus!!

good job !! go on !!

Thanks for keeping us safe!

Спасибо!

I always visit this buy and sell website on normal firefox browser. but
when I visit the site using tor browser it says:

Access Denied
You don't have permission to access "http://www.olx.ph/" on this server.
Reference #18.8f643e17.1474466683.4a84b0f

what should I do?

AVG detect IDP.ARES.Generic

your problem is using AVG. it's a terrible program that steals private information from your machine. why bother using tor at all? lol.

I'm sorry to have to use this space to address Tails' users. (There used to be a Tails' public forum but it was discontinued a few years back.)

To: Tails users

Before you decide to use Tails 2.6, you need to know that it contains an unpatched security vulnerability that has the potential to unmask your anonymity.

According to Tails' official website, version 2.6 uses Linux kernel 4.6. As of the time of this post the said kernel is still unpatched by Debian (cf: https://security-tracker.debian.org/tracker/CVE-2016-5696).

Conclusion: Use Tails 2.6 at your own risk.

i can not translate languages when using tor why?

See:

   https://blog.patternsinthevoid.net/cve-2016-5696-and-its-effects-on-tor…

The "potential to unmask your anonymity" is seriously overegged. The attack, using TCP blind in-window DoS attack to try and bump Tor clients towards a hostile set of relays hardly helps a de-anonymisation attack because, as Isis Lovecruft explains, Tor builds new circuits whole from scratch.

I'm using Tails 2.6 right now (with Linux kernel 4.6) and I don't experience any DoS.

Hi, when you maximize your window TOR states that something like this. When maximizing your window websites can gather data and find out the size of your screen, we recommend you keep it as it is. Or something like that. Can't TOR do something about this so even if you do maximize your screen you can choose what size the website can see, something similar to fraudfox? Thanks

We are working on it but it is tricky to get right. We are currently stuck at https://trac.torproject.org/projects/tor/ticket/14429.

How come I keep getting CAPTCHA loops when trying to join certain onion sites?

TOR Project is overtaken, stay away from new versions. I was suspicious for 6.0.4 version and I was right. It's not bug, it's intentional backdoor.

What is an intentional backdoor? Could you point to it?

> TOR Project is overtaken, stay away from new versions. I was suspicious for 6.0.4 version and I was right. It's not bug, it's intentional backdoor.

The Snowden leaks include a number of published documents which explain the methods and goals of NSA and GCHQ trolling operations. These include:

o short comments,

o repetitive comments which ignore any corrections or contrary information,

o comments which attempt to reinforce notions which benefit our enemies ("everyone knows there is a backdoor in Tor"--- if ordinary citizens around the world believe that, they won't use Tor, which is what NSA and GCHG want),

o comments which attempt to exploit systemic vulnerabilities in a community (such as Tor users); for example, the difficulty which ordinary citizens experience in gaining reliable information about computer network or software vulnerabilities.

Of course, much the same could be said of commentards paid by the RU or CN governments. And to be sure, not every comment which satisfies these conditions need be posted by an enemy operative. But over time a suggestive pattern becomes sufficiently clear to make a pretty good guess.

On balance, it is likely that our enemies want to discourage users from adopting the current versions of Tails precisely because it closed a vulnerability they had been using against selected victims.