471672 - Require EV certificate for update sites and mechanism of Firefox, Thunderbird etc.

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Eddy Nigg (StartCom)]

Update sites should be secured by EV certificates and EV must be enforced by the application, otherwise update should fail. This is mainly due to bug 470897.

Comment 2

[Eddy Nigg (StartCom)]

Ben suggested to add the certificates public key to the update mechanism.

Comment 4

[Ben Bucksch (:BenB)]

Eddy, even though you were faster (and I think originally pointed out the problem, thanks for that!), I mark this one as dup of the other one, because:
- We must not depend on EV either, as that also has serious weaknesses and is not appropriate to a such high-risk operation as gaining full access to 150 million PCs.
- This one is filed against Server Operations. While the server certs would probably be changed for operational reasons, this is not strictly necessary, not the core part and will not be sufficient. The critical part is that the autoupdater does not accept *other* certs.
- I think I explain the issue and the steps needed better than this bug.

Comment 5

[matthew zeier [:mrz]]

Should the auto-updater only accept Mozilla signed certs?

Comment 6

[Ben Bucksch (:BenB)]

mrz, this is detailed in the other bug, including what happens with third-party extension authors.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

Whether Mozilla depends on a CA-issued EV cert or not is a policy question
for Mozilla to make.  Until that decision is made, this bug is not 
superseded by bug 471779.

Comment 8

[Eddy Nigg (StartCom)]

Concern has been raised in another bug that the update mechanism comprises of several different sub domains. Even though EV doesn't support wild cards, it allows for multiple domains and sub domains within the same certificate. Therefore this shouldn't present a problem. 

Additional note, EV must provide an OCSP responder for revocation (required only in 2010, but most CAs have that already), which will help to protect in case of key compromise.

Comment 9

[matthew zeier [:mrz]]

I'm not sure if this bug sits with IT just yet - comment #0 suggests app level changes first.  

Where's the right place for this bug?

Comment 10

[Wolf [:wolf]]

In Toolkit / App Update this bug is a duplicate of Bug 471779.. I suspect being about policy, it probably belongs in mozilla.org governance or something similar.

Comment 11

[Johnathan Nightingale [:johnath]]

(In reply to comment #9)
> I'm not sure if this bug sits with IT just yet - comment #0 suggests app level
> changes first.  
> 
> Where's the right place for this bug?

Bug 471779 is a mess, but I agree with mrz that this is not at all on IT's plate at the moment.

I agree with Nelson that this is a policy discussion, and if we're going to have a policy discussion about what certs are "validated enough" to serve updates, and how that should be enforced, it is not bug fodder. It's a newsgroup discussion, probably in dev.platform, not dev.tech.crypto.  I'd have things to say in that discussion, but I'll say them there (if and when) not here.

Should that policy discussion end with the conclusion that this is a good idea, the next step would be to figure out implementation in a bug which should almost certainly be right here in Toolkit->Application Update.  IFF that implementation has specific and well articulated IT requirements should they have to deal with it.

Comment 12

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

I strongly suggest we WONTFIX this. See bug 770594 comment 9 and bug 770594 comment 11. This does not actually help secure users because we need to be able to update Firefox through (corporate and/or local anti-virus) MitM proxies, which aren't (hopefully!) EV certs and which are basically worthless as far as ensuring the integrity of Firefox updates is concerned.

This is basically a solved problem on Windows because on Windows we use signed MARs for updates. Instead of doing what this bug suggests, we need need to extend the
MAR signing mechanism used on Windows to the other platforms, and then do the *exact opposite* of what this bug suggests: remove the extra checks of the update service SSL certificate that we already have in place--that is, fix bug 770594. (In fact, I would
like to avoid using SSL at all as part of updates, to reduce the number of
moving parts in the update process; e.g. to avoid bugs in our SSL
implementation affecting the ability of users to download Firefox.)

The reason this extra check would hurt security is that it would disallow (or delay) anybody using a corporate MitM proxy from updating Firefox while they are on that network. But, it is better to (securely) give people Firefox updates as fast as possible.

Comment 13

[Robert Strong (they/them - no direct email)]

Thanks bsmith and agreed.

dveditz, can I get you to weigh in on this as well? Thanks

Comment 14

[Robert Strong (they/them - no direct email)]

We will be using mar signing as the method to prevent exploits so resolving as wontfix