643461 - Do more strict certificate checks for add-on updates from AMO

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

Similar to the checks added for the AUS checks in bug 544442 we should verify that the AMO cert matches what we expect before allowing an update.

Comment 1

[Daniel Veditz [:dveditz]]

We need to land this in a 4.0 update if at all possible, we're only as safe as our weakest daily update check.

Definitely wontfix for 3.5 (die! die! die!); I'll put "wanted" on 1.9.2 since we have so many users there but it's probably not realistic to expect it.

Comment 2

[Ben Bucksch (:BenB)]

Ideally, we should also cover addon (first-time) installs.

Anything that protects binaries shouldn't rely (or be intercepted by) on DV certs (or in fact any third-party CA at all IMHO).

Comment 3

[Dave Townsend [:mossop]]

(In reply to comment #2)
> Ideally, we should also cover addon (first-time) installs.
> 
> Anything that protects binaries shouldn't rely (or be intercepted by) on DV
> certs (or in fact any third-party CA at all IMHO).

We don't even restrict add-on installs to coming from a secure server at the moment, I'm not sure if we want to do that but if we do it should be a separate bug (probably bug 429319)

Comment 4

[Ben Bucksch (:BenB)]

I'm just saying that if the install comes from *.mozilla.org (or: our whitelist in prefs), we should mandate *at least* EV and a certain CA (better yet a signature from us).

Comment 5

[Ben Bucksch (:BenB)]

(Given that we hook up this site in the browser UI, and lead users there, and thus most users install from there only.)

Comment 6

[Ben Bucksch (:BenB)]

I filed bug 644403, because it seems like you want to deal with this separately. I don't know if there's opportunity to share implementation.

Comment 7

[Daniel Veditz [:dveditz]]

Missed Macaw, minus.

Comment 8

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

I do not see why we would ever do this. We have already created a good model for secure updates for packaged web apps, which uses Mozilla-signed JAR files with version rollback protection, which are restricted to a Mozilla-owned-and-operated root, with keys protected by HSMs and other precautions. That should overall be much safer than relying on TLS for integrity. It makes a lot more sense for us to convert (AMO-based) addon install/update to the Firefox Marketplace signed JAR model than it does to do this or other things that we're not doing for (Firefox Marketplace-hosted) packaged apps.

In addition, we should support security updates of extensions even when the user is using a (corporate or local anti-virus) MitM proxy. This alone makes any TLS certificate checks a non-starter as the basis of a secure extension installation mechanism.

Comment 9

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

tl;dr for comment 8: I suggest WONTFIX.