On 2/23/15 3:55 PM, Richard Barnes wrote: > 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.
Yes. > 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. I don't think we can restrict it to add-ons since external programs like Superfish (and the Lenovo removal tool, for that matter) write directly into the NSS profile database. It would be a bunch of work for precisely zero win. Could we make the "real" and only root accepted by Firefox be a Mozilla root, which cross-signs all the built-in NSS roots as well as any corporate roots submitted via this kind of program? I thought pkix gave us those kinds of abilities. Or we could reject any added root that wasn't logged in CT, and then put a scanner on the logs looking for self-signed CA=true certs. Of course that puts the logs in the crosshairs for spam and DOS attacks. > 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. We have this problem with add-ons which can also be added directly while Firefox isn't running. Where do you store the snapshot such that the injector can't just tweak it while injecting? > 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. Would it? I haven't heard of any widespread problems with people fooling others into installing a root via the UI. Meanwhile it would do zero to stop the actual way unwanted roots get added. > (Also, this is more of a Firefox discussion than a CA program discussion, > so it might be more appropriate for dev.tech.crypto.) It's not a technical crypto issue either; I suggest something more general like dev-security or dev-firefox. -Dan Veditz _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
