Re: .tg Certificates Issued by Let's Encrypt
Thank you to everyone who has been looking into the .tg Registry problem and providing valuable information. I greatly appreciate all of your efforts! I have updated the related action item in the November CA Communication to reflect the dates that we believe the .tg Registry was having problems with NS Records. ~~ ACTION 8: Check for issuance of certificates containing .tg domains from October 25 to November 11, 2017. We believe that the .tg Registry was compromised from October 25 to November 10, 2017, such that a perpetrator set the Name Server (NS) Records for some domains to name servers controlled by them, and then successfully obtained certificates for those domains. Please check the certificates containing .tg domains that chain up to your root certificates included in Mozilla's program to ensure that the certificate subscriber actually owns the domains included in their certificate. Response Options: - There are no certificates containing .tg domains that chain up to our root certificates included in Mozilla's program. - There are certificates containing .tg domains that chain up to our root certificates included in Mozilla's program, but there were no new validations on .tg domains from October 25 to November 11, 2017. - There are certificates containing .tg domains that chain up to our root certificates included in Mozilla's program, and we have re-verified the certificates that were issued for .tg domains from October 25 to November 11, 2017, and no problems were found. - We have revoked certificates containing .tg domains that were issued between October 25 and November 11, 2017, and have sent information about these revoked certificates to Mozilla. - Other - explain ~~ Thanks, Kathleen ___ 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
Hi Kathleen, Comodo issued a number of certificates to .tg domains during the period of interest. We see a history of applications for .gouv.tg certificates which we had been previously been rejecting and suddenly in the period of interest we issued them - which might support the notion of the .tg registry being compromised. It could, of course, also indicate a sudden burst of activity by the Togo government in setting up websites. It is hard to tell. We issued certificates including around 170 names matching .gouv.tg. Issued names certificates 19/06/2017 2 1 01/08/2017 1 1 25/10/2017 31 7 26/10/2017 46 15 27/10/2017 7 3 28/10/2017 8 4 30/10/2017 19 8 31/10/2017 20 4 01/11/2017 12 2 02/11/2017 9 3 03/11/2017 8 4 04/11/2017 5 2 and that's when we blocked .tg. When we first got a heads-up about this we looked at the data and I said that it looked to me like 25th October was the transition to chaos, since that is when we issued the first of many gouv.tg certificates. I hope that helps a little. Regards Robin Alden Comodo CA Ltd > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+robin=comodo@lists.mozilla.org] On Behalf Of Kathleen Wilson > via dev-security-policy > Sent: 14 November 2017 16:31 > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: .tg Certificates Issued by Let's Encrypt > > On 11/14/17 4:34 AM, douglas.beat...@gmail.com wrote: > > > > Do we believe that this issue has been resolved by the Registry and issuance > an resume as normal, or are there ongoing concerns which CAs should be > aware of when issuing certificates to .tg domains? > > > > > Based on information from folks that are monitoring their NS Records, we > believe that the .tg Registry problems were fixed on November 1, and > have remained fixed since then. > > I have not looked into how Registries are operated and maintained, so > here is my personal (uneducated) opinion: I think it is possible that > the .tg Registry could be compromised again. I have no idea if all of > the newer Registries are using good network and security protocols, > infrastructure, etc. > > I think that we will need to have much deeper investigation and > discussions about Registries, so I have added this to my to-do list, but > I will not be able to get to it until January. > > Thanks, > Kathleen > > > > ___ > 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: .tg Certificates Issued by Let's Encrypt
On Tuesday, 14 November 2017 16:31:34 UTC, Kathleen Wilson wrote: > Based on information from folks that are monitoring their NS Records, we > believe that the .tg Registry problems were fixed on November 1, and > have remained fixed since then. > > I have not looked into how Registries are operated and maintained, so > here is my personal (uneducated) opinion: I think it is possible that > the .tg Registry could be compromised again. I have no idea if all of > the newer Registries are using good network and security protocols, > infrastructure, etc. Can we loop in somebody (from ICANN maybe? or the root operators?) who can speak for the top level? Do they actually have any power or influence over ccTLDs at all ? Do these registries in practice actually do anything they're told or are they a law unto themselves? It seems to me there's a bunch of options here At one extreme we just accept that some TLDs will be poorly run, entities like Google that have acquired 2LDs in every suffix they can will have cause to regret this but it's not our fight. Certificates for google.tg will be properly issued to whoever happens to persuade the broken .tg registry system to agree they own it that morning, and if asked we point to the .tg registry because it's their problem. Because the DNS is a hierarchy this has no impact for people whose names aren't under poorly run registries, and the incentive to run registries properly lies with the registrars who can expect nobody to bother paying for something that's now effectively worthless. A middle path is that CA/B or Mozilla on its own, decides that registries which can't manage this sort of thing properly aren't able to deliver on the promise that names should be "meaningful" and so a list of registries will be blacklisted and all names under those suffixes will be ineligible for Web PKI certificates, it would then always be mis-issuance to issue for such names at all. And at another extreme Mozilla could decide that Firefox, the browser, won't trust such names, and blacklist suffixes at its sole discretion, affected DNS names would simply never get treated as secure in Firefox - it would be acceptable to issue certificates but they won't make any difference for those names. ___ 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 Tuesday, November 14, 2017 at 8:31:34 AM UTC-8, Kathleen Wilson wrote: > On 11/14/17 4:34 AM, douglas...@gmail.com wrote: > > > > Do we believe that this issue has been resolved by the Registry and > > issuance an resume as normal, or are there ongoing concerns which CAs > > should be aware of when issuing certificates to .tg domains? > > Based on information from folks that are monitoring their NS Records, we > believe that the .tg Registry problems were fixed on November 1, and > have remained fixed since then. Let's Encrypt disabled issuance to .tg on November 1 as a protective measure. The block remains in place. We'd like to lift the block but we have seen no evidence that the problem was ever acknowledged or fixed by anyone involved in running the .tg registry. Most of the issuance to .tg during the problematic period was from Let's Encrypt (note that validation was successfully completed, Let's Encrypt did not mis-issue). Since we disabled issuance to .tg on Nov 1 a lack of new suspicious issuance may only reflect our block, not resolution of problems. The fact that some large companies got control of their domains back may only reflect customer service actions. We are stuck in a difficult situation where we'd like to re-enable issuance to .tg but we just don't have confidence that the registry is secure. If anyone has any direct evidence we'd greatly appreciate seeing it. Without more evidence we will simply have to re-enable .tg issuance and monitor it for a period of time. ___ 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 11/14/17 4:34 AM, douglas.beat...@gmail.com wrote: Do we believe that this issue has been resolved by the Registry and issuance an resume as normal, or are there ongoing concerns which CAs should be aware of when issuing certificates to .tg domains? Based on information from folks that are monitoring their NS Records, we believe that the .tg Registry problems were fixed on November 1, and have remained fixed since then. I have not looked into how Registries are operated and maintained, so here is my personal (uneducated) opinion: I think it is possible that the .tg Registry could be compromised again. I have no idea if all of the newer Registries are using good network and security protocols, infrastructure, etc. I think that we will need to have much deeper investigation and discussions about Registries, so I have added this to my to-do list, but I will not be able to get to it until January. Thanks, Kathleen ___ 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 11/13/17 7:22 PM, Jakob Bohm wrote: Wouldn't the .tg incident be equally relevant for the e-mail trust bit? (In which case the first 3 options should say TLS/SSL/e-mail) Good point. To make it easier, I removed "TLS/SSL", and changed text to "certificates containing .tg domains". Updated as follows: ~~ ACTION 8: Check for issuance of certificates containing .tg domains from October 25 to November 2, 2017. We believe that the .tg Registry was compromised from October 25 to November 1, 2017, such that a perpetrator set the Name Server (NS) Records for some domains to name servers controlled by them, and then successfully obtained certificates for those domains. Please check the certificates containing .tg domains that chain up to your root certificates included in Mozilla's program to ensure that the certificate subscriber actually owns the domains included in their certificate. Response Options: - There are no certificates containing .tg domains that chain up to our root certificates included in Mozilla's program. - There are certificates containing .tg domains that chain up to our root certificates included in Mozilla's program, but there were no new validations on .tg domains from October 25 to November 2, 2017. - There are certificates containing .tg domains that chain up to our root certificates included in Mozilla's program, and we have re-verified the certificates that were issued for .tg domains from October 25 to November 2, 2017, and no problems were found. - We have revoked certificates containing .tg domains that were issued between October 25 and November 2, 2017, and have sent information about these revoked certificates to Mozilla. - Other - explain ~~ Thanks, Kathleen ___ 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 Monday, November 6, 2017 at 6:40:58 AM UTC-5, Ben Laurie wrote: > 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 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? Do we believe that this issue has been resolved by the Registry and issuance an resume as normal, or are there ongoing concerns which CAs should be aware of when issuing certificates to .tg domains? ___ 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 14/11/2017 02:23, Kathleen Wilson wrote: On 11/6/17 3:40 AM, Ben Laurie wrote: Since CT is not (yet) compulsory, it seems you probably have to contact all CAs, doesn't it? To close the loop on this... I have added the following to the draft of the November 2017 CA Communication. ~~ ACTION 8: Check for issuance of TLS/SSL certificates to .tg domains from October 25 to November 2, 2017. We believe that the .tg Registry was compromised from October 25 to November 1, 2017, such that a perpetrator set the Name Server (NS) Records for some domains to name servers controlled by them, and then successfully obtained SSL certificates for those domains. Please check the SSL certificates that were issued to .tg domains and that chain up to your root certificates included in Mozilla's program to ensure that the certificate subscriber actually owns the domains included in their certificate. Response Options: - There are no TLS/SSL certificates issued to .tg domains that chain up to our root certificates included in Mozilla's program. - There are TLS/SSL certificates issued to .tg domains that chain up to our root certificates included in Mozilla's program, but there were no new validations on .tg domains from October 25 to November 2, 2017. - There are TLS/SSL certificates issued to .tg domains that chain up to our root certificates included in Mozilla's program, and we have re-verified the certificates that were issued to .tg domains from October 25 to November 2, 2017, and no problems were found. - We have revoked certificates to .tg domains between October 25 and November 2, 2017, and have sent information about these revoked certificates to Mozilla. Shouldn't there be an "issued" in there? (as phrased it seems to say that the revocation, not the issuance, took place during the incident). - Not Applicable, because our root certificates do not have the Websites trust bit enabled. Wouldn't the .tg incident be equally relevant for the e-mail trust bit? (In which case the first 3 options should say TLS/SSL/e-mail) - Other - explain ~~ Thanks, Kathleen Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ 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 11/6/17 3:40 AM, Ben Laurie wrote: Since CT is not (yet) compulsory, it seems you probably have to contact all CAs, doesn't it? To close the loop on this... I have added the following to the draft of the November 2017 CA Communication. ~~ ACTION 8: Check for issuance of TLS/SSL certificates to .tg domains from October 25 to November 2, 2017. We believe that the .tg Registry was compromised from October 25 to November 1, 2017, such that a perpetrator set the Name Server (NS) Records for some domains to name servers controlled by them, and then successfully obtained SSL certificates for those domains. Please check the SSL certificates that were issued to .tg domains and that chain up to your root certificates included in Mozilla's program to ensure that the certificate subscriber actually owns the domains included in their certificate. Response Options: - There are no TLS/SSL certificates issued to .tg domains that chain up to our root certificates included in Mozilla's program. - There are TLS/SSL certificates issued to .tg domains that chain up to our root certificates included in Mozilla's program, but there were no new validations on .tg domains from October 25 to November 2, 2017. - There are TLS/SSL certificates issued to .tg domains that chain up to our root certificates included in Mozilla's program, and we have re-verified the certificates that were issued to .tg domains from October 25 to November 2, 2017, and no problems were found. - We have revoked certificates to .tg domains between October 25 and November 2, 2017, and have sent information about these revoked certificates to Mozilla. - Not Applicable, because our root certificates do not have the Websites trust bit enabled. - Other - explain ~~ Thanks, Kathleen ___ 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 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
Re: .tg Certificates Issued by Let's Encrypt
Neither CAA nor DNSSEC mitigate registry compromises. On Sun, Nov 5, 2017 at 9:15 AM Daniel Cater via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hmm, CAA records could also potentially be spoofed in this situation, in > which case they would also not be trustworthy (save for cached records with > a long TTL). > ___ > 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: .tg Certificates Issued by Let's Encrypt
Hmm, CAA records could also potentially be spoofed in this situation, in which case they would also not be trustworthy (save for cached records with a long TTL). ___ 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
I think it depends on whether the issue has been fixed or not. If it has not been fixed, then I would say that all CAs need to put a hold on .tg certificate issuance as a priority. If a registry can be compromised, then potentially the integrity of all 10 blessed methods is at risk. If it has been fixed, then I think revalidating all recent issuances (for some definition of recent) makes sense, and revoking those that cannot be confirmed as legitimate. CAA might have helped in some situations here, for example google.tg doesn't have a CAA record and if it referenced "pki.goog" then it's unlikely an attacker could have gained a valid certificate from that CA. In a lot of instances I expect it wouldn't have helped, because the attacker could just go to the approved CA and request the certificate, and the domain validation would succeed using whatever registry/domain-takeover method was used (unless the CA has extra checkpoints / blocks in place for particular high-profile domains). I note that .tg still doesn't have DNSSEC enabled: http://stats.research.icann.org/dns/tld_report/ This may or may not have helped mitigate the attack for those sites, depending on the technical details. On Saturday, 4 November 2017 19:55:05 UTC, Kathleen Wilson wrote: > 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? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
