NoScript Temporarily Disabled in Tor Browser

by gk | May 4, 2019

Due to a mistake in Mozilla's signing infrastructure, NoScript and all other Firefox extensions signed by Mozilla have been disabled in Tor Browser. Because they use NoScript, higher security levels are currently broken for Tor Browser users.

Mozilla is working on a fix, and we'll start building a new Tor Browser version as soon as their fix is available.

Meanwhile, anyone who is dependent on the security provided by the higher security levels can apply the following workaround:

  1. Open the address about:config in the Tor Browser address bar
  2. At the top of the page, search for xpinstall.signatures.required
  3. Set the xpinstall.signatures.requiredentry to false by double clicking it

Note: This workaround should only be used temporarily, as it disables a security feature. Please remember to set the xpinstall.signatures.requiredentry back to true again once the Tor Browser security update is applied.

Sorry for the inconvenience.

Comments

Please note that the comment area below has been archived.

John (not verified) said:

May 04, 2019

Permalink

Thanks for the workaround! Did it, it works fine so far. What exactly is the risk by setting it to false?

OT: Google captcha drives me crazy with Tor while surfing on many sites. It says my results are wrong and I have to do it again and again and again. :-( Is there a workaround? Thanks!

anon (not verified) said:

May 04, 2019

Permalink

> installing add-ons in Tor Browser is generally not recommended
Well... having less-trusted addons like NoScript preloaded in browser bundle sorta nullifies this recommendation. While some other addon can improve privacy even in private browsing environment and junk traffic thru tor circuits (which are slow already).

Sure thing. Problem is that NoScript receives updates thru addons.mozilla.org as well - as preconfigured in browser bundle effectively leaving an open sesame for any attack NoScript's author wishes to perform again, see https://adblockplus.org/blog/attention-noscript-users
That's why I don't use NoScript at all (it is rather pointless in 2019 anyway).

It's ok as long as you remember to check (enable) it again after the patch is installed. Leaving automatic updates to add-ons turned off prevents automatic security updates to add-ons, so don't leave it disabled for longer than it needs to be.

But it has no effect on the disabled status of NoScript.

This happened WITHOUT WARNING. The sudden disabling of NoScript resembles a ransomware assault. I interpreted this as corruption and I tried to re-install, and lost ALL my bookmarks! I have been digging but have no idea how or even if I can recover them.

This is OBSCENE.

Stop moaning you lame ass moaners. You get this service for free. You act like 2 year olds some of you selfish, self centered candy ass moaners. Did it ever cross your self centered mind to say "hey Firefox/Tor, thank you for all the effort you put in to providing selfish moaning little nobody me with a free and usually pretty good and safe service.
Thank you Firefox/Tor workers for providing me a safe place on the Internet!

I agree that posters who are expressing harsh criticism of Tor devs or spreading FUD based upon misconceptions or misleading "spin" are not helping anyone, but I also feel that we all need to be sympathetic when something like this happens and some Tor users panic. After all, the most at-risk Tor users really might lose their freedom or even their life if a seriously bad entity is able to exploit some bug in the Tor ecosystem.

The good news in this story is that it seems the problem existed for only minutes to hours before Mozilla was notified, and Mozilla, Tor Project, and Tails Project all promptly issued fixes.

I would agree with anyone who says people who complain about TP should be making donations to help make things better, for example by allowing TP to become less reliant upon USG/Google.

Bookmarks are stored in the browser's profile folder inside the tor-browser folder. They're deleted if you delete the tor-browser folder. First, open your Recycle Bin. If they aren't there, you need to immediately stop writing to the partition and scan it with forensic recovery software for deleted files. If you aren't able to stop writing to the partition while your OS is running, plug the drive into another computer, and scan it from there, or scan it from a Live USB.
https://en.wikipedia.org/wiki/Data_recovery#List_of_data_recovery_softw…

For how to backup before you lost them, see the final paragraphs here:
https://ocewjwkdco.tudasnich.de/comment/280732#comment-280732
and here:
https://ocewjwkdco.tudasnich.de/comment/281023#comment-281023

Поддерживаю! У меня в связи с этим тоже были опасения по поводу внезапного отключения всех дополнений в Tor Browser! Сначала копался в файлах так как полагал, что слетела система. Потом попробовал отключить проверку сертификата мозилла и дополнения появились в браузере и работали. Затем снова произошёл сбой! И тут я подумал, что поймал дикий вирус и система в полном ауте а я в полной жопе. Так и до инфаркта недалеко!

You don't understand the principle how torbrowser works.
If you ad Add-ons you change your Browser-fingerprint and loose your anonymity, cause you are a special snowflake in the mass of tor users.
Do you really think the tor project did not check noscript? Why do you use torbrowser if you do not trust them and think they are that stupid? If you think you understand the internet better than all the programmers, software-engineers and network-specialist at tor project, why don't you build your own anonymous browser or network.
I am shocked every time to see how much people suffer from Dunning-Kruger-Effect.

> It's a lie.
> why don't you build your own
Going to disregard kindergarten-tier exclamations, sorry.

> all the programmers, software-engineers and network-specialist at tor project
But let me remind you, what you are here on this page because one our trusted dependency been sloppy enough to lose the key (and, if you insist, the other our trusted dependency overlooked the flaw). This happened because such is life where sheet happens.

The case of NoScript is different because during that little war with Wladimir Palant, NoScript's author INTENTIONALLY deployed the questionable updates (see the ABP blog link above). That's why I'm treating NoScript addon as less-trusted and adding some entropy to my fingerprint having it disabled. Moreover, I have even more entropy from the use of uBlock Origin w/country specific lists for as partial replacement of NoScript functionality. I'd happily return back to line but not with NoScript, sorry, can't make myself to trust it.

@anon, you seem to know a lot about uBlock Origin.
Are you sure it doesn't reveal your TRUE IP as some addons do? Or track you in some other way?
I see all the time that uBlock Origin sets a bunch of cookies every time it updates the Filter Lists from Easylist, Fanboy etc...

Anonymous (not verified) said:

May 06, 2019

Permalink

Speaking of add-ons. I think there should be a preinstalled ad-blocker too. NoScript blocks ads as long as you don't allow ANY scripts. Once you need to allow some scripts in order to make the website work correctly you'll get the ads as well so if you don't want ads you need to install at least an ad-blocker.

This wouldn't be an issue if an adblocker was included by default with tor browser (and configured the same for all users). Tor browser users already stand out, the important thing is that you shouldn't be able to tell one tor browser user from another.

The suggested workaround is an UNEQUIVOCALLY BAD IDEA. WTF, disable signature checks? Never, never, never!

In the small picture, this is a real risk. In the big picture, Tor Project, are you deliberately training users to defeat "certificate validation" failed errors?

Good workaround: Open about:config and set javascript.enabled to false.

This will totally disable JavaScript. Therefore, NoScript is not needed. (Thanks to other cypherpunks in #30394.)

It may mess up the Security Slider, so this *after* setting the Slider to High. This way, you will also get settings such as disabling SVG, MathML, Web fonts... Or if you need JavaScript on some sites, set the Slider to Medium first (disables ultra-dangerous script features). Then, leave an about:config tab open so you can toggle JavaScript on and off.

(John, OT, Google is evil. Google, Cloudflare, et al. use soft coercion to make you abandon untrackable means of accessing the Internet. Don't give in; just boycott affected sites as much as practical, and politely let their owners know why.)

First, about:preferences#privacy -> Permissions -> "Warn you when websites try to install add-ons" is enabled by default, and the only exceptions are to Mozilla-controlled first-party add-on websites. Mozilla vets the add-ons they list, and a user would have to visit Mozilla's website, click the button on the page to install, and then see the warning that the browser displays and click on that. Difficult to do accidentally. Finally, the post makes very clear that the workaround should only be used temporarily (in bold) and reverted after the patch is installed. Disabling signature checks is not good, but there are many other layers of protection in place including telling users about the effects of the workaround and how to behave with it, so it isn't as bad as you make it out to be.

Second, while disabling javascript will close many of the holes that were opened when NoScript was disabled, many users will need javascript enabled as you noted, but try explaining the intricacies of the relationship between the slider, NoScript, and Preferences to non-technical users and expecting them to know when to change what.

I agree on boycotting incessant captchas and pervasive Cloudflare, but many websites roll their own javascript or depend on relatively benign javascript frameworks to function. Disabling javascript disables all of them, not just Google and Cloudflare.

When the patch is released, its blog post and the next few that follow it should absolutely repeat the message to reset the preference back to True.

I think the disabled signature checks are only for installing extensions. Unless you are installing extensions in Tor Browser (which is a bad idea), then it is totally harmless. It's not like you're disabling TLS PKI signature checks that are necessary for secure HTTPS sites.

Anonymous (not verified) said:

May 05, 2019

Permalink

Avoid web-surfing until the fix is available? I am willing to try, but any idea when we can expect the fix? I know we depend upon Mozilla to fix the cause for NoScript breakage.

Anonymous (not verified) said:

May 07, 2019

Permalink

Does this mean that TB 8.0.9 and the latest Tails are not yet safe but still need to be fixed?

8.0.9 includes the fix for this issue.

Anyway, even the previous version was still relatively "safe" if you were using the "standard" security level. It mostly made a difference for the users of the "safer" and "safest" security levels.

Anonymous (not verified) said:

May 07, 2019

Permalink

Whew, OK, thanks, this thread has moved so quickly that it was a little hard to tell that 8.0.9 fixes the second issue which arose.

However, I use "safer" and "safest" almost exclusively.

Someone (not verified) said:

May 06, 2019

Permalink

Not found

>The suggested workaround is an UNEQUIVOCALLY BAD IDEA. WTF, disable signature checks? Never, never, never!

Bad idea is mandatory signature verification for add-ons. If you can't install add-ons without Mozilla's permission - it's not your browser. Mozilla add-on signature give a false sense of security.

Signed is NOT verified by Mozilla.

Mozilla removed today (August 16, 2018) 23 Firefox (signed) add-ons that snooped on users and sent data to remote servers, a Mozilla engineer has told Bleeping Computer today.

The list of blocked add-ons includes "Web Security," a security-centric Firefox add-on with over 220,000 users, which was at the center of a controversy this week after it was caught sending users' browsing histories to a server located in Germany.

"I did the investigation voluntarily last weekend after spotting Raymond Hill's (gorhill) comment on Reddit, https://www.reddit.com/r/firefox/comments/96715s/make_your_firefox_brow… ," Wu told us. "I audited the source code of the extension, using tools including my extension source viewer."

"After getting a good view of the extension's functionality, I used webextaware to retrieve all publicly available Firefox add-ons from addons.mozilla.org (AMO) and looked for similar patterns. Through this method, I found twenty add-ons that I subjected to an additional review, which can be put in two evenly sized groups based on their characteristics.

"The first group is similar to the Web Security add-on. At installation time, a request is sent to a remote server to fetch the URL of another server. Whenever a user navigates to a different location, the URL of the tab is sent to this remote server. This is not just a fire-and-forget request; responses in a specific format can activate remote code execution (RCE) functionality," Wu said. "Fortunately, the extension authors made an implementation mistake in 7 out of 10 extensions (including Web Security), which prevents RCE from working."

https://www.bleepingcomputer.com/news/security/mozilla-removes-23-firef…

I consider signature checks to be a to be a security vulnerability themselves if they disable security features like this. I don't know how you think it's helping anyway, being signed by Mozilla means almost nothing in the context of Tor Browser.

> What exactly is the risk by setting it to false?

If you forget to also disable autoupdates of addons, potentially a malicious attacker might be able to trick your browser into installing an (unsigned!) piece of malware masquerading as a legitimate update. Or if you forget and install an (unsigned!) add-on, you will have... installed unverified software, which again might be malware. It's hard to guess how likely these scenarios really are, but the fact that they must be taken seriously because a certificate expired is really shocking and outrageous.

As I understand it, this emergency temporary mitigation is not a *fix* and it involves a security tradeoff.

o An intermediate cert needed to verify NoScript autoupdates expired owing to a goof at Mozilla.

o Ensuring that NoScript is working correctly is critical to Tor Browser.

o So you should disable signature verification until Mozilla fixes the cert.

o When that happens Tor Project will release an emergency new version of TB.

o Be careful to avoid installing any extension or allowing any autoupdates until the new TB is released; I think in most cases you should get a dialog box asking if you want to install something and of course you should say "No" because that something will not have been authenticated.

> If you forget to also disable autoupdates of addons, potentially a malicious attacker might be able to trick your browser into installing an (unsigned!) piece of malware masquerading as a legitimate update.

The bundled add-ons (HTTPS Everywhere and NoScript) update from mozilla.org by the preferences extensions.update.background.url and extensions.update.url in about:config[1]. So, if you don't trust Mozilla's review process for add-ons nor the developers of your add-ons, then you may want to temporarily disable automatic updates of add-ons. It's a greater concern if you installed add-ons after installing Tor Browser. Mozilla probably is being extra cautious about reviewing add-ons or not doing it at all until most people install the patch.

How to disable automatic updates of add-ons:
Add-ons tab -> gear icon -> uncheck Update Add-ons Automatically. Or set extensions.update.autoUpdateDefault to False in about:config. It prevents your HTTPS Everywhere and NoScript from receiving security updates, so remember to enable it or set it to True again after you install the patch to be released for this bug.

We actually get HTTPS-Everywhere from the EFF as we did not want to use the Mozilla version. That way in case Mozilla messes something up with their extensions we'd have at least HTTPS-Everywhere working as in this case.

People must understand that Signed != Verified

It's exactly the same bullshit as signed programs in M$ Windows. It takes control from you and gives it to corporation (Mozilla Corp in this case), while giving you the false sense of security.

You have a point. But verifying a sig is much better than nothing, and TP needs to always bear in mind the possibility of overwhelming newcomers with esoteric concerns.

It's a challenge, but we need to grow the Tor user base by leaps and bounds.

did this in the real firefox. the setting is there, but the addons in that browser remained disabled, and even after removal i couldnt redownload and install them with the workaround. i guess the same will be true for noscript: now its disabled the ff part of torbrowser will somehow know it was disabled unverified and prevent re-enable. cant reinstall. cant reenable. whats the point?

Supposedly using Chrome means getting less captcha challenges, so maybe changing user agent. Unless it's some other magic behind the scenes data Chrome is telling google about you to tell recaptcha you're real. Which I wouldn't rule out.

Don't forget that Google is not just a company or an executive suite but also a large workforce of highly skilled employees, many of whom rebelled against Dragonfly (Censorbrowser) and Project Maven (the killbot death listing AI project for the Pentagon). Unfortunately those employees have already experienced retaliation. So we should direct our ire and the executive suite, not neccessarily people who work at Project Zero (for example).

Anonymous (not verified) said:

May 04, 2019

Permalink

Is openly publishing for exit does still a good thing ? They become to easy blocked , tor is becoming heavily attacked more and more these days

I think it's unavoidable. Exits go to the clearnet, so the clearnet can always see whether traffic from an IP looks like a proxy. If they weren't published, third-party monitors would detect and list them as high traffic proxies anyway.

> Is openly publishing for exit does still a good thing?

I don't think there is any way of keeping the IPs of exit nodes secret. It is hard to even keep the IPs of bridges (unpublished "stealth" entry nodes needed for anti-censorship) secret.

Kim Jong-un sucks (not verified) said:

May 04, 2019

Permalink

This is crazy dangerous and can have put peoples life on risk. Why can addons be disabled remotely anyway? This was not some kind of update where it stopped working after the user applied a update, but it just happened all by itself in the background. WTF! Tor devs you should not trust mozilla this much leaving this open channel, this proves why

True, this was a serious blunder. But from what I understand, this happened because a certificate *expired*. If so, it wasn't disabled remotely; it was disabled because a certain predetermined time had elapsed. It wasn't a deliberate action from Mozilla or anyone else, and it wasn't something that a malicious actor could have triggered if they had wanted to.

I hope that Tor Browser devs (and Mozilla too) will learn from this and make the system more robust in the future. Tor Browser should always trust the extensions that are bundled with it, and that trust shouldn't be time-dependent. Ideally, it should also "fail closed" so that if NoScript is unavailable for any reason, the browser should default to javascript.enabled=false.

> It wasn't a deliberate action from Mozilla or anyone else, and it wasn't something that a malicious actor could have triggered if they had wanted to.

Expiration can be deliberate, and actors can disrupt attempts to extend the time. Think of its relation to revocation too. But there aren't indications at this point that this particular situation was deliberate.

Nothing is expired, they have timer that checks signatures every 24 hrs, like in corporate gaming consoles, look for yourself here:

app.update.lastUpdateTime.addon-background-update-timer
app.update.lastUpdateTime.recipe-client-addon-run
services.blocklist.addons.checked

> Why can addons be disabled remotely anyway?

To verify the cryptographic signatures of code before installing an add-on, we need to verify the certs in a chain. In this case, one of those certs expired because Mozilla goofed. That silently disabled NoScript, putting us all at risk. Outrageous? Yes. Incredible? Unfortunately not, if you have followed decades of criticism of the many weaknesses of current PKI.

Security is hard. Very hard. This incident reminds us that human error remains as much a threat as malicious attacks exploiting some unrecognized technical flaw in software incorporated into the Tor ecosystem.

Another perspective:
The sig files on the Tor Browser download webpage are a different type of cryptographic signature that we use to verify Tor Browser before installing it. They are created from Tor Project's cryptographic keys that are also capable of having expiration dates. If those keys expire and we tried to verify the Tor Browser installer, we would either not be able to verify it or be presented with a warning message from our verifier program, i.e., gpg. But we wouldn't be denied from installing it regardless or suddenly find it was uninstalled.

Good point. But I would never install unsigned code. Which unfortunately means I cannot help test alpha versions of some good stuff like upcoming Tails because (incredibly) these are unsigned.

Calbillie (not verified) said:

May 04, 2019

Permalink

There is more to this and a real solution will be for Tor to decouple from mozilla as much as possible. But really we need a new browser decoupled from all the states/govts and really if Tor doesn't change then it becomes suspect in govt. chicanery.

In an ideal world, clearly yes, Tor Browser should be independently developed with security in mind from the ground up, and regularly audited. That would take resources far beyond what TP will be able to muster in the foreseeable future.

I think the only long term solution, which satisfies among other desiderata the principle that "if you want it done right, do it yourself", is to evolve Tor Project from a tiny NGO dependent upon the "largesse" of untrustworthy governments and corporations to a user supported human rights NGO with a stupendous endowment enabling it to decline firmly offers of "help" :-p from the likes of Google, Amazon, Facebook, US State Dpt, DARPA, etc. That will take hard work, dedication, and a long-term commitment from community organizers, as well as a "no-strings" multimillion dollar gift to the Tor Foundation from some repentant tech billionaire.

Not an ideal world is required I'd say. Look at git. One guy started it (yes high visibility guy) and the ball started rolling. Why? Because it was clear to thoughtful people that it was the right thing to do. There are many thoughtful people that can see quite clearly that the current web trajectory is bad. We really have no choice but to create a new browser. What it's based on? Don't know.
Git is based on sound crypto science and the motivation of source freedom. And freedom from hindrances that alternatives had/have, technical/legal/etc.
So the right seed gets planted and right minded people will feel motivated to contribute. Otherwise it becomes yet another shitshow of which there are so many now (in all aspects of life).

Anonymous (not verified) said:

May 04, 2019

Permalink

After setting it to false restart Tor and then change it back to true so you won't forget to later on. As long as you don't restart again the addon still work for me fine though there is a warning about NoScript not being signed.

There is also another way to do this on Firefox though not Tor. Tools, Options, Privacy & Security, go to Browser Data Collection and allow Firefox to install and run studies. You can undo it right afterwards and it will still work.

Anon (not verified) said:

May 04, 2019

Permalink

@Calbillie What browser would you use as the base of Tor? Better yet would you build an entire new one? Because that is an insane amount of work that will take a long time. This doesn't even get into all the security checks that would need to be run by the community for quite a while before it would even be possible for download.

Then there would be porting over the addons over to the new browser, troubleshooting that until each work, make sure no security risks are added, etc.

Chromium would be the obvious choice. It's a much more secure and stable base than Firefox, with a lot more resources behind it. Not sure how easy it would be to adapt it to the Tor Project's needs though and to keep porting these changes to newer Chromium versions.

Something would have to be done about the integration.
Ungoogled-Chromium is not really a different/separate browser, it is just vanilla-Chromium gutted/patched to the extreme & updated per-release of vanilla-Chromium.
Other than being updated slightly faster, I fail to see how vanilla-Chromium is better in any way than Ungoogled-Chromium.

The problem with Chromium is that in effect you have to trust Google, a company which is reorganizing as part of the US military-surveillance complex (c.f. their AI kill-list for US drone strikes, to mention just the most notorious example). Or maybe even the CN military-surveillance complex (c.f. censorbrowser).

Yes, Chromium is open source, but is it really adequately audited on a continuing basis by reliable (non Google) coders? If not, Tor Project cannot possibly take on that job.

I have to agree with those who say that the only thing we can do is to urge Mozilla to try harder to avoid such dangerous (and embarassing) goofs in future.

Another advantage of Mozilla is that Tails is based on Debian which uses Firefox as the default browser. So there is a huge user base which has a stake in making Firefox safer.

Mozilla needs to comply with government requests just as Google does. Firefox also has Google integration, as well as its on trackers. You don't have any privacy advantage if you compare stock Firefox to stock Chromium. All you have is a much weaker security model on Firefox.

Years ago I remember the precursor to Project Zero freaking out because they discovered a new and very dangerous APT attributed to CN military. In those days Google did not publicize USG state-sponsored malware, but reacted strongly to CN state-sponsored malware. They had cause to regret trusting USG when they read the Snowden leaks and saw that infamous smiley.

These days it appears possible, even likely, that Google is betting it can make more money by kow towinig to the CN dragnt surveillance machine than the US dragnet surveillance machine. If so in future you may see Google publicizing NSA APT malware but saying nothing about CN APTs.

Something to think about when you think about the meaning of the phrase "government requests".

But Firefox is not safer. In fact, it doesn't even begin to compete with Chromium. There also isn't a "huge user base" in Tails. The user base of Tor and Tails is so tiny, it would barely even show up on regular website analytics. Just because Firefox's code is out there does not mean even one person just goes and audits it in their free time and keeps doing so for updated code. It's just not what happens. It's a fallacy to believe that just because something is open source, there will be people who audit its code. Google has a much better track record than Mozilla, when it comes to security. Security is an essential piece to even begin working on privacy. Firefox doesn't offer it.

If you want something audited, you can pay a team of professionals to do so, and then keep doing so as the code is being changed. Nobody does it for free, for obvious reasons.

> The user base of Tor and Tails is so tiny, it would barely even show up on regular website analytics.

And we need to change that. Spread the word! Teach your friends to use Tor and Tails!

And besides all those reasons, Chromium's main developer is a company that's business model is built on ads and therefore "sharing" user data with other parties, and any decisions they make will be a compromise between real security and their bottom line, which is essentially built on breaking privacy.

If I remember correctly, the issue with Chromium wasn't so much that you'd have to make all this changes. After all, many changes had to be made to Firefox too. Rather, Chromium not accepting changes upstream was the issue and having all this patches rebased onto every release is error prone and time intensive. Probably not doable with the small team working on Tor Browser at all. Mozilla, however, accepts patches to upstream Firefox and is even willing to help with advice, review and making sure the features keep working.

Lets use an insecure browser, because "muh free market economics".

The Chromium code base originated in the open source code community, while Firefox is commercial code that comes from the company that made the Netscape browser. Google doesn't own Chromium, it belongs to the world.

Does anyone really think Google's going to backport security or anti-tracking stuff from a Tor Chromium to mainline Chromium? Because Firefox does. For example:

https://www.zdnet.com/article/firefox-to-add-tor-browser-anti-fingerpri…
Or just search for "Tor Uplift", the Firefox project to review and integrate privacy changes from Tor into Firefox master.

Barry (not verified) said:

May 04, 2019

Permalink

Weird. My Tor Browser (8.0.8) and its default plugins (NoScript 10.6.1, HTTPSEverywhere 2019.1.31 are working without issue and it's showing that I'm running the latest version.
Is this blog post in relation to non-default plugins only?

Blazito (not verified) said:

May 04, 2019

Permalink

Has anyone been able to get NoScript working? The work around posted does not work for me. Regular firefox has been fixed for me and all the addons are now working, but TOR still has NoScript disabled. Is TOR going to push an update?

Yes, the workaround worked for me. The NoScript icon came back on the toolbar some minutes after I set the preference to false, and I didn't restart. See if it comes back after you close and restart the browser.

>The work around posted does not work for me

After you change the about:config preference "xpinstall.signatures.required" from Value "true" to Value "false", you have to quit and restart Tor Browser.

mehdi (not verified) said:

May 04, 2019

Permalink

SHAME ON MOZILLA!
What happened with prenty of already installed add-ons which suddenly got remotely deactivated by Mozilla (no choice given to the user about what to do) is UNACCEPTABLE and INEXCUSABLE since it unexpectedly left Tor Browser users exposed, without security feautres they were trusting and using in that moment to protect their privacy: a rogue move by Mozilla that could have possibly pose threat to the lives of activists and dissenters whose presence in the world wide web relies on Tor Browser. The Mozilla Foundation and those in charge of the Firefox development roadmap must be held accountable for their misconduct. Plain and simple: they acted as miscreants. Was it only a matter of carelessness?
It's extremely sad to state that the Mozilla Foundation seems to be increasingly focused on its own politically biased agenda: more propaganda and far less technological care, respect and responsibility towards its user base.
I call on the steering group of Tor developers: please take seriously into account the incident of such sudden deactivation of (critical) Firefox add-ons, including those bundled with Tor Browser!
Firefox is an UNRELIABLE piece of software to build privacy upon. The Mozilla Foundation is an UNRELIABLE and TREASONOUS partner. Seriously, look for a viable alternative!

If you happen to come back to check replies, please state any conflicts of interest you may have in writing this comment such as:

  • if you receive any money from a competitor that could benefit from Mozilla's loss
  • if you receive money or participate in a consumer protection organization that could benefit from maligning Mozilla
  • if you have had a dispute with Mozilla in the past that hasn't been satisfactorily resolved.

as you do not seem to be looking at this situation objectively.

I think that risking one's freedom or one's life is a sufficient reason, it is not necessary to assume any conflict of interests.
This is not (only) a usability problem and it is not even a 0-day worth a million dollar, this is a very serious problem caused by an equally serious carelessness from the mozilla team.

javascript can now be covertly used to find the real ip address of dissidents. but this is now apparently unobjective. i would point out that whether or not this is the law of unintended consequences biting torproject in the ass before mozilla, i would say thats irrelevant. the fact remains that because of firefox devs making a poorly judged decision, and then brute forcing it on people rather than giving a warning and offering them the choice whether to take a judgement call on the risk on their addons, that peoples real lives are now at risk, more than they would have been had they not had tor at all.

no i have no connection to mozilla or any browser maker. i actually prefer firefox over chrome because i find ff easier to deal with in terms of addons, finding and using them. chrome can be quite opaque in its features also.

but while i used both, i no longer trust firefox, because of the FORCED nature of its decision. and because tor did not seemingly know about it.

its going to be a while if this gets on the mainstream news, and longer if anyone dies because of it, for mozilla to recover. if it doesnt wind up going under.

> rather than giving a warning and offering them the choice

Mandatory signing was controversial when it was introduced in 2015. Speaking of warnings, there was "a transition period of two release cycles (12 weeks total) during which unsigned extensions [only generated] a warning in Firefox. After the transition period, it [was not] possible to install unsigned extensions in Release or Beta versions of Firefox."
https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-expe…
https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signi…
https://wiki.mozilla.org/Add-ons/Extension_Signing

Ignored by tor developers? You realize you're commenting on a Tor blog post that is dedicated to addressing this specific issue? They gave a workaround and said they will ship a fix when it is available from Mozilla. What else do you want?

I'm unsure what you mean by ignoring. It's only a handful of people working on Tor Browser, and yet there is already this blog post, the necessary changes to the code have been made and the fixed version is already being built and tested. Seems pretty good to me.

Of course, it would be better if more people helped out. Perhaps, then the next issue like this is discovered and fixed even before the certificate expires.

> The Mozilla Foundation and those in charge of the Firefox development roadmap must be held accountable for their misconduct. Plain and simple: they acted as miscreants.

Mozilla has been doing a great job at improving privacy for their users lately. There is Firefox Focus, implementation of containers, accepting patches for Tor Browser (investing a considerable amount of their own time on advice and review), matching donations to Tor and much, much more.

Do you really want to blame Mozilla? To me, I'd seem they are doing a better job at security and privacy than almost all of organizations on the internet. Also, it rather odd to blame someone for trying to do the right things.

> Was it only a matter of carelessness?

Are you suggesting this could have been intentional? If so, with what purpose?

> Seriously, look for a viable alternative!

Is there one? Please let me know.

> Was it only a matter of carelessness?

The fact that the inadvertent logic bomb detonated a few days *after* May Day is indirect but useful evidence that this was not a deliberate act engineered by "the usual suspects" (e.g. FBI). Because the usual suspects would likely want to spy on Tor users just *prior* to May Day not just *after* May Day.

More importantly, over the years there have been a number of widely reported new stories about some huge company forgetting to update a cert. So there's plenty of evidence that organizations large and small are finding it very difficult to maintain their cryptographic assets.

I don't mean we should excuse Mozilla (or anyone else) from overlooking a critical deadline; my point is that there is no reason (AFAIK) to think this was anything other than a mistake. A serious mistake, but a mistake which to their credit Mozilla quickly fixed.

Sadly, I must agree with the final assessment. Though FireFox/Mozilla has, over time, come to be trusted, the excuse that it doesn't allow such add-ons as NoScript due to cert failure, simply doesn't hold water. As the base, which controls cert behavior and setting the handshake needed for validation, FireFox does not require a specific cert to be incorporated w/in their Add-on suite and therefore, restrictions to the HTTPS/NoScript add-ons should not have that excuse used (overlooking cert validation) when they fail to permit an Add-On.

In most cases, the reasoning the general public hears, is not true. There are multiple channels that can be used to ensure that a specific event does or does not happen, and something that has been a stable capability for years is not suddenly affected.

Developers for both FireFox/TOR and other Mozilla based products in most occasions follow one simple rule: If it's not broken, don't fix it. This spans across any organization which must fund their resources based on time-spent towards a specific Goal and Objectives. That funding can only occur if there is sufficient money to use in order to make enhancements and/or platform changes.

By blocking and preventing key components from being installed and used, especially for those that have been around for as long as NoScript has, this change was conscious and intentional, with the target for what this add-on offered to the public.

And, while the Organization shall find a so-called "workaround" or eventually permit the originally branded product to be used, this entire approach to suddenly remove its ability from the platform did nothing but buy some time for the platform developers to devise a side-step to what shall eventually be permitted.

Make no mistake about it. There are people w/in Mozilla and elsewhere that expect anything based on this technology to follow requirements, otherwise, funding shall be stripped, and failure to comply shall result in unpleasant and personally impact consequences for all stakeholders in the product and product supply chain.

It is a sad day folks... Your privacy and all aspects surrounding your public and private life can and is likely to be impacted. Not only in free countries, but around the globe where others tend to simply make someone disappear when they don't think they want what they're doing to stay with them.

Signatures of add-ons are checked in Firefox's code whenever something calls XPIDatabase.verifySignatures() or possibly XPIInstall.verifySignedStateForRoot. A timer is hard-coded to call verifySignatures() every 24 hours after you open the browser, but other actions may call it at any time. I was unable to search for "verifySignatures" to find all actions that call it on Mozilla's web repository because the search timed out, and I didn't want to clone the whole repository just to search for a string. I don't know if Mozilla's hotfixes verify them immediately or how long it waits.

  1. const XPI_SIGNATURE_CHECK_PERIOD = 24 * 60 * 60;<br />
  2. ...<br />
  3.       timerManager.registerTimer("xpi-signature-verification", () => {<br />
  4.         XPIDatabase.verifySignatures();<br />
  5.       }, XPI_SIGNATURE_CHECK_PERIOD);

https://phabricator.services.mozilla.com/source/mozilla-central/browse/…

You can reinstall Tor and do not wait for the Mozilla's "solution" using the following workaround:
...Browser\TorBrowser\Data\Browser\profile.default\user.js
########################
# User Preferences
user_pref("app.update.auto", false);
user_pref("app.update.enabled", false);

user_pref("extensions.update.enabled", false);
user_pref("extensions.update.autoUpdateDefault", false);

user_pref("xpinstall.signatures.required", false);

########################
So you have to
1) install fresh Tor
2) +remove checkbox "start TBB" at the ending of installation!!! (do not start TBB!!!
)
3) put user.js to the "profile.default" folder
4) now you can start TBB easy - it will work

