RE: Tightening up after the Lenovo and Comodo MITM certificates.
With the vast number of private PKIs created by the CA service included in Windows Server, the enterprise market tends to rely on Active Directory-based distribution within the forests it controls. This leads to an IE mandate, within a network that the owner/operator of the PKI controls. When a private PKI attempts to cross outside its territory and unconsciously or subconsciously affect individuals through modification of how a browser operates, that crosses a line into warranting browser enforcement of constraint on what that PKI can do because it is no longer private once it reaches beyond its arm. This is what this discussion has mainly touched so far, and I don't contest that one bit, rather I'm interested in the opportunity in this situation. Poles defined, that leaves the grey area. Mozilla policy might wish to encourage and enable distribution of enterprise roots with the simplicity of AD group policy push. This supports an enterprise alternative, however it isn't easy to draw the boundary when you don't have a central repository that distinguishes a target device as subscribed to the enterprise network or not. Certainly there is plenty of genius among the dev community to overcome that with something more flexible than name constraints that become huge for large companies and change with every acquisition or brand launch requiring re-issuance. The problem needs dynamic data because the corporate name space is not static. Create membership in and enrollment to the influence of a private PKI not only from an end user pull but also a central corporate authority push and we solve the realm of authority issue. PrivDog and Superfish affect beyond their realm. OK, so create realm. Create a market for scoped buy in where the systems touched and people affected are wholly within the authority of the PKI injected into their browser. When the scope of interception is within a network that the PKI owner controls and the humans on that network are subject to its policy of interception as a condition of employment and they agree by remaining employed, then the interception is a controlled implementation of policy across an owned private scope. Even in the case where consent is not very conscious, attempts to suppress entirely rather than scope private-root-based interception will result in IE mandates. The root can be GPO-pushed silently, and either the proxy servers or the desktop management software can disable non-IE use. Kind regards, Steven Medin Product Manager, Identity and Access Management Verizon Enterprise Solutions -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+steve.medin=verizonbusiness@lists.mo zilla.org] On Behalf Of Clint Wilson Sent: Monday, February 23, 2015 5:14 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Tightening up after the Lenovo and Comodo MITM certificates. Lots of Enterprises and organizations have very legitimate requirements to add their own internal root CA to the NSS store. In fact, Mozilla even answers the question of how to do this: https://wiki.mozilla.org/CA:FAQ#How_do_I_import_a_root_cert_into_NSS_on_our_ organization.27s_internal_servers.3F What type of signing of these internal Root certificates should be required? On Monday, February 23, 2015 at 2:40:15 PM UTC-7, John Nagle wrote: With the Lenovo and Comodo disclosures, the restrictions on loading new certificates into Firefox clients need to be tightened. Add-on policy is moving to a new system where add-ons cannot be added to a production version of Firefox without approval from AMO. SSL certificates should get the same treatment. If you can't install a new add-on unless it's been signed by AMO, why should you be able to install a new SSL certificate without having it signed? John Nagle SiteTruth ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Tightening up after the Lenovo and Comodo MITM certificates.
On Monday 23 February 2015 18:55:34 Richard Barnes wrote: On Mon, Feb 23, 2015 at 5:28 PM, Matt Palmer mpal...@hezmatt.org 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.) This is doubly problematic, as some people may want to preserve roots that were removed (see the recent removals of 1024 bit roots)... It's a big can of worms no matter how you approach it. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Tightening up after the Lenovo and Comodo MITM certificates.
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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Tightening up after the Lenovo and Comodo MITM certificates.
Daniel Veditz dved...@mozilla.com 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Tightening up after the Lenovo and Comodo MITM certificates.
This thread seems fairly focused on a technical solution; whereas I see this problem being more of an informed consent situation. I'm reminded of the discussion leading up to the know your rights toolbar and another discussion with respect to whether or not to display HTTP connections with explicit insecure visual feedback. Those discussions leaned towards informing the user. In this case informing them that they have pre-loaded 3rd party extensions or certificates. With the right wording a power user could think I do!? Let's investigate this. and a regular user could think Interesting. I wonder why they'd bother to tell me - better get on with my day. On Tue, Feb 24, 2015 at 3:54 PM Peter Kurrasch fhw...@gmail.com wrote: 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; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Tightening up after the Lenovo and Comodo MITM certificates. Daniel Veditz dved...@mozilla.com 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Tightening up after the Lenovo and Comodo MITM certificates.
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; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Tightening up after the Lenovo and Comodo MITM certificates. Daniel Veditz dved...@mozilla.com 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
