Re: Consequences of mis-issuance under CNNIC
Absolutely agreed. There is ample evidence that CNNIC has not upheld their responsibilities in Mozilla's Certificate Inclusion Policy. Can someone please file a bug to remove CNNIC as a trusted root CA? -Daniel On Tuesday, March 24, 2015 at 2:18:12 PM UTC-7, 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 entropy
Re: NSS Trust Bits for AOL root cert?
Ok, thanks for the clarification. I was wondering why https://pki-info.aol.com/ had stopped responding. It's sad to see them go. I was hoping they would start issuing free SSL certs with them or donate them to someone (Mozilla?) who would start issuing free SSL certs. We desperately need some competition to StartCom. Daniel On Tuesday, October 28, 2014 12:13:33 PM UTC-7, Kathleen Wilson wrote: I should clarify that the two remaining AOL root certs are also going to be removed per https://bugzilla.mozilla.org/show_bug.cgi?id=1083294 Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
Yes, I started this thread. I officially declare this thread closed...even though I have no ability to enforce it. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Proposal: Switch generic icon to negative feedback for non-https sites
So the general top criticism I'm seeing to this proposal is that it's too expensive (in both time and money) get an SSL certificate. I'm feeling a general consensus that HTTPS is desired, but it's too difficult to attain for many sysadmins. So what can be done to lower the threshold to get sysadmins to start serving over HTTPS? Allowing self-signed certs is one proposal. What are some others? Could Mozilla start their own root CA and give out SSL certs for free? How about a kickstarter to make a free root CA? Now is the time for creative solutions! And it will likely take pushing from many different fronts to make this happen :) On Sunday, July 20, 2014 10:05:10 AM UTC-7, Daniel Micay wrote: On 20/07/14 06:23 AM, Hubert Kario wrote: - Original Message - From: David E. Ross nobody@nowhere.invalid To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Sunday, 20 July, 2014 4:39:09 AM Subject: Re: Proposal: Switch generic icon to negative feedback for non-https sites On 7/19/2014 11:54 AM, Daniel Roesler wrote: Howdy all, Yesterday, I created a bug proposing that Firefox switch the generic url icon to a negative feedback icon for non-https sites. https://bugzilla.mozilla.org/show_bug.cgi?id=1041087 I created this bug because it's time we start treating insecure connections as a Bug. There is so much open wifi available to the modern internet user that a significant portion Firefox users' requests can be sniffed. If that request is insecure, it makes session hijacking, MITM, and metadata attacks trivially easy. Not using https should now be bad practice and considered harmful. Mozilla should be a leader and push websites to start securing their connections. Many of the largest websites already default to https, and it's time to start bringing the rest on board. Having negative feedback for insecure connections offers a huge incentive to fixing the larger Bug of insecure connections. Thanks and looking forward to any discussion, Daniel Roesler diaf...@gmail.com Your concept would cast a negative shadow over many non-commercial Web sites, blogs, and legitimate freeware sources. Are you willing to pay the cost of site certificates for such sites? How about just the cost of a site certificate for my own site? I have no advertising on my site and thus no revenues to pay for a certificate. Yes, I know there are some certification authorities that issue free certificates. For various reasons, I have marked many of their root certificates as untrusted. I was able to get a certificate for a year for $3 that links up to COMODO CA. That was without any promotions or coupons - regular price. You need to pay few times more for hosting than you need to pay for certificates. Also, while you might have marked them as untrusted, I'm sure that the vast majority (over 99%) of users didn't. Rightfully so. They are not supposed to thwart any and all attacks. They are there so that trivial attacks can't be launched. There are about 1000 CA's that are trusted by Firefox (by linking up to root CA certs or by being in the root store directly), how many of them have you marked as untrustworthy? +1 on the idea of starting treating HTTP as insecure and while we're at it, let's get rid of those warnings about self signed certificates -- they are less insecure than HTTP (Firefox actually uses certificate pinning for sites with previously waived cert problems!) so let's not treat them worse than HTTP connections They shouldn't show up with a lock icon, but treating HTTPS connections as less secure than an HTTP connection is counterproductive. Self-signed certificates should still be forbidden with HSTS. It prevents an attacker from using sslstrip, so it should also prevent them from providing their own certificate. The sslstrip technique already prevents HTTPS from having *any* value without basic user education (or HSTS). Looking for a lock icon instead of https:// wouldn't be a big change. In Chromium, the leading http:// is hidden, so they're in the position to start allowing self-signed HTTPS with the leading https:// hidden. It would only be there when copying the URL. http://tools.ietf.org/html/draft-dukhovni-opportunistic-security-00 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
