On Mon, Feb 23, 2015 at 5:28 PM, Matt Palmer <[email protected]> wrote:
> On Mon, Feb 23, 2015 at 02:14:13PM -0800, Clint Wilson wrote: > > Lots of Enterprises and organizations have very legitimate requirements > to > > add their own internal root CA to the NSS store. > > I suspect John's point is that lots of enterprises and organisations (I > remember a time when those were the same thing...) have very legitimate > requirements to add their own internal add-ons to Firefox, and he is simply > calling out an apparent inconsistency in Mozilla's policies on these two > object types. (John, if I'm misrepresenting your position, please feel > free > to correct me). > If I understand correctly (dveditz CC'ed to correct me), the current add-on signing tool has a provision for signing add-ons that are not published through AMO. They still need to be submitted to AMO to be scanned and signed, but they're not published. > However, the two situations aren't the same, and thus can't be compared so > simplistically. Mozilla's signature on an add-on says, "we're reasonably > sure this add-on isn't going to do Bad Things to your browser", because > they > can wave automated scanning tools over the code to look for dodgy stuff. > > The closest thing I can think of for CA certificates would be if Mozilla > OK'd only technically-constrained CA certs -- say, only for domains and IP > ranges which the applicant was known to own. However, that is exactly the > sort of thing that existing trusted root CAs do. I suspect that existing > trusted root CAs would be unhappy if Mozilla took on this task. It would > also be a significant cost to Mozilla, because determining authority to > issue certs for an entire portion of the DNS space is a lot more manual > effort than running a code analysis tool over an add-on. > I think the benefit here would be more transparency than quality. If we only allowed changes to the root store by signed add-ons, then (1) Mozilla would at least have internal visibility into all the MitM roots being deployed, and (2) we could use the add-on blacklist facility to block things like Superfish once they were detected. These both seem beneficial in terms of mitigating risk due to MitM. However, it could be challenging to implement this control. In addition to the in-browser UI for adding roots (which could easily be disabled), certs can also be added to the NSS databases directly, even while the browser isn't active. To counter this risk, we would have to periodically snapshot the database and check that nothing else had changed it. I'm not sure the incremental benefit merits the level of development required. Nonetheless, if we can reinforce the idea that addons are the way to install roots by simply turning off the UI that exists, that could be beneficial. (Also, this is more of a Firefox discussion than a CA program discussion, so it might be more appropriate for dev.tech.crypto.) --Richard > - Matt > > -- > "The user-friendly computer is a red herring. The user-friendliness of a > book just makes it easier to turn pages. There's nothing user-friendly > about > learning to read." > -- Alan Kay > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
