Live data from Hacker News

Technical Details on the Recent Firefox Add-On Outage

hacks.mozilla.org

21–30 of 279 posts

Re: Technical Details on the Recent Firefox Add-On Outage

#21

>An important feature here is that the new certificate has the same subject name and public key as the old certificate, so that its signature on the End-Entity certificate is valid. Shouldn't it be impossible to generate a new cert (with a different expiry date) that ends up having the same public key as an existing cert?

> Shouldn't it be impossible to generate a new cert (with a different expiry date) that ends up having the same public key as an existing cert?

If you have the secret key of the original certificate, you can use the same key material, and just use different meta data (like expiry date).

Re: Technical Details on the Recent Firefox Add-On Outage

#22

After the last PR disaster - the Mr Robot tie-in - one of the ways Mozilla tried to make it right was that they promised that the survey system would never again be used for something that was not an experiment. https://blog.mozilla.org/firefox/retrospective-looking-glass... > A SHIELD study must be designed to answer a specific question. Why have they abused it again here to deploy a hot fix, breaking their promise…

I think the reason was probably that the vast majority of Firefox users, if asked, would prefer that they did this. Not too many would say, "I am willing to participate in your study, but please don't fix my browser's add-ons if they all break". Sure, approval might not be 100%, but it would be something well north of 90%, and they probably took the right action.

Given, of course, that the truly right action of not letting the certificate expire in the first place, was no longer possible.

Re: Technical Details on the Recent Firefox Add-On Outage

#23
post #9

Earlier quoted context omitted.

No, one public/private key pair can be used to generate or sign as many certificates as you like, as often as you like.

No I'm not talking about the root, I mean they generated a new certificate (the intermediate) (with a new private key) that had a public key identical to an existing certificate -- you shouldn't be able to do this, public keys can't be "specified" afaik, they're derived from your private key and the signer's public key.

Isn't that the point of having the root cert and the intermediate? Otherwise, why not just have everything keyed to the root?

Re: Technical Details on the Recent Firefox Add-On Outage

#24
post #9

Earlier quoted context omitted.

No, one public/private key pair can be used to generate or sign as many certificates as you like, as often as you like.

No I'm not talking about the root, I mean they generated a new certificate (the intermediate) (with a new private key) that had a public key identical to an existing certificate -- you shouldn't be able to do this, public keys can't be "specified" afaik, they're derived from your private key and the signer's public key.

AFAIK the public and private keys of any keypair, like the intermediary, are always linked. You can not have a new public key with the same private key.

But you can always re-sign the same keypair from the root with a new, non-expired certificate. And since this keypair (the intermediary) signed all the individual add-ons to begin with, it will just magically work.

Remember that certificate is nothing but a message that is signed by some "higher" keypair, which says that some "lower" keypair is trusted.

Re: Technical Details on the Recent Firefox Add-On Outage

#25
post #9

Earlier quoted context omitted.

No, one public/private key pair can be used to generate or sign as many certificates as you like, as often as you like.

No I'm not talking about the root, I mean they generated a new certificate (the intermediate) (with a new private key) that had a public key identical to an existing certificate -- you shouldn't be able to do this, public keys can't be "specified" afaik, they're derived from your private key and the signer's public key.

The literal ascii blob of the signed key would be different, because (for example) the "Valid Until" date has changed — but they control the private keys for the signer and the intermediate, which means they can issue a certificate that is logically identical from an X.509 perspective other than fields that either time or randomness contribute to. (Serial number would not necessarily be randomized in this scenario.)

Re: Technical Details on the Recent Firefox Add-On Outage

#26
post #17

There is a related blog post about what Mozilla is doing with the data collected from users who enabled Studies in order to get the hot fix. https://blog.mozilla.org/blog/2019/05/09/what-we-do-when-thi... TL;DR is "In order to respect our users’ potential intentions as much as possible, based on our current set up, we will be deleting all of our source Telemetry and Studies data for our entire user population collect…

As someone who reluctantly re-enabled Studies to get the fix, I appreciate this.

Re: Technical Details on the Recent Firefox Add-On Outage

#27

After the last PR disaster - the Mr Robot tie-in - one of the ways Mozilla tried to make it right was that they promised that the survey system would never again be used for something that was not an experiment. https://blog.mozilla.org/firefox/retrospective-looking-glass... > A SHIELD study must be designed to answer a specific question. Why have they abused it again here to deploy a hot fix, breaking their promise…

I think using the system they used to provide a hotfix for a browser-breaking issue does not clash with the spirit of their prior pledge. I feel a complaint like this verges unhelpfully in to the pedantic.

Yeah I agree with you on this one. Especially because as another user posted earlier, they are going through and deleting all telemetry and usage statistics for their entire user base during the time period that this was needed to be enabled.

This seems like a very good compromise and is honestly more than they needed to do imo

https://blog.mozilla.org/blog/2019/05/09/what-we-do-when-thi...

Re: Technical Details on the Recent Firefox Add-On Outage

#28
> Second, we need a mechanism to be able to quickly push updates to our users even when — especially when — everything else is down.

They should simply streamline the "normal" updates for that purpose, not invent the new "channels."

Specifically, not all binaries in the directory should be changed just to push an update where only few lines of the code are different.

Re: Technical Details on the Recent Firefox Add-On Outage

#30

After the last PR disaster - the Mr Robot tie-in - one of the ways Mozilla tried to make it right was that they promised that the survey system would never again be used for something that was not an experiment. https://blog.mozilla.org/firefox/retrospective-looking-glass... > A SHIELD study must be designed to answer a specific question. Why have they abused it again here to deploy a hot fix, breaking their promise…

I think using the system they used to provide a hotfix for a browser-breaking issue does not clash with the spirit of their prior pledge. I feel a complaint like this verges unhelpfully in to the pedantic.

As someone who opted out of Studies after the last abuse, I felt betrayed that my addons were, effectively, held hostage behind enabling both telemetry and Studies. I decided to wait.

It’s bad optics at the very least. Users who opted in for the update were in fact entered into studies they explicitly wouldn’t have wanted to be in without the lure of an earlier update.

Post reply on HN