It helps with Windows TBB. BTW when Mozilla&TBB will solve the issue - you HAVE to change all "false" to "true" certainly.

Old versions are just as susceptible and have more unpatched vulnerabilities. I don't know if your method of turning off updates has any effect on checking signatures, but if it does, it wouldn't work unless you turned it off very quickly before it ran the automatic routines.

So you use a version with the commercial spy stuff removed.

Interesting comment about the two code bases here:

https://marc.info/?l=openbsd-misc&m=152876412422034&w=2

"There's a great irony here…

Firefox is a derivative of the Mozilla code base which used to be known
in the general public as Netscape. Netscape Communications was a
for-profit company, that actually *sold* their browser for commercial
use (it was only free for personal use).

Chrome and Safari both derive from Apple WebKit which itself is a fork
of the KHTML rendering engine developed by the KDE project, and has
*always* been, LGPL licensed code since its first release in 1998.

Yet today, Firefox is held up as the open-source darling and
Chrome/Safari is seen as the proprietary devil. Go figure. :-)"

I disagree. It's true that google has the resource to employ world-class security researchers in the world (google project zero discovered numerous security bugs) to make their browser secure.

However, privacy-wise (which is Tor Browser all about!), chrome is a very poor choice. One has to understand that making profit with user's data is part of google's business model, e.g, gmail scans user's mail for targeted advertisement. Chrome is especially bad, it is a chromium (which is free/libre and open-source) based proprietary browser with many anti-privacy features (such as sending your usage pattern to google).

