683175 - Pin CAs for addons.mozilla.org

Status: RESOLVED DUPLICATE of bug 1019772

(NSS :: CA Certificates Code, task)

Description

[LegNeato]

addons.mozilla.org has been the subject of fraudulent cert generation recently. While we investigate if we should pin CAs for 3rd party certs (and if so which 3rd parties) at the very least we should handle addons.mozilla.org (and maybe AUS?)

Not sure if this bug belongs in this component, please move if not.

Comment 1

[LegNeato]

....and we already do this for updates (thanks johnath, thought dveditz mentioned that earlier) and it doesn't make sense to do it for the website really (no PII on AMO). Closing the bug as invalid.

Comment 2

[Boris Zbarsky [:bzbarsky]]

We do this for updates, but do we do it for initial extension installs?

Comment 3

[Michael Coates [:mcoates] (acct no longer active)]

I still see value in pinning and think we should consider this even though we have additional controls for updates.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

My opinion is that we should decide on a (very small) set of CAs to use for *.mozilla.*, and pin *.mozilla.* to those CAs. We can do this as a trial of whatever certificate pinning mechaism we want to offer to other websites.

Comment 5

[Brendan Eich [:brendan]]

Do we pin AUS cert(s) now, already?

/be

Comment 6

[Reed Loden [:reed]]

(In reply to Brendan Eich [:brendan] from comment #5)
> Do we pin AUS cert(s) now, already?

Not to the extent that Google does pinning (actual fingerprints), but we do "pin" two particular CAs as the only ones whose certificates are accepted for AUS.

Specifically, here are the prefs from firefox.js:

pref("app.update.certs.1.issuerName", "OU=Equifax Secure Certificate Authority,O=Equifax,C=US");
pref("app.update.certs.1.commonName", "aus3.mozilla.org");

pref("app.update.certs.2.issuerName", "CN=Thawte SSL CA,O=\"Thawte, Inc.\",C=US");
pref("app.update.certs.2.commonName", "aus3.mozilla.org");

See bug 544442 for more information.

Comment 7

[Dave Townsend [:mossop]]

Currently add-on updates from AMO aren't secured in any way beyond normal SSL. Bug 643461 covers adding more strict certificate checks for add-on updates, basically the same kind of checks we added for app update. That wouldn't cover add-on installs though.

Comment 8

[Reed Loden [:reed]]

(In reply to Dave Townsend (:Mossop) from comment #7)
> Currently add-on updates from AMO aren't secured in any way beyond normal
> SSL. Bug 643461 covers adding more strict certificate checks for add-on
> updates, basically the same kind of checks we added for app update. That
> wouldn't cover add-on installs though.

Bug 644403 covers add-on installs.

Comment 9

[Robert Kaiser]

(In reply to Reed Loden [:reed] (very busy) from comment #6)
> pref("app.update.certs.1.issuerName", "OU=Equifax Secure Certificate
> Authority,O=Equifax,C=US");

Note that we will need to do something there anyhow, as this root is not used any more for issuing new certificates. SeaMonkey just came across that recently and I think Callek hasn't filed a followup bug for Firefox yet to add another one (like GeoTrust, which is the "replacement" root for the Equifax one) to preserve redundancy.