Live data from Hacker News

Technical Details on the Recent Firefox Add-On Outage

hacks.mozilla.org

31–40 of 279 posts

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

#31

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…

Before reaching out to words like "abuse" for what is ultimately a hotfix, perhaps you should read the article. In particular:

> Second, we need a mechanism to be able to quickly push updates to our users even when — especially when — everything else is down. It was great that we are able to use the Studies system, but it was also an imperfect tool that we pressed into service, and that had some undesirable side effects. In particular, we know that many users have auto-updates enabled but would prefer not to participate in Studies and that’s a reasonable preference (true story: I had it off as well!) but at the same time we need to be able to push updates to our users; whatever the internal technical mechanisms, users should be able to opt-in to updates (including hot-fixes) but opt out of everything else.

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

#32
post #11

Looks like a good read. I haven't finished reading it yet, but there's something I still don't get ... Windows and macOS both have a signing infrastructure for apps. The rules of that infrastructure dictate only that apps must have been signed by a valid certificate at the time they were signed. That way old app downloads don't need to be periodically re-signed just to account for expiring certificates. I can downloa…

For the time stamp method to work, you need a trusted mechanism to attest that the timestamp is correct, otherwise the mechanism is useless (an attacker with an outdated private key can just backdate the timestamp in the executable and then sign it). Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same.

I’m not saying they shouldn’t, but it is a significant piece of complexity.

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

#33
post #14
post #7

Earlier quoted context omitted.

It's clearly just a disclaimer to show his respectful intent, since the paragraphs following that are addressing failures of his colleagues.

Understood, and I explained a bit more of my thoughts in another comment. I understand I'm being a bit pedantic. But, as a user who is pretty concerned with a CA having a certificate issue of this scale, which affected this many people, I don't care about the authors respectful intent to their colleagues. Tell them in person, in an internal memo, whatever. It's simply not a lesson learned.

Likewise, I'm sure he cares more about keeping good working relationships with his colleagues than about what the reader thinks of his choice of paragraph order. A manager who makes his team feel insulted is not conducive to producing better software (which is presumably what you care most about here).

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

#34
> For the other groups we are developing a patch to Firefox that will install the new certificate once people update. This was released as a “dot release” so people will get it — and probably have already — through the ordinary update channel. If you have a downstream build, you’ll need to wait for your build maintainer to update.

Why not link to the xpi that can be installed now?

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

#35

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 l…

Not sure if you want a browser that emphasis privacy and security, that you will also want to have remote code injections as a way to ship an update that affects the way add-ons security work.

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

#36

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.

I agree. And Mozilla somewhat addresses this in their second lessons learned:

> [...] we need a mechanism to be able to quickly push updates to our users even when — especially when — everything else is down. It was great that we are able to use the Studies system, but it was also an imperfect tool that we pressed into service, and that had some undesirable side effects. In particular, we know that many users have auto-updates enabled but would prefer not to participate in Studies and that’s a reasonable preference [...] but at the same time we need to be able to push updates to our users

Its a difficult situation to be in: Some users do not want any changes being applied automatically, but when something breaks, changes need to be applied. It sounds like the Firefox team is doing everything they can with respect to both ends of the spectrum.

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

#37
post #11

Looks like a good read. I haven't finished reading it yet, but there's something I still don't get ... Windows and macOS both have a signing infrastructure for apps. The rules of that infrastructure dictate only that apps must have been signed by a valid certificate at the time they were signed. That way old app downloads don't need to be periodically re-signed just to account for expiring certificates. I can downloa…

For the time stamp method to work, you need a trusted mechanism to attest that the timestamp is correct, otherwise the mechanism is useless (an attacker with an outdated private key can just backdate the timestamp in the executable and then sign it). Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same. I’m not saying they shouldn’t, but it is a significant piece of…

> Windows code signing uses a server Microsoft runs to provide this, and Mozilla would need to do the same.

Mozilla already requires uploading even your private extensions to a Mozilla server to be signed for internal or external deployment.

https://wiki.mozilla.org/Add-ons/Extension_Signing

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

#38
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.

I think you're perhaps mixing up the public key on the certificate and the signature on the certificate.

The signature is over the contents of the certificate, so the certificate cannot change without the signature changing.

The public key, though, is just part of the arbitrary information that the certificate is intended to secure. Much like multiple certificates can be issued with the same subject name (but varying other details), multiple certificates can be issued with the same public key.

For example, in the TLS context, you can produce an unlimited number of CSRs (certificate signing requests) off of the same private/public key pair used for TLS. It's a common practice to generate a new private/public key pair every time you generate a new CSR in order to mitigate potential compromise of the private key, but even that practice is becoming less common because changing the public key prevents pinning it using e.g. HSTS - today, some clients establish trust by verifying the public key against both the certificate and some other separate method (often TOFU). This is a separate practice used alsongside certificate verification intended to mitigate some of the security concerns around the certificate infrastructure.

In this case, as in Mozilla's case here, it is a practical requirement to issue a new certificate with the same public key, because clients expect the public key to remain constant for various reasons.

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

#39

> because they want to run old-style add-ons, but many of these now work with newer versions of Firefox. Except it wasn’t working for this few days. Anyway older versions of Firefox wasn’t signing add-on, so they are not concerned by this fix.

Wrong. I lost my addons in firefox 60 esr, which I got from debian. I'm done with mozilla disrespecting my preferences, and have switched to waterfox and icecat. Remote control of the browser is simply the last straw.

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

#40

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…

Before reaching out to words like "abuse" for what is ultimately a hotfix, perhaps you should read the article. In particular: > Second, we need a mechanism to be able to quickly push updates to our users even when — especially when — everything else is down. It was great that we are able to use the Studies system, but it was also an imperfect tool that we pressed into service, and that had some undesirable side effe…

I have read the article - and accusing users of not doing so is against the site guidelines here by the way.

Mozilla previously told us

> we have created a set of principles that we will always follow when shipping a SHIELD study to our users, and two principles are most relevant to this situation.

> A SHIELD study must be designed to answer a specific question.

What question did this hot fix answer? None. So what’s the point in the policy and promise if they’re doing to disregard it. It was supposed to be there to stop what went wrong last time. It’s like they disabled a safety put in after the last bad accident.

Post reply on HN