Hi, I think it is quite clear that e-Tugra has demonstrated that they are not able to handle the responsibilities that come with being a publicly trusted CA. Additionally, as there would be no user impact as a result of distrusting e-Tugra it seems to me that removal is the obvious choice.
-Cynthia On Mon, Jun 5, 2023 at 7:36 PM Ben Wilson <bwil...@mozilla.com> wrote: > > Dear Mozilla Community, > > This email relates to the e-Tugra breach that was described in a blog post by > Ian Carroll and subsequent discussions here and in CCADB Public and Bugzilla. > We are grateful for the involvement of various individuals and organizations, > particularly Ian Carroll and Google Chrome, who have contributed their > expertise and resources while investigating this breach. > > We are now opening this discussion to help determine whether the e-Tugra root > certificates should be removed from Mozilla’s Root Store. We will greatly > appreciate your thoughtful and constructive feedback on this. > > Below are some questions for us to consider in this discussion. > > What were the main concerns raised by the community during the discussions > that took place in Bugzilla Bug #1801345? (this is not a complete list; > details may be found in the bug) > > Mr. Carroll indicated that he was able to log in and conduct reconnaissance > on e-Tugra’s email and document storage systems, gaining access to customer > PII. > > There were security holes in e-Tugra’s internal systems that existed because > access to internal resources was not adequately secured, namely, default > passwords on some administrative tools had not been changed, and internal > applications were left exposed without appropriate access control mechanisms. > > Statements by e-Tugra about the lack of impact were refuted by the fact that > the contents of 568,647 emails and 251,230 documents were accessible, > including access to password resets and confirmation codes. > > e-Tugra indicated in their incident report that they would conduct additional > vulnerability scanning and penetration testing before the end of 2022. They > also said that they were preparing a detailed report of the problem and would > provide more information. > > None of this information was provided until April 2023. > > The explanations in subsequent reports and executive summaries of penetration > testing did not fully answer the questions that had been asked. > > A detailed analysis was not provided, no root cause analysis was ever > provided, and the output of the penetration test (i.e., reports) did not > offer any detail addressing concerns raised in the incident report. (The > penetration test reports only provided brief statements and insufficient > information to evaluate the security posture of e-Tugra.) > > Does the benefit of having e-Tugra root certificates in Mozilla’s Root Store > outweigh the risk? > > The breach that was found by Mr. Carroll may indicate that the CA operators > may not have the level of expertise necessary to securely operate a publicly > trusted CA. > > The slow response by e-Tugra may also be an indication that they may not be > prepared to respond to concerns and incidents in the required timely manner. > > How would the distrust of e-Tugra affect our users? > > Since the e-Tugra root certificates are not currently being used, there would > not be any impact to our users. > > e-Tugra is not currently issuing TLS certificates within their own CA > hierarchy. Instead, e-Tugra has been acting as a reseller for the SSL.com CA, > which means that all domain validation and certificate issuance is being > performed by systems operated by the SSL.com CA, so SSL.com is the party > currently responsible for issuance/security procedures. > > If distrusted, could e-Tugra continue to be a reseller for a publicly trusted > CA? > > Yes, as long as the publicly trusted CA ensures correct > systems/procedures/processes in relation to reselling certificates within > their CA hierarchy. > > If distrusted, could e-Tugra re-apply to have their root certificates > included in Mozilla’s Root Store? > > If we decide to remove the current e-Tugra roots, then in order for e-Tugra > to apply to have their root certificates included in Mozilla’s Root Store > again, they would need to: > > Implement an infrastructure that is properly secure and tested, with > sufficiently detailed artifacts to show that the systems are properly > configured. > > Then create new root certificates within the properly secured infrastructure. > > Then re-apply for inclusion in Mozilla’s root store. > > As always, the onus is on the CA operator to demonstrate their ability to > operate a publicly trusted CA hierarchy. > > How are other root stores addressing this issue? > > Google Chrome announced that they will remove the “E-Tugra Global Root CA ECC > v3” and “E-Tugra Global Root CA RSA v3” roots from the Chrome Root Store. > > Apple stated that the e-Tugra roots are not in the Apple Root Store. > > Given that SSL.com has been the operator of the issuing CA, e-Tugra’s breach > has not necessitated that we take any urgent safeguarding actions. However, > e-Tugra’s problems give us reason to question whether the e-Tugra CA should > continue to be in our root store, based on the level of expertise required to > securely operate a publicly trusted CA infrastructure. Additionally, > e-Tugra’s inadequate responses to the problem and resulting requests for > information, give us reason to question e-Tugra’s commitment to the important > role that CAs have in ensuring security on the web. > > We appreciate your engagement and dedication, and we kindly request that all > participants adhere to our Community Participation Guidelines, fostering a > respectful and constructive environment for dialogue. > > Thanks, > > Ben and Kathleen > > PS: For your reference, below are excerpts from > https://wiki.mozilla.org/CA/Maintenance_and_Enforcement > > CA behavior > > Did the CA notice the error and take appropriate action in a timely manner? > > Was the threat or error properly contained? > > Did the CA notice the hacker intrusion and take appropriate action in a > timely manner? > > Were the CA's defense mechanisms current and sufficient? > > Was the intrusion appropriately contained? > > Was the CA's behavior reckless? > > Did the CA try to cover up the mistake/threat rather than follow Mozilla's > Security Policy? > > In incident response, Mozilla is looking for the following factors: > > A CA takes responsibility for their own actions. > > Incidents are taken with an appropriate level of seriousness. > > Incidents are handled with urgency. > > Root cause analysis is performed. > > Any questions posed, by anyone, are answered quickly and in detail. > > A reasonably-detailed incident report is made public on what happened, why, > and how things have changed to make sure it won’t happen again > > > -- > You received this message because you are subscribed to the Google Groups > "dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaUPBb1DG4Uc4Cs40K4v56c2hzkdYO-JS8sNN9K%2BzzfYw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKw1M3PBFrSUNh2nWFe2WHueobPrdvs8JwztWJe0%2BpzPSZoh5w%40mail.gmail.com.
