
Tor Browser disabled NoScript, but can't update - lichtenberger
https://lists.torproject.org/pipermail/tor-talk/2019-May/045116.html
======
Faark
> Turns out an unrelated 3rd party can suddenly remotely disable Tor anonymity
> protections at their whim

Am I the only one annoyed by people pushing this "they flicked a switch"
narrative? No. They provided shitty software that didn't work under certain
conditions (in this case date related) and thus broke your shitty software.

A third party having remote control capability is something entirely
different.

~~~
judge2020
If I'm not mistaken, then very well could revoke the intermediate certificate
if they wanted. This wasn't a case of that, but it seems it could happen.

~~~
crehn
Usually the whole certificate chain is distributed as a bundle, and most
software don't bother checking revocations.

~~~
tedunangst
Are we talking about Firefox extensions or something else?

~~~
crehn
Not sure of the Firefox implementation; just pointing out revocation isn't
necessarily straightforward.

~~~
tknkx
The way I understand it is: certificate revocation is handled by checking OCSP
servers, and OCSP servers can be programmed so they give different answers
depending on the IP address of whomever is asking. In other words, it should
be possible to disable all addons for a selected user by targeting him by IP
address.

~~~
crehn
Seems that Firefox skips revocation checks for CA certs [1].

[1]
[https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox](https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox)

~~~
marcinzm
Where does it say that? The link says they centrally manage revocations using
OneCRL and then push a single revocation list to browsers (independent of
browser updates). Which means they can revoke any certificate they want using
that mechanism.

~~~
crehn
Ah, you're correct. Seems they skip CA CRL/OCSP in favor of their own CRL.
Thanks for the correction.

------
Waterluvian
Somewhat related to this ongoing Mozilla plugin saga, are there any infamous
stories I should look up that involve huge mistakes leading to unfixable
clients? Ie. Imagine bricking your customer's devices with an irreversible
buggy update. In Mozilla's case they were able to deploy a hotfix for many,
and an update for others. But I imagine there's got to be some great stories
about completely bricking countless devices.

~~~
tgtweak
It's one of my favorite interview questions. I only know the answer because it
happened to us once with 5M users on the affected version before it was
discovered. It's a very good question to see how people react in a mostly
hopeless situation. The only candidate out of 100s to logically get to the
solution (or essentially it) was one of the best engineesr I've hired and
worked with.

"So you and your team just released a tested and reviewed build, did gradual
rollout and numbers looked good - so out to general public it goes. All
clients update over the following days. QA discovers, upon testing the next
release, a latent bug that prevents the current version from connecting to the
update service and running the updater. How do you resolve this?"

~~~
willj
I'm super interested to know the answer to this question. I imagine it's more
interesting than just uninstall/reinstall.

~~~
judge2020
As said in the other answer, hopefully the interviewee asks how it's unable to
connect. If it's an Oculus situation [0] where the signing certificate is
expired and you don't have a backdoor like Firefox studies, the only way is a
reinstall or a "fix utility" [1].

