RE: Consequences of mis-issuance under CNNIC
Peter Gutmann said.. Daniel Micay danielmi...@gmail.com writes: CNNIC is known to have produced and distributed malware for the purpose of mass surveillance and censorship. TeliaSonera aided totalitarian governments, Comodo provided the PrivDog MITM software, and that's just the first two off the top of my head. If you have solid evidence that other CAs do this, feel free to present and I'll be a loud supporter of ripping out their certificates too. We'll start with Comodo then, shall we? Hi Peter, Your assertion about Comodo is wrong and that blunts your point instead of helping you make it. I refer you to my previous statement on Privdog. https://cabforum.org/pipermail/public/2015-February/005095.html and Hanno's post to this list https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg01 544.html Robin ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
On 31/03/15 02:34, Peter Gutmann wrote: So this is now a convenient excuse to kick out CNNIC, after the initial attempts to not let them in in the first place failed. I've always wondered, what do people have against CNNIC and Turktrust in particular? I haven't seen anyone in this thread mention TurkTrust in any context other than as one of the list of CAs which have misissued intermediates, which includes Trustwave and ANSSI (American and French respectively, if it matters). Given that other certificate vending machines trusted by Mozilla have done all manner of bad things (selling certs to phishers and other criminals, A certificate is proof of identity (or domain ownership), not of honesty. I'm not aware of any 100% accurate test for honesty that CAs could deploy even if we asked them to. selling certs for things like apple.com to multiple people who asked for them, [citation needed] selling thousands upon thousands of certs for internal, unqualified, and RFC 1918 domains/addresses, etc), all in violation of the BR, Internal names are not currently a BR violation (they will be soon). More generally, a second informal requirement for being in a browser, alongside Don't sell only a small number of certs (to meet the TB2F criteria required by browsers if something goes wrong) seems to be Don't be Chinese or Arab/Persian/Turkic. I have great respect for you as a technologist, but I'm disappointed that you would make such a serious (implied) accusation without extremely careful analysis of the facts. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
On 03/25/2015 12:54 AM, Erwann Abalea wrote: See also Mozilla CA Policy, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/, point 10. This unconstrained sub-CA MUST have been audited and disclosed to Mozilla *before* it was able to issue certificates. Thank you - I was waiting for someone to finally say this. This is a bit like Trustwave - what, it's an industry practice? Ralph ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
Best and most substantial summary I have read so far, Ryan. I do remember the CA communications Kathleen initiated after TrustWave. Also, CNNIC is saying it was only a test and we got it wrong and it had consequences. Not exactly trust-inspiring. On 03/25/2015 08:17 AM, Ryan Sleevi wrote: Based on the information provided so far, I think we can establish multiple failures upon CNNIC's part to comply with both the Baseline Requirements and Mozilla's Certificate Inclusion Policy. Some of these have also been raised by others (thanks Peter!), but below is a summary of the information available to date. * Section 17 of the BRs requires that all certificates _capable_ of being used to issue new certificates MUST either be Technically Constrained or audited in line with all of the requirements of Section 17. * Prior to the issuance of a certificate, CNNIC should have ensured a Point in Time Readiness Assessment with an appropriate audit scheme, per Section 17.4. * Prior to the issuance of a certificate, CNNIC should have ensured the development of a Key Generation Script and that the Key Generation Script was witnessed by a qualified auditor or a video recording opined upon by a qualified auditor, per Section 17.7. * Prior to the issuance of a certificate, CNNIC should have ensured that the keys were generated in a physically secured environment and generated securely, per Section 17.7. * CNNIC's current CPS (v3.03) does not provide for or describe the issuance procedures for test or subordinate CA certificates. The closest approximation is Section 2.2.10, which describes CNNIC pursuing cross-certification for their own root, not the use of CNNIC to cross-certify. * CNNIC's current CPS (v3.03) states in Section 6.2.3 that The private keys of the root certificates and intermediate root certificates of CNNIC Trusted Network Service Center are not entrusted to another agency, nor does CNNIC Trusted Network Service Center accept the entrustment from any certificate applicant to keep signature private keys.. Two interpretations of this exist - this is either a reaffirmation that subordinate CA keys are not issued (consistent with the rest of the CPS, and based upon entrusted to another agency referring to MCS), or that they only control the private keys detailed within the CPS itself. * CNNIC's current CPS (v3.03) states in Section 7.1.2 that the profile for issued certificates will have a CA=FALSE, through the mistranslation of basicConstraints as Basic Restriction and Subject Type = End Entity. * Mozilla's Certificate Inclusion Policy (v2.1 and 2.2) both require that all certificates capable of issuance be _publicly disclosed and audited_ or _technically constrained_ (Section 8). Disclosure is required _before_ the subordinate CA is allowed to issue certificates (Section 10). In the responses provided to this list, CNNIC has affirmed that MCS did not have a CPS developed, ergo did not have an approved Key Generation Script, did not have a Point-in-Time Readiness Assessment, and lacked any form of controls beyond that of contractual agreement. CNNIC knowingly and willingly issued certificates despite this - this was not a failure of technical controls (as was Turktrust), but an intentional action. This represents multiple Baseline Requirements and Mozilla Policy violations. Further, given the nature of these violations, there are zero guarantees that these would have been detected by an audit. Though CNNIC limited the certificate validity to 23 days (a value of time greater than the two weeks represented here and in the Mozilla blog post), such certificates could have only been detected by a sampling audit. Given that Section 17.8 only dictates a quarterly audit of 1 cert or 3% of issued certs, there is a significant probability that this certificate would not have shown. Had it shown, the fact that it has expired may, for many auditors, prevent a qualified finding from being issued, thus from Mozilla being notified. This is different than ANSSI, in which an administrator violated stated policy when handling the issued certificate, but which was part of the same organization recognized. The closest similarity to past misissuance is Trustwave, in which a CA knowingly violated the program requirements. At the time of Trustwave, there existed some confusion regarding this, which although many people disagreed with Trustwave's interpretation, Root Stores recognized this as a possible reading. Mozilla had previously affirmed in the February 17, 2012 communication the expectations regarding such certificates [1]. This was further affirmed in the January 10, 2013 [2] and May 13, 2014 [3] CA communications. As one last data point worth mentioning, during the request for inclusion of their EV root [4], it's noted that CNNIC is failing to comply with Mozilla and CA/B Forum Guidelines by not ensuring there are at least 20 bits of
Showing SHA1 certificate error in webconsole
Hi everyone, https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates Mozilla had add a security warning to the Web Console This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1. But i had verified a lot that site is using SHA2 only. Here is link : https://staging.landbay.co.uk/ Thanks ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Showing SHA1 certificate error in webconsole
It looks like your GeoTrust root cert uses SHA1: GeoTrust Primary Certification Authority Self-signed Fingerprint: 323c118e1bf7b8b65254e2e2100dd6029037f096 RSA 2048 bits (e 65537) / SHA1withRSA Weak or insecure signature, but no impact on root certificate See more details here: https://www.ssllabs.com/ssltest/analyze.html?d=staging.landbay.co.uk -Daniel On Tue, Mar 31, 2015 at 9:28 AM, dev-security-policy-requ...@lists.mozilla.org wrote: Message: 5 Date: Mon, 30 Mar 2015 05:24:33 -0700 (PDT) From: Innovify Agile innovifytest...@gmail.com To: mozilla-dev-security-pol...@lists.mozilla.org Subject: SHA1 warning in mozilla firebug console Message-ID: e38cacc8-2b15-46b4-8307-e273ce728...@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Hello everyone, I had updated my SSL certificate sha1 to sha2 and when i do online vertification on my site it's working fine. But when i'm using mozilla firefox , firebug says This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1. Can anyone help me to resolve this. Thanks ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
CT will be worthless if removals don't happen when the policy violations are detected. signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SHA1 warning in mozilla firebug console
Are you using sub-resources that have SHA-1 certs? On Mon, Mar 30, 2015 at 8:24 AM, Innovify Agile innovifytest...@gmail.com wrote: Hello everyone, I had updated my SSL certificate sha1 to sha2 and when i do online vertification on my site it's working fine. But when i'm using mozilla firefox , firebug says This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1. Can anyone help me to resolve this. Thanks ___ 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