Being proprietary, it is impossible to audit the code. Even if we choose to base tor browser on chromium instead of chrome, it would be a maintenance nightmare to make absolutely sure all anti-privacy features has been turned off in chromium.

A better option is to use a non-corporate-backed browser - which is firefox!

If you want firefox to be more secure, please help to report bugs or denote!

Chrome (well, Chromium, which is the open source version) is significantly better. I'm an exploit dev, so I'm not just parroting what someone else said! Chromium has more and better security mitigations that make traditional exploits very hard to use and necessitate complex and unreliable exploit chains. Firefox is much easier to exploit. The only benefit Firefox had over Chromium, which was the power of the XUL browser extension API, no longer exists now that WebExtensions are a thing and now NoScript in Firefox is not nearly as powerful as it used to be.

Unfortunately the real reason Tor Project can't move to Chromium is that Firefox is easier to maintain a fork of because it releases snapshot versions called "ESR". Chromium is much harder to track and requires a bigger and more dedicated team to manage, even if it is more secure.

No, but it's all too plausible that NSA/TAO, GRU, and other state sponsored hackers regularly read Tor dev lists, monitor Tor dev chat rooms, and even occasionally post in this blog.

It's also plausible that such entities have tried, are trying, and will continue to try to insert their own operatives into TP as a kind of "double agent". I hope that TP is trying hard to make that difficult.

