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.
Ben suggested to add the certificates public key to the update mechanism.
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 471779
Should the auto-updater only accept Mozilla signed certs?
mrz, this is detailed in the other bug, including what happens with third-party extension authors.
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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.
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?
Assignee: server-ops → nobody
Component: Server Operations → Application Update
Product: mozilla.org → Toolkit
QA Contact: mrz → application.update
Version: other → Trunk
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.
(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.
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.
Thanks bsmith and agreed. dveditz, can I get you to weigh in on this as well? Thanks
We will be using mar signing as the method to prevent exploits so resolving as wontfix
Status: NEW → RESOLVED
Last Resolved: 9 years ago → 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.