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

NEW
Assigned to

Status

()

Toolkit
Add-ons Manager
7 years ago
6 months ago

People

(Reporter: mossop, Assigned: dveditz)

Tracking

({sec-want})

Trunk
sec-want
Points:
---

Firefox Tracking Flags

(blocking2.0 -, status2.0 wontfix, status1.9.2 wanted, status1.9.1 wontfix)

Details

(Whiteboard: [sg:want p1][wanted fx5])

(Reporter)

Description

7 years ago
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.
(Assignee)

Comment 1

7 years ago
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.
blocking2.0: --- → ?
status1.9.1: --- → wontfix
status1.9.2: --- → wanted
status2.0: --- → wanted
Whiteboard: [sg:want p1]

Comment 2

7 years ago
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).
(Reporter)

Comment 3

7 years ago
(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)
(Reporter)

Updated

7 years ago
Whiteboard: [sg:want p1] → [sg:want p1][wanted fx5]

Comment 4

7 years ago
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

7 years ago
(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

7 years ago
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.
(Assignee)

Updated

7 years ago
Assignee: nobody → dveditz
(Assignee)

Comment 7

7 years ago
Missed Macaw, minus.
blocking2.0: ? → -
status2.0: wanted → wontfix
(Assignee)

Updated

6 years ago
Keywords: sec-want
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.
tl;dr for comment 8: I suggest WONTFIX.
You need to log in before you can comment on or make changes to this bug.