You're right, you just have to trust me. It doesn't really matter though anyway because it's not that elite of a position. I'm not one of those experts with a dozen priceless 0days in his home dir.

I suppose one shouldn't ask for whom you develop exploits or what your intentions are.

That aside, I think you have correctly explained why currently TP really has no viable alternative to being based upon Firefox ESR.

I think it's a fine thing to ask. Answer: I develop exploits because it's fun and lets me root personal devices that otherwise would be locked down ("jailbreaking"), because I hate DRM and I hate that a device you own is not truly yours. When I find bugs in software that people rely on (e.g. browsers, OS components) I contact the vendor and disclose the vulnerability used so that they can fix it. I am not an exploit broker who sells bugs, and I despise people and companies which do.

An exploit dev is not automatically a black hat who sells their bugs!

null (not verified) said:

May 04, 2019

Permalink

Firefox is dead since their intentional ridding of ALSA as a fallback audio interface in Linux, their sly attempt at adverts as a browser and these incidents....
Palemoon Browser needs more publicity... if the team behind Palemoon and Tor worked together at making Palemoon "secure" and the default Tor browser, that would be perfect.

Yes, Pale Moon is the bloat-free, lightweight version (fork) of Firefox, i love it too. It would be optimal for Tor. And - if privacy - don't trust Google-related products.
Reading it on Pale Moon at the moment :)

No thanks (not verified) said:

May 05, 2019

Permalink

prove what? you must be ignorant. if you think Google and Facebook are spying on you but Mozilla isn't you must be brainwashed.
1. this isn't the first time Mozilla slipped into this mess, do you like Mr. Robot because Firefox knows you do.

