Hacker News Reader

Comment by electrotype | Hacker News Reader

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

A new certificate can be generated if you have to in a couple of minutes, sure. Of course, you probably defined some procedures to do it properly and securely that require more time.

Then the issue becomes: how to get the new certificate to a few hundreds million users?

If it was a certificate on some server, just replace it there, done. Client software will just pick it up. But not here. A copy of the certificate is shipped in every add-on package file. Oops. Now you have to re-sign all add-ons with the new certificate. And get those resigned files to the users.

Essentially it works like this (which is a slightly modified jar/apk signing mechanism):

- An add-on package is a zip file and other than the actual files there is also a list of known-good hashes of those files in a file called "manifest.mf" in the META-INF folder

- Then there is a file "META-INF/mozilla.sf" giving hashes of "manifest.sf"

- And finally, there is "META-INF/mozilla.rsa", which is a DER-encoded pkcs7 signature and two certificates. The signature verifies "mozilla.sf" was not tampered with and still is the same as when it was signed by mozilla. Which in turn verifies the known-good hashes are still proper.

- The signature is made with a generated certificate, the first one included in "mozilla.rsa". E.g. "CN=uBlock0@raymondhill.net" in case of uBlock.

- The "CN=uBlock0@raymondhill.net" certificate was issued by an intermediate certificate "CN=signingca1.addons.mozilla.org". This "CN=signingca1.addons.mozilla.org" is the second certificate in mozilla.rsa. It says "Validity Not After : May 4 00:09:46 2019 GMT". Oops. This is where the chain breaks now!

- "CN:signingca1.addons.mozilla.org" was issued by "CN=root-ca-production-amo". This root certificate is baked straight into the browser and not part of mozilla.rsa.

Therefore, it is not enough to issue another intermediate certificate (e.g. "CN=signingca-number-two.addons.mozilla.org"), but you have to actually generate a new "CN=uBlock0@raymondhill.net" (or whatever) signed by this new certificate, put those two certificates and a new signature of "mozilla.sf" based on those new certificates into a new mozilla.rsa FOR EACH add-on and ship updated add-on files.

PS:

Try it yourself... Extract some addon package (it's a zip file). Then:

    openssl pkcs7 -in META-INF/mozilla.rsa -inform DER -print

The root certificate is also part of the mozilla.rsa. Addons have it included, it can be extracted and then imported into the browser Certificates > Authorities and it will be used to validate addons, including those which are not updated.

A sample procedure doing exactly this, and a fix for Firefox <= 56.0.2 can be found here: https://www.velvetbug.com/benb/icfix/

The same procedure can be used on newer versions, but the syntax is a bit different (import cert, go to about:addons, open console):

  Components.utils.import("resource://gre/modules/addons/XPIDatabase.jsm");
  XPIDatabase.verifySignatures();

This only makes sense if you really need to fix it while the browser is running, otherwise you can simply restart it after the new certificate is imported.

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.

Reply on news.ycombinator.com