I think focusing on the trusted root store as a way to resolve this problem is (or will be) less than ideal. I understand the desire to look there but I don't think it will necessarily end well.
That said I don't have a great alternative myself but I do have some questions: 1) I saw a quote attributed to Richard that Mozilla will blacklist or is considering blacklisting the cert(s) generated by Superfish, Komodia, and so forth. Can you comment here at all, Richard? 2) Has any analysis been performed on the "quality" of the end certs generated by the Komodia proxy? Are there obvious oversights that could be checked or enforced within Mozilla? How much work would that involve? 3) Am I right to presume that affected users did not notice that those sites with EV certs no longer were showing a green address bar? that EV itself provided no protection in this situation? 4) In this situation any sites using HSTS provided no additional benefit but did cert pinning make a difference? Thanks. Original Message From: Brian Smith Sent: Tuesday, February 24, 2015 12:05 PM To: Daniel Veditz Cc: Matt Palmer; [email protected] Subject: Re: Tightening up after the Lenovo and Comodo MITM certificates. Daniel Veditz <[email protected]> wrote: > 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. mozilla::pkix makes it so that you can ignore the NSS profile database, if you wish to do so. > 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? This is effectively what the built-in roots module already does, except the Mozilla root CA certificate is implied instead of explicit. > I thought pkix gave us those kinds of abilities. mozilla::pkix offers a lot of flexibility in terms of how certificate trust is determined. > 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. Those spam and DoS attacks are why logs are specified (required? recommended?) to not accept those certificates. If Mozilla wanted to, it is totally possible to make an extension API that allows an extension, when it is not disabled, to provide PSM with a list of roots that should be accepted as trust anchors. And, it is totally possible for PSM to aggregate those lists of extension-provided trust anchors and use that list, in conjunction with the read-only built-in roots module, to determine certificate trust, while ignoring the read/write profile certificate database. Whether or not that is a good idea is not for me to decide. But, it would not be a huge amount of work to implement. Cheers, Brian _______________________________________________ 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