2. check out the steps needed for a temp fix.

3. your browser just REMOTELY disabled something without your permission. no alarm bells are ringing in your head? ???? have you checked the source to see if anything else can be remotely controlled?

Hey that thought came(?) to my mind as well....how was it disabled without me doing anything?

But we should believe someone sometimes, just to make ourselves feel better.

What is even more funny, they became bold and push for remote controlled "hotfix" in the "studies" - literally the thing that let's them control your browser remotely 24/7. If you disable that, you wont receive the "hotfix" - corporate fear tactics.

Philip Manzur (not verified) said:

May 04, 2019

Permalink

Hi friends...having noticed that Java Script is still enabled despite using (as always) the highest level in my settings, I would like to know whether you recommend to stop using Tor till the problem is finally solved...sorry for my simple question, but I am a "newbie" in technical matters...Thank you very much indeed for all your efforts and permanent support...best regards.

Don't worry, there is no chance TP will ever adopt Chrome (or even Chromium probably) as the basis for "Tor Browser gen 2".

Adding security features after the fact as Mozilla tries to do with FF is not the best way, but currently it may be the best way TP can actually use.

To get a specialty browser writtten ground up for TP you need to give TP a LOT of money.

certifiable (not verified) said:

May 04, 2019

Permalink

warning.
mozilla disabled noscript extension, leaving javascript enabled

set this to "false".
about:config?filter=javascript.enabled

also, when mozilla auto-disables an extension, they should automatically set associated Firefox prefs to the secure value.

is this mozilla "bug worthy"?

unsure (not verified) said:

May 04, 2019

Permalink

blunder of the decade... but sure, let's keep firefox as our frontend, just toogle this boolean and that boolean and then toogle it again... :poolparty:

tor needs something simple like epiphany, midori or falcon.

smallDetails (not verified) said:

May 04, 2019

Permalink

Has anyone noticed that The Tor Project has been open and honest about this problem ?
Anyone notice that posts critical of The Tor Project have remained ?

Sometimes its the little things.

Anonymous (not verified) said:

May 04, 2019

Permalink

Mozilla is working on a fix, and we'll start building a new Tor Browser version as soon as their fix is available.

Don't forget Tor 0.4.0.5!

0.4.0.5 won't be included in this update, as we try to minimize unrelated changes to avoid issues which would delay the update. We also did not test the dormant feature introduced in 0.4.0.5 in an alpha yet, so it will probably get included in the next alpha first.

Anonymous (not verified) said:

May 04, 2019

Permalink

During this time, malicious actors are likely to take advantage of the fact that many people do not read this blog. This is a big deal and puts into question trust in Mozilla.

Take advantage in what way? It's basically the same as moving the security slider to "low" isn't it? If someone was going to take advantage, for example by a javascript exploit, wouldn't they have been doing so all along? I guess there could be a greater number of tor users now with JS enabled and thus more potential victims, but...

It's not like it was silently disabled. The browser gives you a big yellow banner the moment NoScript is disabled. If you moved the security slider above its default "low" in the first place, than you should have a pretty good idea of what that warning means and the implications of it. If you choose to go on using the browser without NoScript, and you choose not to check the Tor blog for news about the issue, then it kind of becomes your own fault.

It's like ignoring your check engine light and then blaming the manufacturer when your car finally breaks down.

> Take advantage in what way? It's basically the same as moving the security slider to "low" isn't it?

For most users who were (only briefly we hope) affected, that is probably right.

The problem is that the higher settings of the security slider offer substantial security improvements which might really be needed by some users for some things, and (for a short time) some of them might not have realized that NoScript had been disabled which broke the higher settings.

Right now there appears to be no reason to think the cert expiration was deliberate (it is well known that large organizations have a lot of trouble avoiding this kind of mistake entirely) so there is reason to hope that adversaries such as NSA were caught flat footed just like we were, and were unable to quickly exploit the problem to attack us. We hope.

Anonymous (not verified) said:

May 04, 2019

Permalink

In addition to disabling a security feature, does this change the browser fingerprint at all? Wouldn't this workaround significantly increase the attack surface in the browser? Why is Tor Browser "phoning home" to Mozilla anyways? I'm not a cybersecurity expert nor do I pretend to be, I am genuinely curious.

xpinstall.signatures.required doesn't change the browser's fingerprint. Add-ons, for one thing, do. By setting it to false and making sure NoScript comes back, your fingerprint will go back to looking like Tor Browser as long as you don't install or manually disable add-ons. Tor Browser updates its privacy-security add-ons from Mozilla's repository and works with add-ons as Firefox. Tor Project works with the developers of the add-ons it bundles and audits their source code. But it's definitely good to look into the extent of what's phoning Mozilla and if it's necessary.

Minus one.

Tor devs often face tough choices to be made in a short time with imperfect information. On the whole I think they tend to make the best possible choices under often difficult circumstances.

I think we probably agree that in an ideal world, security/privacy/anonymity would not be so hard. And I hope you agree that we can get closer to the ideal if we can move Tor Project to a user supported funding model and greatly increase its operating budget, free of government/corporate influence. I hope you will consider making a donation to TP.

(I am a user like you, not an employee of TP.)

Anonymous (not verified) said:

May 04, 2019

Permalink

Georg Koppen, why do you, as the only one decision-making person, publish this inconvenient blog post about forcing users to manually switch off the security feature in order to make Tor Browser to operate properly instead of doing an emergency release with NoScript added to sig verification exceptions as Torbutton?

We are currently working on an update, but this cannot be done instantly. Meanwhile, we have this short blog post (which was also reviewed by a few people) to explain the issue and give a possible workaround for the people that can't wait for the update.

