Follow

What really doesn't make sense about the expired cert is that it disables extensions that were already installed and in use.

Imagine if an apt signing key expired, and so it deleted every package on your system and killed all the processes.

Why would they design it to fail this way?

All I can guess is this triggered code that was supposed to run when a single extension is found to be malicious and so its signature would be revoked and you'd want it to disable it.

And they didn't consider that a cert failure higher in the chain would do this.

@joeyh by my guess, in case an extension went rogue

@ivesen @joeyh That might possibly make sense on certificate *revocation*. It shouldn't happen just on certificate *expiry*, especially not when the certificate that expired is upstream in the chain, not associated with the extension in particular.

@joeyh That seems to be about the shape of it: check the signatures on extensions regularly to allow revocation, and as it turns out if something higher in that chain is invalid, the signature is invalid. (This isn't necessarily *bad*, as you might have good reason to revoke an intermediate cert as well, but obviously in this case it didn't go as one might like.)

@joeyh
My guess is so that a malicious virus/trojan-installed extension would not load successfully. e.g. a virus could install an extension in Firefox to keep reinstalling the virus, or to let it rum traffic through FF's process to evade antivirus, etcetera. If certs were only checked at install-time then a manual install could bypass cert checks. Being checked at runtime guarantees that what runs is what's trusted.

@joeyh I think it was intermediate certificate, so everytime the extension runs, or maybe everytime firefox starts, it checks the signatures of all extensions against their certificate. But since the respective certificates are signed by this intermediate certificate, the signature is only valid when all certs in the chain are valid. That's my guess. Why didn't they have any expiration warning or why this exact problem wasn't addressed when it happened 3 years ago, that's mystery

@joeyh I was wondering what that message was about... it didn't actually stop any of my extensions though... weird.

@joeyh In theory, they COULD say that the system is designed to remove and inactivate anything with a bad key (including expired keys) to prevent the installation and activation of bad extensions. It's a stretch, but a possibility.

@joeyh @mattskala

What it's trying to guard against is malicious downloads that do ad-hijacking and so on. A guy unwittingly clicks a bad link, which installs a malicious plugin.

Mozilla is not in control during that installation, so only option is to kill it as you start mozilla and load plugins.

blog.mozilla.org/addons/2015/0

@youzicha @joeyh It's much harder to make a case for *expiry* of the signatures after they have been accepted; and it doesn't in fact check for expiry on every startup, only at 24-hour intervals - so the damage would already be done by a malicious plugin installed offline while the browser wasn't running.

@mattskala @joeyh

Installation as FF wasn't running is what this is trying to fix.

For a malicious plugin, it's not that a sig was first "okay", it's that FF didn't look at that sig at all until its 24-hour tidying up. So that plugin can show bad ads for a day or so, but FF sig validation will kill it.

@youzicha @joeyh If a malicious plugin can ever run at all, you're hosed; they are arbitrarily powerful. So, since you cannot guard against offline malicious installation. The best you can do is - as FireFox already does with certificates of Web sites - remember whether you have accepted a plugin in the past. And then, if you have, don't suddenly break it. Your record of that can be tampered with offline, of course, but you cannot prevent offline tampering anyway.

@youzicha @joeyh And, don't forget, the issue is not *checking* the signature, but *expiring* a previously accepted signature.

@mattskala @joeyh

I think it did work, in that it got rid of most malicious plugins. (Which was a big worry until introduction of this sig validation.)

Obviously it's not foolproof, but this way a malicious program must patch FF binary to avoid validation, it can't piggyback on normal plugin installation.

As I said, FF can't know if sig was okay'd or not, a malicious plugin install could falsify any log of prior validation. That's why it looks at sigs again and again.

@youzicha @joeyh But, again, it can only really do this at the moment of installation. The log can be falsified and so can the root certificates used for checking signatures. There is *no* security the browser can enforce against an entity that alters the browser's own security data offline.

@joeyh yes, seems like a Microsoft mindset "we know better than the ignorant user, let's control access to extensions" vs. a Linux mindset would have been "warning: your certificate expired D)elete extension k)eep extension."

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!