Live data from Hacker News

All extensions disabled due to expiration of intermediate signing cert

bugzilla.mozilla.org

81–90 of 955 posts

Re: All extensions disabled due to expiration of intermediate signing cert

#81
post #2

Looks like all extensions have been disabled for all Firefox users. I think this fail-closed behavior is more of a security issue than the one it is trying to solve. All of my security add-ons - Privacy Badger, NoScript, Decentraleyes, and many more were disabled. Even worse, it happened without notice to the user. One moment I was browsing the internet (just barely) secured by these add-ons, and the next moment, all…

A warning yellow bar appeared for me below the URL bar.

Re: All extensions disabled due to expiration of intermediate signing cert

#82
Still working for me in my main profile in Firefox 60.6.1esr. I could even install an update to HTTPS Everywhere!

When I opened my alt profile, extensions still worked, but I can't install updates—including for HTTPS Everywhere.

What's up with that?

Re: All extensions disabled due to expiration of intermediate signing cert

#83

My extensions are still running. I even restarted Firefox a few moments ago. So it’s not everyone?

My extensions are also still running. Comments on the bugzilla bug restricted so adding details here and figuring that if this is useful someone can forward it to the right people

    $ date
    Fri May  3 22:45:22 EDT 2019

    $ date --utc
    Sat May  4 02:41:47 UTC 2019

    $ firefox --version # Installed from arch repositories
    Mozilla Firefox 66.0.3
about:config

    xpi.signatures.required true
    app.update.lastUpdateTime.xpi-signature-verification 1556920447
    extension.update.enabled true
1556920447 is unix timestamp Fri May 3 21:54:07 UTC 2019.

Edit: I think I know why. It checks the signatures daily, and the timing works out so it hasn't checked since the cert expired for me. Just luck, it will break within the next 21 hours for everyone. From the source code:

    const XPI_SIGNATURE_CHECK_PERIOD      = 24 * 60 * 60;

    [...]

    timerManager.registerTimer("xpi-signature-verification", () => {
      XPIDatabase.verifySignatures();
    }, XPI_SIGNATURE_CHECK_PERIOD);

Re: All extensions disabled due to expiration of intermediate signing cert

#84
post #75

I'm a bit confused. I thought that the way signing works in general is that the signer issues a certificate for the thing being signed (domain, code, whatever) that contains identifying information for the thing signed (host name for an SSL certificate, checksum of the code for a code signing certificate), the valid from and valid to dates of that certificate, and assorted other information, and either a reference to…

If a signing certificate expires and is stolen, it can backdate signatures. On the theory that expiration is useful because either people keep poorer track of key material over time or algorithms get weaker over time (which is not an unassailable theory, but it's a coherent model), you want expiration to prevent future use just as if it were revocation. Because you can't trust the date of a possibly-forged signature, you have to check the current date.

The model you're suggesting is closer to the "timestamping" one commonly used in code signing (IIRC Windows and Mac both do this) where a third party that's particularly trusted to handle key material well long-term gives you a second signature over the message "I saw this signature at this time" (effectively they are analogous to a notary or witness for real-world signatures). Then you can trust that signatures from expired signing certs were actually made in the past, and not by an attacker who got hold of the key. That is, without timestamping you have no proof of #5 in your list.

(I suppose you could do this now for the SSL PKI with Certificate Transparency logs.... it isn't exactly what they were built for but it's probably sound.)

Re: All extensions disabled due to expiration of intermediate signing cert

#85
post #25
post #12

I’ll still keep using Firefox since I recognize the importance of browser diversity and the hazards of a Chrome monoculture (that and vertical tabs), but, yikes. Still, this type of oversight seems all too common even in large companies. I remember several cases from Fortune 500 companies in the past few years alone. What would be a good way to automate checking for them? Has anyone developed a tool designed specific…

ACME / Let's Encrypt go in the direction of making expiry happen so often that renewal gets automated, rather than a being a rare manual process that can be forgotten about. Not sure that's viable for a signing certificate like this, but that's the way to solve it for the web PKI.

This is just abusive to the vast majority of users who do not care but still want to use SSL for their servers, frankly. I should be allowed to choose a near unlimited lifetime for my server's certificate if I don't care about the risks that may present.

Re: All extensions disabled due to expiration of intermediate signing cert

#87
post #78

Newbie question: why can't they just renew the certificate, like in 5 minutes?

They would have to reissue the intermediate certificate, as well as all dependent certificates.

And there are often bootstrapping problems where e.g. the push that distributes the new intermediate cert to clients is rejected because of the same expiry issue.

Re: All extensions disabled due to expiration of intermediate signing cert

#89
post #66
post #12

I’ll still keep using Firefox since I recognize the importance of browser diversity and the hazards of a Chrome monoculture (that and vertical tabs), but, yikes. Still, this type of oversight seems all too common even in large companies. I remember several cases from Fortune 500 companies in the past few years alone. What would be a good way to automate checking for them? Has anyone developed a tool designed specific…

> Still, this type of oversight seems all too common even in large companies. (...) Has anyone developed a tool designed specifically to avoid certificate expiry disasters? LetsEncrypt renewal is supposed to be automated. [1] I know of a company that hosted blogs for thousands of customers. They used LetsEncrypt, but the CTO considered automatic renewals a possible security risk, so they did it manually. Problem is,…

So did they conclude it wasn’t a security concern or did they conclude the security risk was worth the uptime?
Post reply on HN