1. In part, because I (a Tor user) asked him to do so (in the #tor chat room).

2. Mostly because keeping Tor users informed about critical security issues is obviously an absolutely appropriate thing to do.

Also, the problem is that Mozilla goofed by letting a certificate expire, which had the horrible effect of silently disabling NoScript, an essential part of TB security. So TP needs to wait for Mozilla to fix the cert before TP can issue an emergency bug fix for TB.

@ gk:

Thanks again for posting!

> NoScript added to sig verification exceptions as Torbutton

Hey, that's a good idea. extensions.legacy.exceptions Easy for developers, transparent to users, and if I understand correctly has the same effect as xpinstall.signatures.required but precise to NoScript, not all add-ons.

Yes, that's one of the options on the table. However, this kind of exception has the risk that there might be holes open now to get you a non-signed malicious NoScript installed. So, there is a trade-off to make here as well.

Lisa (not verified) said:

May 04, 2019

Permalink

OMG, not having no script really sucks. I was ad-free at a spot I visit often. Now, I'm getting one ad after another. I hope whatever this problem is, it can be solved. I feel like I'm under attack.

Joe (not verified) said:

May 04, 2019

Permalink

The workaround isn't working in regular Fx 63. Changing "xpinstall.signatures.required
to false & restarting Fx doesn't reverse disabling of addons.

Maybe forcing Fx to check for addon updates AFTER the about:config change is needed for the fix to work? In regular Firefox I did a manual check for addon updates - were none.
Restarted Fx - no change.

However, in regular Fx following Mozilla's suggestion of enabling "Studies" in Fx preferences, here: https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-…
& restarting Fx, then waiting a couple of minutes - doing another check for addons & all addons were enabled again.

They mention it might take much longer (hours) for the Studies to be applied in Fx and also some different, associated issues some users reported (& list possible fixes) .

Anon (not verified) said:

May 04, 2019

Permalink

The real fix to this would be to develop on the Gnome or KDE browsers instead.

If people keep using chromium or firefox as bases they will inevitably keep breaking features and by extension users privacy and security. I'm sure quite a few peoples password security will be at risk right now as well.

Firefox has been slowly feature creeping to a standard that the big tech companies want: more cloud features, more 3rd party extension, and less data actually kept securely in the hands of their actual users.

At least with a project like Gnome you'd know there'd be an army of other linux users waiting to fork the browser if there was any issues like this.

Anonymous (not verified) said:

May 04, 2019

Permalink

One important point no-one is talking about: when did the cert expire and when did Mozilla learn about the problem?

If this was an unrecognized critical flaw for many months that would change this from "a serious blunder which could potentially endanger people all over the world" to "a serious blunder which likely cost an unknowable number of political dissidents their lives or freedom".

Anonymous (not verified) said:

May 05, 2019

Permalink

Thank you, every bit of information helps. What I really need to know now is when the certificate which caused the problem actually expired.

Note for anyone following the link, the "fix" they describe does not apply to Firefox ESR, which will be fixed "soon".

> when did the cert expire and when did Mozilla learn about the problem?

Expired:
Sat May 4 00:09:46 2019 UTC (2019-05-04)
Mozilla bug #1548973 reported:
Sat May 4 00:49:00 2019 UTC (2019-05-04)
About 39 minutes after it expired.

"Some reports on reddit says that they had their clocks a day forward, but they may be just early canaries for the actual widespread issue." [1]

It's a PKCS #7 certificate. [2] Certificate information:

  1. Organization (O) = Mozilla Corporation<br />
  2. Organizational Unit (OU) = Mozilla AMO Production Signing Service<br />
  3. Common Name (CN) = signingca1.addons.mozilla.org<br />
  4. Validity:<br />
  5.     Not Before: May  4 00:09:46 2017 GMT<br />
  6.     Not After : May 4 00:09:46 2019 GMT
[3] [4]

Or do it yourself:

  1. Copy the NoScript add-on installer (XPI file) from your Tor Browser folder to a temporary folder so you can work on it. The XPI file is named as the UUID of NoScript: 73a6fe31-595d-460b-a920-fcc0f8843232 (See question 2.6 in NoScript FAQ. Microsoft calls them GUID's.) ./tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/extensions/{73a6fe31-595d-460b-a920-fcc0f8843232}.xpi
  2. XPI files are ZIP files, so open it in your local unzip program. If it returns errors, rename the XPI file to something normal like noscript.xpi.
  3. Extract the mozilla.rsa file. ./META-INF/mozilla.rsa
  4. If you have openssl command line tools installed, open a terminal (command line prompt), cd to the folder containing the extracted mozilla.rsa, and type this command: openssl pkcs7 -in mozilla.rsa -inform der -print [4]

You can grep just the names, dates, and times by doing:
openssl pkcs7 -in mozilla.rsa -inform der -print | grep -B1 -A3 -i valid

New certificate:

  1. Common Name (CN) = signingca1.addons.mozilla.org<br />
  2. Validity:<br />
  3.     Not Before: Apr  4 00:00:00 2015 GMT<br />
  4.     Not After : Apr  4 00:00:00 2025 GMT

Good discussions:
https://news.ycombinator.com/item?id=19823701
https://news.ycombinator.com/item?id=19825921

> the "fix" they describe does not apply to Firefox ESR, which will be fixed "soon".

"A Firefox release has been pushed... version 60.6.2 for ESR." (Sun May 5 20:25:00 2019 UTC (2019-05-05)) [5]

> XPI files are ZIP files, so open it in your local unzip program.

unzip had a bug which was recently fixed in Debian.

Don't know how much to worry about that; my point is that we all need to be careful to avoid making things worse with an ill-conceived "fix".

> If this was an unrecognized critical flaw for many months...

When a cert is created, the "before" and "after" dates are displayed or manually entered. Whoever made it was told the date when it would expire. It was very likely recognized. But it was forgotten, neglected, or ignored. The cert was valid from 2017-05-04 to 2019-05-04 which implies that it was created and recognized(!) on 2017-05-04 or sometime between that range of dates for it to have been of any usefulness.

anon (not verified) said:

May 05, 2019

Permalink

Please ensure core addons cannot be disabled in the future for whatever reason, I was wondering why javascript was working despite being on the safest security level

clueless (not verified) said:

May 05, 2019

Permalink

So to be clear, setting "xpinstall.signatures.requiredentry" to "false" only effects installing addons ? Is there any other effects this will have? Is this just for getting noscript to work again? What does no script do that disabling javascript doesn't?

Many websites require at least some scripts to be allowed in order to work properly. With NoScript you can decide which scripts you allow. With disabling javascript it's all or nothing. If you want to make a website to work you need to enable javascript and then you let in ALL scripts. Not just the ones that are needed to make the website work.

Suggestions (not verified) said:

May 05, 2019

Permalink

Some alternative browsers have been suggested in this thread and on other sites.
Browsers like Waterfox, Pale Moon, Vivaldi, Brave.
I would prefer the comparatively lesser known Icecat browser.
I like their user centric approach to privacy.

Desktop: www.gnu.org/software/gnuzilla/
Android: f-droid.org/en/packages/org.gnu.icecat

PLAS (not verified) said:

May 05, 2019

Permalink

For those who know, it's safer to disable Javascript from about: config or have noscript give extra protection?

another user (not verified) said:

May 05, 2019

Permalink

This problem seems like a simple enough oversight, especially as the advice has always been to not to install add-ons. The real mistake imo is that TBB's Security Level functionality depends on an add-on (NoScript), which in turn is dependent on externalities out of Tor Project's control/purview.

Functionality integral to Tor Browser should be integrated into Tor Browser: In this case that would mean building NoScript functionality into Tor Browser rather than continuing to employ it as an add-on. Please look into making this happen in a future release.

Yes, that's another option on the table we could pick and not an unreasonable one (even though it will require quite some engineering effort). We'll discuss it once the dust has settled a bit.

AGNUnymous (not verified) said:

May 05, 2019

Permalink

While Chromium seems more secure to some people, as it probably contains more security features the following also needs to be taken into account:
- The source code is very hard to audit. It is for instance hard to make sure that Chromium is free software, or even to make sure that it's legal to redistribute as this bug report shows: https://bugs.chromium.org/p/chromium/issues/detail?id=28291.
- Security is very dependent on the threat model. For Apple, the people using some of their products (Iphones and Ipads) are a threat. But for many people used by Apple's products, Apple's tight control over the device that they bought and use is a threat. So for the latter, Apple's security (restricted boot which forces people to be used by their operating system, and denying users right to install the applications they want without Apple's consent) is a very serious threat. So having that security broken or having no such security is crucial for people's freedom privacy and security. As I understand Firefox's threat model is way more aligned to the tor-browser's threat model than Chromium's.
- As I understand, more generally speaking, the Firefox political goals are more aligned with the tor-browser's political than Chrome's. As such, the design decisions and the code written carry out that political goals. As the tor-browser relies on upstream codebases for various reasons, it's probably more practical to help improve Firefox's security by working with them, rather than trying to retrofit privacy and freedom into a project like Chromium that might be driven by totally incompatible and antagonist objectives. It might also not be a very good idea to spend an enormous amount of resources just to keep up developing and maintaining that privacy and freedom retrofitting as the new versions of Chromium are released. Spending that amount of resources in a way that is more sustainable and has greater long term impact would be wiser. It would also have greater political impact as it could make the organizations that develop free software browsers better, and more generally try to influence web standards to respect users freedom and privacy and try to empower users as much as possible.

Concerned (not verified) said:

May 05, 2019

Permalink

I agree with previous comments, even if Mozilla stays oblivious TOR really needs to have some means of avoiding things like that in the future

Gob (not verified) said:

May 05, 2019

Permalink

To put it simply. Tor browser is no longer safe as scripts cant be blocked but the so called work around also causes security problems. Are we supposed to just not use tor until this is fixed? It seems like the most obvious question to me.

The security problem caused by workaround is a problem only if you want to install add-ons because now there's nothing to tell if they are safe or not. So after the workaround you can use Tor just fine. Just don't install any add-ons.

Well, to begin with Mozilla took way longer than usual to provide a fix and they needed several trials to get this right as this is more complicated than it looks. Additionally, we need to test a bit more than usual as well as we need to add an additional fix on top of what Mozilla ships as the solution interferes with one of our patches.

We have a candidate build for testing if you want: https://people.torproject.org/~boklm/builds/8.0.9-build1/ and so far everything looks good. We plan to push the update live in a couple of hours.

SlimYokozunaFromWWF (not verified) said:

May 05, 2019

Permalink

Hey hi Tor team, I just L O V E your team and work, I appreciate your work a lot. Tor messenger should have been active as well, at least a software which makes any messenger software a Tor messenger, by making changing changes in network setting of a PC. I never used Tor messenger I just think it should have been there.
I always want to donate, I want to donate every now and then.....but I think the amount under 'donate once' should be lesser than 10$, hmmmm something around 3$ or at the most 5$...for us, we are boomed and banged Chindians. :-)

Lots of love and respect to you guys!

Jack (not verified) said:

May 05, 2019

Permalink

For normal Firefox Users (not Tor!) Mozilla released a fixed version: Firefox 66.0.4.

Click help in Firefox, then About and it will update to 66.0.4.

Anonymous (not verified) said:

May 05, 2019

Permalink

I'd like the next blog post for Tor Browser releases to walk through how to backup and install cleanly. All of these different suggestions to change assorted settings can't be hygienic for the user base. It's probably best to serve a guide about it somewhere on the main website or wiki permanently anyway.

Once the bug patch is released, your team deserves a couple full days off. Your weekend was ruined. But thank you all.

Anonymous (not verified) said:

May 05, 2019

Permalink

History doesn't show ip and date of Firefox and the browser communicating over certificates to disable the security feature. Is it in a log somewhere?

I vote for VIV… (not verified) said:

May 05, 2019

Permalink

It has mouse gestures, keyboard shortcuts built in (both of which makes it a breeze to move between tabs/windows when you have multiple windows with many tabs open; needed, when doing research).

Also has screen shot/page capture, color invert (DARK mode) and many other functionality that are built into the browser, completely eliminating the need to install additional extensions/add-ons.

> It has mouse gestures, keyboard shortcuts built in (both of which makes it a breeze to move between tabs/windows when you have multiple windows with many tabs open; needed, when doing research).

Convenience is the enemy of security. I actually hate gestures. I often have the problem that an unintentional gesture maximizes TB, a real no-no. And I have no idea what motions the FF developers intend to be gestures.

Anonymous (not verified) said:

May 05, 2019

Permalink

Is this Mozilla certificate expiration and NoScript disablement a very tasty vulnerability for adversaries to exploit and deanonymize Tor Browser users by creating one or more fake Mozilla add-on certificates now or at some other times in the near or more distant futures? Can a powerful adversary exploit this vulnerability in Tor Browser thanks to the vulnerability caused by the mismanagement of Mozilla certificates for add-ons in Tor Browser? Hasn't Mozilla already demonstrated a past history on at least one occasion of serious problems in the management of Mozilla certificates for add-ons? Does this indicate Mozilla is wittingly or unwittingly caving on the user security front? Does this mean Tor Browser will be operating with lowered thresholds of user security going into the future? What is the best recourse for worried Tor Browser users operating in countries with dangerous authoritarian governments where communications with the outside world via Tor can bring arrest, torture, imprisonment, or execution at the hands of the state? In light of this exposed compound weakness in Mozilla, NoScript, and Tor Browser, is it risky or dangerous to continue to use Tor Browser if a user faces a powerful and dangerous adversary?