0:
[https://news.ycombinator.com/item?id=16541235](https://news.ycombinator.com/item?id=16541235)

1: [https://www.theverge.com/2018/3/8/17095414/oculus-rift-
softw...](https://www.theverge.com/2018/3/8/17095414/oculus-rift-software-fix-
certificate-expiry)

------
deogeo
If Mozilla hadn't locked down Firefox so much, the fix could have been as
simple as going into about:config and flipping a switch to allow unsigned
plugins.

~~~
javagram
FWIW, since the original intent of the change to block unsigned plugins was to
prevent third party software installers from adding malicious plugins without
user consent, leaving a preference to toggle it back would have been pretty
pointless as the third party installers could have just toggled the preference
themselves (about:config is just some sort of easily modifiable data format on
disk).

TBH it’s not hard for me to think of ways Mozilla could have preserved user
control even in the face of these constraints though. For instance, I already
use a master password to encrypt/decrypt the password database in Firefox. Why
not allow the master password to also protect the settings and store them
encrypted so a third party can’t modify them?

~~~
rightbyte
If the malicious plugin or executable can write to disk it's probably to late
anyway?

~~~
EvilTerran
The malicious code may well have the necessary permissions to write to the
profile folder, but not to modify the executable.

Under the Unix security model, for example, that would be pretty likely: your
profile's owned by your account, the executable & its containing folder are
owned by root & go-w, so code running as you can tamper with the former but
not the latter.

~~~
pdkl95
The malicious code can simply write an executable somewhere in the profile (or
/tmp, or anywhere). It is _highly unlikely_ that the profile (usually in
/home/${USER}/) is on a filesystem mounted with the "noexec" flag.

Or just inject code the browser at runtime.

Under the Unix security model, the UID is the permission boundary. Even if the
binary is owned by root, it inherits the user's UID when they run it.

~~~
EvilTerran
Well, true, but all this is _a lot_ more conspicuously fishy than "flip a
setting that the user might have legitimately flipped themselves". You're not
going to get far hiding a whole new Firefox install in $HOME before someone
asks why theirs suddenly got 200MB bigger, for one thing.

------
d0bby
> Turns out an unrelated 3rd party can suddenly remotely disable Tor anonymity
> protections at their whim, and possibly endanger TBB users (or deliberately
> help in deanonymizing them).

> remotely disable Tor anonymity protections [!]

Maybe a 'certificate is expiring soon' warning on the browser side?

Users would know and Mozilla would be forced to keep certs valid.

------
AnaniasAnanas
One of the weird things here is that javascript is not disabled by default in
the Tor Browser and instead an addon is needed.

This whole thing is also yet another reason to use something like Tails or
Whonix which are much safer to use with JS enabled.

~~~
oil25
It is a valid trade-off to leave Javascript enabled by default in Tor Browser.
The reason being, the experience is much more user-friendly to a layperson and
thus results in greater network usage and diversity. "Safe" is a relative
concept in information security and not everyone has the same goals or risks -
though in principle I agree disabling JS greatly hardens a browser.

------
swiley
I remember saying over and over again that using Firefox for the TOR browser
was a horrible idea.

Use curl -H "" and links --dump. Until we have something sane that's really
the only safe way to browse TOR if you actually have something to hide.

(There's dillo and other things like the absolutely horrifying browser I've
been writing but that hardly even supports forms right now heh. but I'm
worried about connecting stuff like that to stuff like TOR)

~~~
dontbenebby
OTOH the more people who use Tor, the more anonymous everyone on the network
is, so having a usable version is important.

[https://www.freehaven.net/anonbib/cache/usability:weis2006.p...](https://www.freehaven.net/anonbib/cache/usability:weis2006.pdf)

People with heightened privacy concerns can always use Whonix or Tails
instead.

~~~
swiley
curl is good enough for fetching RSS, leaving that running would probably help
quite a lot.

------
johnnydoe9
Every single one of my Firefox extensions stopped working with an error
message that says "could not be verified for use in Firefox and has been
disabled" re-downloading doesn't work either. I'm assuming it's happening to
everyone?

~~~
cf498
yes [https://blog.mozilla.org/addons/2019/05/04/update-
regarding-...](https://blog.mozilla.org/addons/2019/05/04/update-regarding-
add-ons-in-firefox/)

------
Causality1
I can't improve upon this comment:

"Hey Mozilla - this is why people said that forcing addons to be signed with
no way to disable was a bad idea. You didn't even make it a year without
screwing it up.

Who could have seen this coming? Oh wait, pretty much everyone who argued
against this policy."

~~~
Jonnax
It's a dumb comment. There was a ton of malware being distributed as add-ons
that came packaged with other installers.

This solved that issue.

~~~
antt
Burning down London stopped the plague too.

~~~
floatingatoll
The Great Fire burned central London long after the plague had moved to the
poorer outer areas of the city, where it continued to die out gradually
unaffected by the fires elsewhere.

------
krick
How Firefox came to be _like that_? Which browser should I use _now_?

