Incident report - ROCA fingerprints in certificates issued by Comodo CA (was Re: RSA key generation vulnerability in Infineon firmware)
On 16/10/17 15:13, Alex Gaynor via dev-security-policy wrote: Hi all, Today researchers announced a vulnerability they discovered in RSA keys generated by a particular piece of firmware, which allows practical factorization of the private key given just the public key. Full details of the research here: https://crocs.fi.muni.cz/public/papers/rsa_ccs17 There is a publicly available tool for testing keys here: https://github.com/crocs-muni/roca I'd encourage CAs to proactive check all of their issued certificates, particularly S/MIME/client certs, since this affects common smartcard implementations. Comodo CA became aware of the ROCA vulnerability (CVE-2017-15361) on Monday 16th October at 12:45 UTC. We immediately downloaded the key testing tools from https://github.com/crocs-muni/roca and set about implementing the ROCA check in crt.sh. Having completed this implementation work on Tuesday 17th October, a report of all ROCA fingerprints found on crt.sh was published to m.d.s.p / https://misissued.com/batch/28/ on Wednesday 18th October. We then set about scanning (for ROCA fingerprints) all of the certs that we'd ever issued. This scan completed on Friday 20th October and found 175 certificates with ROCA fingerprints. Only 33 of these certs had not yet expired: 9 Server Authentication certificates 24 S/MIME certificates crt.sh links for the 9 serverAuth certs: [www.]my.intellectscada.com https://crt.sh/?id=6169662 [*.]crd.bc.ca https://crt.sh/?id=248616628 https://crt.sh/?id=248616633 https://crt.sh/?id=248616641 [www.]gsappre01.nu.com https://crt.sh/?id=248616637 https://crt.sh/?id=248616648 [www.]scada.nelha.net https://crt.sh/?id=14815246 https://crt.sh/?id=248616640 [www.]scada.nelha.org https://crt.sh/?id=248616645 A report was made available to our Validation/Support teams, who set about contacting the affected customers and revoking the certificates. The last of these certificates was revoked on 2nd November. On Tuesday 31st October we implemented the ROCA vulnerability check in our PKCS#10 CSR parsing code, and on Thursday 2nd November we implemented the ROCA vulnerability check in our SPKAC () and CRMF (RFC2511) parsing code. These changes were deployed to our production CA system on Sunday 5th November. On Monday 6th November, we scanned the certificates that we'd issued between 20th October and 5th November. 8 further server authentication certificates were found, all for subdomains of the same registered domain. We will get these revoked and then post the details. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On Mon, Nov 6, 2017 at 6:34 AM, Fotis Loukos via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 04/11/2017 02:36 μμ, Daniel Cater via dev-security-policy wrote: > > I notice that on https://crt.sh/mozilla-onecrl there are lots of > certificates that have recently been added to OneCRL from the .tg TLD > (Togo), including ones for high-profile domains such as google.tg. The > issuances occurred 3 days ago, on 1st November. > > According to LE CP section 4.2.1: > The CA SHALL develop, maintain, and implement documented procedures that > identify and require additional verification activity for High Risk > Certificate Requests prior to the Certificate’s approval, as reasonably > necessary to ensure that such requests are properly verified under these > Requirements. > > The same language also exists in section 4.2.1 of the CA/B Forum BRs. > > Has Lets Encrypt implemented the documented procedures? Is a request for > google.tg considered a high risk certificate request based on the > LetsEncrypt risk-mitigation criteria? > Does it matter? We've discussed this on the list several times in the past - the fact is that it can be whatever a CA defines, and is itself not meaningful for assurance. We've also seen how CA's "high risk" lists have ended up denying legitimate requests or causing security issues, so it hardly seems the thing to hang our hat on, or the thing of substance worth discussing. Should all CAs treat .tg as high risk now? Should all domains be treated as high risk, since, of course, registries can have issues? You can see how we can quickly devolve into arguing everything is High Risk, while, in practice, nothing is High Risk. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On 4 November 2017 at 19:54, Kathleen Wilson via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/4/17 5:36 AM, Daniel Cater wrote: > >> I notice that on https://crt.sh/mozilla-onecrl there are lots of >> certificates that have recently been added to OneCRL from the .tg TLD >> (Togo), including ones for high-profile domains such as google.tg. The >> issuances occurred 3 days ago, on 1st November. >> >> I don't see a thread already for this here, or on >> https://letsencrypt.org/blog/ so I thought I would start one. >> >> From the check-in comment "registry problems", I assume that this is a >>> problem with the TLD rather than with Let's Encrypt. >>> >> >> As OneCRL and CRLSets are public this information is being noticed. There >> is likely a large overlap between the people that read this group and the >> people that monitor those lists. That said, be mindful of posting any >> specific technical vulnerabilities or exploits which may not yet be patched. >> >> > > As you have noticed based on OneCRL and crt.sh, there was a problem with > the *.tg registry, and SSL certificates were issued to domains in *.tg that > probably should not have been issued. As you can see, the Let's Encrypt CA > was made aware of the problem and has already responded by revoking the > impacted certs, and we have added entries for those certs to OneCRL. > Unfortunately, the CT data shows that other CAs also recently issued certs > containing *.tg domains. > > I have not personally spoken with the people at the *.tg registry yet, but > my understanding is that the problem has been fixed on their end. > > This is a new scenario to me -- having a problem at a registry that > results in SSL certs being issued that otherwise would not have been > issued. So I am trying to figure out how to respond to it. For example, > should I send email to only the CAs who are showing up in CT and crt.sh as > having issued SSL certs for the *.tg TLD within the past few days? Or > should I send an email blast out to all CAs in Mozilla's program? > > I think those CAs need to re-validate their recently issued SSL certs that > contain any *.tg domains, and possibly revoke such certs and send us the > info so corresponding entries can be added to OneCRL. But, as this is new > to me, I will appreciate thoughtful and constructive input in this. Since CT is not (yet) compulsory, it seems you probably have to contact all CAs, doesn't it? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: .tg Certificates Issued by Let's Encrypt
On 04/11/2017 02:36 μμ, Daniel Cater via dev-security-policy wrote: > I notice that on https://crt.sh/mozilla-onecrl there are lots of certificates > that have recently been added to OneCRL from the .tg TLD (Togo), including > ones for high-profile domains such as google.tg. The issuances occurred 3 > days ago, on 1st November. According to LE CP section 4.2.1: The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements. The same language also exists in section 4.2.1 of the CA/B Forum BRs. Has Lets Encrypt implemented the documented procedures? Is a request for google.tg considered a high risk certificate request based on the LetsEncrypt risk-mitigation criteria? Regards, Fotis > > I don't see a thread already for this here, or on > https://letsencrypt.org/blog/ so I thought I would start one. > > From the check-in comment "registry problems", I assume that this is a > problem with the TLD rather than with Let's Encrypt. > > As OneCRL and CRLSets are public this information is being noticed. There is > likely a large overlap between the people that read this group and the people > that monitor those lists. That said, be mindful of posting any specific > technical vulnerabilities or exploits which may not yet be patched. > ___ > 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