> Does this indicate Mozilla is wittingly or unwittingly caving on the user security front? Does this mean Tor Browser will be operating with lowered thresholds of user security going into the future?

I am not a coder but I think the answer to those two is "no". But we users are not wrong to be horrified. Seems it could have been much worse, but this should be a wake-up call.

This vulnerability was not triggered by the name on the certificate; it was triggered by the time at which the cert was set to expire.

> by creating one or more fake Mozilla add-on certificates [in the future]?

It would be extremely difficult to deliberately insert a fake Mozilla certificate without anyone noticing; much harder than the cause of this bug. Every certificate in the chain from the top root-ca-production-amo is labeled as being issued by Mozilla Corporation. If you trust what the certificates say, then only Mozilla and the add-on submitter are in the chain. The inclusion of the cert to the Mozilla software repositories is reviewed and then cryptographically signed by Mozilla developers. Tor Project later releases reproducible builds of Tor Browser. If any cert for add-ons is faulty, the browser displays a yellow warning bar.

Hypothetically, it may be simpler to coerce or spearphish a Mozilla developer to compromise the private key. I don't know if a council of developers observes how their organizational keys are created. I don't know their methods of holding their organization's private keys. Mozilla could make a new key to replace a faulty key anyway as quickly as they made the one in the fix.

> Can a powerful adversary exploit this vulnerability in Tor Browser... ?

Which vulnerability? The absence of NoScript can be exploited because individual browser fingerprints became more identifiable on Safer and Safest. The cert chain, however, appears to be totally controlled by Mozilla, no third parties.

> Hasn't Mozilla demonstrated a past history of serious problems in the management of Mozilla certificates for add-ons?

The recent event was dubbed "armagadd-on 2.0". It was reported about 39 minutes after it expired. The original "armagadd-on" in 2016 was reported about 7 days before it expired.

> Does this indicate Mozilla is wittingly or unwittingly caving on the user security front?

Yes? Unwitting is more likely. People forget expiration dates for all sorts of things. In the world of computing, another example seen very often is when a website domain name is not renewed.

> Does this mean Tor Browser will be operating with lowered thresholds of user security going into the future?

No, definitely higher. 8.0.9 repaired it and is the first step of many toward preventing the problems from happening again.

> What is the best recourse for worried Tor Browser users

Hopefully, when they saw the yellow warning bar, they stopped browsing to new pages and closed Tor Browser or started a New Identity to close all their tabs. Then, hopefully, in the new session, they came straight to this blog to look for updates and help. The basic difference was that their traffic became similar to browsing on Standard. Not exactly, but similar. The good news for at-risk users is that 1) Tor Browser continued using relays as normal, 2) the user's IP was hidden as normal, 3) the sites they were visiting could only be observed between their exit nodes and destinations as normal. The bad news, mainly, is that those sites and third-parties observing traffic from the exit node could have recorded a browser fingerprint that was more able to relate their traffic to their other traffic despite being from a crowded exit node or a New Identity. If they closed their tabs, their best recourse is to do what they would do similar in manner as if they had been browsing on Standard in that session and until they installed the fix.

> is it risky or dangerous to continue to use Tor Browser

On 8.0.9, it's as risky as if this bug was never there. As if this bug was recognized and fixed before the cert expired. Just remember to roll back any workarounds you did.

Firefox fix by… (not verified) said:

May 06, 2019

Permalink

My firefox is fixed by installing 66.04 but torbrowser still does not work. May-5- 17:00 HR EST

John Doe (not verified) said:

May 06, 2019

Permalink

Dear dev's, you should put an update for the Tor Browsers that changes the start page with the information on the current situation and with a message that using Tor Browser currently is risky.

Instead we provided an update that fixes the problem. We thought it would be better to spend our engineering capacity to get a fix out as fast as possible and inform about the problem in this blog post instead.

Drew (not verified) said:

May 06, 2019

Permalink

Hi..
does this relate to Netflix not showing on the TOR browser anymore? i keep getting an error page asking to use HTML 5 or silverlight..netflix was actually working fine on the browser when it was first installed

Trebbor (not verified) said:

May 06, 2019

Permalink

It's all fixed now but...

It's a frightening online world without NoScript. Advertisements, pop-ups, gifs and audio run wildly rampant!

Viva N/S! Viva
...

Anonymous (not verified) said:

May 06, 2019

Permalink

Little question here: does that xpinstall.signatures.required work in all Firefox ESR version or just in Tor Browser? If the former, wow I'm switching to ESR as soon as 68 arrives!

KremlinSt00ge (not verified) said:

May 06, 2019

Permalink

Noob here, rather than join the complain-fest I thought I'd try and assist by downloading the 8.0.9rc1 tarball and apply my limited tech knowledge to testing it out. NoScript icon appeared in it's usual place, looks good to go so I started to go further afield. After a couple of minutes though, the yellow warning banner appeared, the NoScript icon disappeared and Add-Ons manager reported it as disabled. I realized what I did, or rather didn't do, and that was to go to the Add-Ons manager and set the NoScript updating to 'Off'. I re-downloaded rc1 and re-installed, immediately changed the NoScript setting and all seems stable now.

Could one of the devs, if they read this, please confirm that NoScript 10.6.1 is the version to stick with in 8.0.9?

once (not verified) said:

May 06, 2019

Permalink

I continue to trust and thank the Tor team for the work they did, but the huge "incident" on Saturday and especially the lack of any information really makes me doubt Mozilla.

Maybe, perhaps, the suggestion to rebuild a new Tor Browser around something other than Firefox would be a good thing...

Mozilla was releasing lots of information. Some was on their blog and support site, but the majority of work was being done hurriedly in their development communication channels, bug tracker, source code branches, etc. Regrettably, they didn't make a fraction of as much effort to recognize the expiration date before it arrived.

Kate (not verified) said:

May 06, 2019

Permalink

Just an hour or so ago, extensions in my Tor browser went bust. Strange enough, I didn't notice any of this yesterday when the Firefoxes had their add-on-troubles. I have two Ff, 52.3 ESR and 58.0, both portable. The 52.3 ESR was 'fixed' right away with setting the xpinstall.signatures.required to false (and it still works), but nothing helped with the 58.0.

I hate the idea of anyone fussing around with my computer or switching off any add-ons in my browser with no warning and without my consent. I'm not a geek, I'm not even particularly security-minded, I'm actually the proverbial DAU who just wants a nice, uncomplicated browser. But I'm stubborn - my computer is my castle, so to say.

It seems Mozilla will use the chance to peddle its latest version, so I might have to look for a new browser. For now, only Tor and an utterly outdated K-Meleon are left - and the 52.3 ESR (but who knows for how long). I downloaded a Palemoon yesterday and it seems I might get used to it. Does anyone know if there is a portable version of Icecat?

(That's one of my silly quirks - all of my browsers are portable. I avoid installing anything if I don't have to.)

flowerpt (not verified) said:

May 06, 2019

Permalink

Please remember to

This is a bane of security. Please force this back to 'false' and alert the user if the flip is made. Better to have people have to toggle it again than to leave people accidentally unguarded.

I realize both options are bad, so "fail safe".

Developer!
This case is a disgraceful crash in your project. Blame everyone who works in the project. I think in the future you need to forever get rid of add-ons from the site "mozilla" and other third-party repositories. You need to create your own repository tied exclusively to your project, with additions specifically for Tor Browser, signed by your signature and only your certificates. This will allow you to avoid such embarrassment in the future. And users will be satisfied.

In my opinion you have seriously misunderstood what happened.

> This case is a disgraceful crash in [Tor] project.

Actually, the problem arose from someone at Mozilla missing a deadline to generate a new cert.

TP's response was in my opinion rather exemplary. Indeed, while the original mistake at Mozilla was a serious good, Mozilla also responded quickly.

> Blame everyone who works in the project.

Actually, I think everyone who worked over the weekend to deal with the emergency deserves a lot of praise and a fine dinner.

> I think in the future you need to forever get rid of add-ons from the site "mozilla" and other third-party repositories. You need to create your own repository tied exclusively to your project, with additions specifically for Tor Browser, signed by your signature and only your certificates.

In an ideal world, I suppose, TP would have enough money and employees to do that well.

If enough people donate enough money (hint hint) many long-standing worries can be addressed in a more direct manner.

intoitagin (not verified) said:

May 06, 2019

Permalink

So, as of 09:30 EST, I see a posting at mozilla.org stating that an update to ESR has been pushed. Having no idea what that might mean in reality, I started up TOR 8.08 and went to add-ons. There, I find that all add-ons (except HTTPS Everywhere) says it is working. So, I look at Help>About Tor Browser. It says that 8.08 is curtrent.
??
Are we done now? Or is the great add-on CF still in process?

A (not verified) said:

May 06, 2019

Permalink

The issue in TOR still remains unresolved, when will this be fixed, however I do appreciate the work the devs have been doing to resolve the issue, might be good to actually put it on the heading on TOR page so people dont download the previous version of TOR until the fix is completed.

Agreed completely! A warning on the download webpage or disabling all download sources! 8.0.9 fixed is released however, and links are updated. Too late. No reason to warn downloaders anymore.

Bob O White (not verified) said:

May 06, 2019

Permalink

The new ESR firefox has been out for hours. Why don't you chaps - gieven you interenatioinal user base - update as has Devuan?

Anonymous (not verified) said:

May 06, 2019

Permalink

So I installed 8.0.9, put "javascript.enabled:true" and NoScript works again, thanks a lot.
But now my "Tor enabled" onion icon, upper left, is blinking with a yellow triangle.
"Check for Tor Browser Update" it says, but there is nothing to upload.
Is FBI on its way, or what does that mean?

Pimmelchen (not verified) said:

May 06, 2019

Permalink

Hi.
Until today, Roboform Password Manager was working fine with 8.0.8. But today it has been disabled. Even downloading it again from Mozilla Addons site, it says that the file is corrupt. Why it was working fine and stopped working. How can I fix it?

AD24 (not verified) said:

May 06, 2019

Permalink

Idk about you guys but i made my extensions work again in normal Firefox by just resetting the browser to defaults and login back into my account to get back addons and settings

Grateful_Old_Guy (not verified) said:

May 06, 2019

Permalink

I am a "user" in both the regular and the social sense. i.e. I "use" without really giving back. So the least I thought I should do after many years of Tor use is to add my voice to thank and encourage Tor devs.

Disagreement is to be welcomed -- that's kinda what Tor protects -- but it is appalling to see some comments that go far beyond disagreement or excited concern to the point of being flatly offensive.

The far-and-away number one threat to free and open source development projects in my more than 30 years of observation is the loss of dedicated developers. Hell, the loss of moderately interested developers. Being subjected to hyperbolic attacks is often the beginning of people drifting away.

Do remember that the vast majority of Tor users will never participate in a forum discussion, but they represent the true value of your work. One comment rightly pointed out that that work for meaningful numbers includes protecting their very lives, and so some upset is not unexpected.

But also remember that there are those who are served by discouraging Tor developers and creating dissension in the Tor community. When you see something that is particularly offensive, or that makes you want to walk away, just consider that is probably what the source wants.

In the world as it now is, your work is exceedingly important. With Western democracies themselves becoming more authoritarian the importance of your work just continues to grow.

Truly, thank you, be well, be happy.

Very well said and very true. Thank you for pointing this out to others. This is my first post after using Tor for many, many years. Complaining, and "acting" knowledgeable are certainly not worthy in any sense.

People need to realize what open source is and then dig deeper. If a person is that concerned about the issue, stop using Tor until the next update which will include the proper fix.

Overall, I do not think this is a serious concern to most Tor users.

https://2019.sedvblmbog.tudasnich.de/getinvolved/volunteer.html.en
https://hzcyulizwd.tudasnich.de/

I see many instances of dissent that illuminate neglected things to improve or reconsider. Seeing through the emotion sometimes reveals a technical or ethical issue. It helps mentally if you do tech support but have a relationship to apply it to development at the same time.

> But also remember that there are those who are served by discouraging Tor developers and creating dissension in the Tor community. When you see something that is particularly offensive, or that makes you want to walk away, just consider that is probably what the source wants.

Plus one.

Years ago I often tried to make that point but you said it much more graceful;y and concisely than I ever did :-)

msfc (not verified) said:

May 06, 2019

Permalink

Mozilla released a fix, ESR 60.6.2, yesterday afternoon: 16:25 EDT May 5 2019. When will a new TorBrowser version be available?

Other person (not verified) said:

May 07, 2019

Permalink

Eh... Depends how one looks at it. Technically, yes, going by the default settings, time-checking disabled it locally. On the other hand, expiration time is managed remotely. It's a dead-man's switch, but if the key owner is alive and just ignores it, same result. Certainly, though, it says nothing about intention.

Making sweeping and misleading claims in times of trouble helps no-one.

In assessing a security issue it is vital to accurately understand the technical details. Those of us who don't have the specialized knowledge required should trust the Tor team, because if we can't trust them, who on Earth could we trust?

I'd add that IMO claims that "Tor is broken" or "all is lost" are just as harmful as advice to ignore security issues entirely.

Security is a process, not a state, and while this incident is very troubling (and clearly not TP's fault), the response to the emergency has been excellent.

> if we can't trust them, who on Earth could we trust?

Ourselves, the code, our build machine, crypto algorithms, math, ... The development, knowledge, and many studies are public and open if we rise to meet the challenge. They did.

No, I'm saying options are not hopeless or desolate as you make it sound. There are more ways than having blind trust and subservience for everyone and everything in the production chain. While being thankful that TP people are doing the work, acknowledge that most of us, we users, would be welcome, and many are able to learn and get involved, but we are choosing not to do the work.

> No, I'm saying options are not hopeless or desolate as you make it sound.

I'm confused. Far from urging anyone to abandon all hope, I was urging people to take heart from the fact that while the Tor community is endangered by many enemies, some lavishly funded, our enemies have problems of their own and our situation, while precarious, is by no means hopeless.

> There are more ways than having blind trust and subservience for everyone and everything in the production chain.

I never urged anyone to "have blind trust" (for example, I always urge people I know to verify the cryptographic signatures before installing the latest TBB). I have argued that given our incomplete information about the hazards Tor users face, we need to try to guess an appropriate threat model which attempts to prioritize threats by the potential damage and the likelihood that they will soon be realized in practical attacks on us.

It is possible that you confused me with another commentator? (Easy to do when almost everyone here is anonymous.)

> While being thankful that TP people are doing the work, acknowledge that most of us, we users, would be welcome, and many are able to learn and get involved, but we are choosing not to do the work.

You are choosing not to help TP? Why not?

Anonymous (not verified) said:

May 06, 2019

Permalink

"Please remember to set the xpinstall.signatures.requiredentry back to true again once the Tor Browser security update is applied. "
Setting it to true makes noscript disappear

anon (not verified) said:

May 06, 2019

Permalink

Bugfix release is out, hooray! BTW, thanks for the necessary reminder to rollback the workaround!

PS: I see some interesting and important points made regarding my personal distrust toward NoScript and general addon use preferences and its impact on privacy, but going to write replies later if you allow. Have to ensure all my affected foxes got their fix and brought back to security

Anonymous (not verified) said:

May 07, 2019

Permalink

Stay cool guys, it's only a browser bug(-:.
Compare it with the systemd buglist, a new must have Linux core component.

Actually, I think both browser and systemd bugs are very serious.

There are valid concerns about systemd which are similar to concerns expressed in this thread about Chromium and Firefox. AFAIK there is not yet any evidence of actual collusion with bad guys, however. So it's another of those things where we worry, and probably should worry, but don't yet really know anything concrete which would sound the tocsin.

Kirk (not verified) said:

May 08, 2019

Permalink

Having an addon disable itself silently seems like a potential security/privacy risk.
I hope the Tor Browser devs have realized this already, and are working on some remedy.

At the very least, the Browser should always display a warning if something is not quite as it should be. So the user can make a decision about what to do.
Obviously we need to know before we load and use a website.

The add-on didn't disable itself. An intermediary signing certificate owned by Mozilla expired, and the browser is configured to disable add-ons whose certificates are expired.

It wasn't silent. When the browser disables an add-on, it displays a yellow bar across the top of the browser tabs that warns the user by saying, "One or more installed add-ons cannot be verified and have been disabled," followed by a "Learn More" button. Did the yellow bar not display for you? If so, that would be a bug we don't know and you should tell us.

I don't know how the yellow bar could have escaped my attention.
I certainly did not notice it. (and I make a point of reading any popups and warnings, because I know there will always be that 1 critical among thousands)

So I think, and am pretty sure, there was no warning.
If there was, and someone like me actually missed it, that's an important indicator in itself.

I am aware the add-on did not literally disable itself. Poor choice of words. But the point is: a security feature was disabled without the users consent - it was automatic, decided by an outside entity, with the "undo" button explicitly removed. This should not be possible, especially in the TorBrowser.

> At the very least, the Browser should always display a warning if something is not quite as it should be.

Actually I think it would have done (before we all updated to TB 8.0.9) but not in a very helpful manner which most users would immediately understand. So if a warning can be coded safely (health checks can in themselves possibly be exploited by the bad guys), this would be worth doing, because we certainly don't want to be caught out if it happens again.

This incident could have had a much more dire impact in the real world if it had happened just before May Day instead of just after May Day.

Looking ahead to the upcoming Tiananmen Square anniversary we should all try to make sure we know how to spot such problems if they arise again. A popup could help a lot if it can be done safely.

Jonny D. (not verified) said:

May 18, 2019

Permalink

Half the add-ons in my regular Firefox have been disabled. Besides 1 UI add-on, all of those disabled relate to security and privacy (disconnect, privacybadger, .. ), everything else is fine.

Solution? Mozilla wants me to install an add-on they made, which at this point I wonder if I can trust. And some people report it does not even fix the problem.
The alternative? Install the newest Firefox.

So Mozilla doesn't really provide a fix. They just force you to update your browser?
What awaits me in the code of that software? These past years forced updates always had "something bad attached".

I started up an old Firefox version, which somehow was still on my hdd: same add-ons, but no problems there. Interesting, all add-ons working fine, if your version is old enough. So the cause was introduced recently?

Well, I guess TorBrowser is going to see even more use from me. Though incidents like this make me wonder, who we can trust. Or more to the point: can you trust the people you trust, to trust the right people. Not removing this Firefox anti-feature for TorBrowser, was a clear sign of blind "if it's for good reason, it must be ok" trust.