Thank you for this incident report Fotis. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1534145 to track this issue.
On Fri, Mar 8, 2019 at 4:37 PM Fotis Loukos via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > ### Problem description > > SSL.com has issued a limited number of ECDSA certificates with > curve-hash pairs that are no longer allowed by the Mozilla Root Store > Policy. > > In particular, section 5.1 states that: > > > Root certificates in our root program, and any certificate which > chains up to them, MUST use only algorithms and key sizes from the > following set: > > - ECDSA keys using one of the following curve-hash pairs: > > - P‐256 with SHA-256 > > - P‐384 with SHA-384 > > A number of certificates which do not use these pairs have been issued. > In particular, certificates were issued using the P-384 curve / > ecdsa-with-SHA256 pair. > > It should be noted that all of these certificates are compliant with the > CA/B Forum Baseline Requirements, but not with the current Mozilla Root > Store Policy, as it was amended at version 2.4 the 1st of March 2017. > > ### How your CA first became aware of the problem (e.g. via a problem > report submitted to your Problem Reporting Mechanism, a discussion in > mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), > and the time and date. > > On Monday, 25 February 2019, a manual review of some certificates that > were going to be issued was conducted by multiple teams within SSL.com > instead of the compliance team only, and the problem was identified. > > ### A timeline of the actions your CA took in response. A timeline is a > date-and-time-stamped sequence of all relevant events. This may include > events before the incident was reported, such as when a particular > requirement became applicable, or a document changed, or a bug was > introduced, or an audit was done. > > - 01/03/2017 - Version 2.4 of the Mozilla Root Store Policy was > published which limits the allowed curve-hash pairs for the ECDSA > algorithm. > - 01/03/2017 - The differences between version 2.3 and 2.4 of the Policy > were communicated between the different departments of SSL.com, without > including the limits on the allowed curve-hash pairs. > - 25/02/2019 - A manual review of some certificates that were going to > be issued was conducted by multiple teams within SSL.com. It was > identified that the curve-hash pair was illegal and no certificates were > issued. > - 25/02/2019 - As a result an investigation was performed and found that > additional certificates had been issued using the same curve-hash pair. > The incident response process formally began. > - 25/02/2019 - In addition to the end-user certificates this > investigation found several CAs certificates that were created with this > set of parameters. > - 26/02/2019 - Issuance of all ECDSA certificates was suspended and a > plan of action for remediation of this issue begun. > - 26/02/2019 - Mozilla was contacted and was made aware of the issue. > - 26/02/2019 - We reviewed all linters and we found that we had none for > the Mozilla Root Store Policy requirements. > - 26/02/2019 - To improve both pre-issuance and post-issuance auditing, > we reviewed all Mozilla technical requirements and implemented linters > for each one to ensure continued compliance. > - 26/02/2019 - These linters were executed against the entire corpus of > certificates to ensure all associated certificates were identified. > - 27/02/2019 - Restructuring of the mode of operation of the compliance > team begun in order to ensure better monitoring of browser policies. > - 07/03/2019 - The configuration of all production CAs was modified to > prevent the future issuance of certificates using these parameters. > - 07/03/2019 - All misissued end-user certificates were revoked. > - 07/03/2019 - To mitigate this issue we took the decision to revoke all > associated CAs including those created before the Mozilla policy was > created prohibiting these curves to ensure we meet the highest possible > level of security and compliance. > - 07/03/2019 - Issuance of ECDSA certificates was resumed. > > ### Whether your CA has stopped, or has not yet stopped, issuing > certificates with the problem. A statement that you have will be > considered a pledge to the community; a statement that you have not > requires an explanation. > > All issuance of ECDSA certificates was suspended when we realized the > Mozilla Root Store Policy compliance issue. > > After fixing the certificate profiles to limit the curve-hash pairs, > revoking the old SubCAs and issuing new ones using the P-384 curve and > ecdsa-with-SHA384, ECDSA certificate issuance was resumed. > > ### A summary of the problematic certificates. For each problem: number > of certs, and the date the first and last certs with that problem were > issued. > > The total number of certificates that were issued using curve-hash pairs > not compliant with the Mozilla Root Store Policy are: > > - CA Certificates: 10 certificates from Dec 17 2018 to Feb 14 2019 > - SSL Certificates: 15 certificates from Apr 24 2018 to Feb 25 2019 > - OCSP Responder certificates: 11 certificates from May 29 2018 to Feb > 20 2019 > > ### The complete certificate data for the problematic certificates. The > recommended way to provide this is to ensure each certificate is logged > to CT and then list the fingerprints or crt.sh IDs, either in the report > or as an attached spreadsheet, with one list per distinct problem. > > Please find attached the files cacerts.csv, sslcerts.csv and > ocspcerts.csv that contain a full list of all problematic certificates. > > Please note that this is not the complete list of the certificates that > were revoked, but only the ones that were not in compliance with the > Mozilla Root Store Policy. > > ### Explanation about how and why the mistakes were made or bugs > introduced, and how they avoided detection until now. > > Before version 2.4 of the Mozilla Root Store Policy there were no > restrictions on the possible allowed curve-hash pairs when using P-256 > and P-384 with SHA256 and SHA384. Thus, our initial set up included the > P-384 with SHA-256 pair. This changed with version 2.4 and was clarified > at 2.4.1. Unfortunately, the change was not communicated to the > technical team. When this was clarified at 2.4.1, it seemed as a > clarification to a practice which we already implement. > > Furthermore, SSL.com implements linting of the tbsCertificate structure > before using the CA key to perform any signing operation (either > pre-certificate or certificate). However, the set of linters we use > (certlint/cablint and zlint) lint against RFC5280 and the CA/B Forum > Baseline Requirements, and not the Mozilla Root Store Policy. > > The issue was not identified during any of the audits, since it is not > an auditable criteria being part only of the Mozilla Root Store Policy. > > ### List of steps your CA is taking to resolve the situation and ensure > such issuance will not be repeated in the future, accompanied with a > timeline of when your CA expects to accomplish these things. > > We have taken several different steps to ensure that we will not have > such issues again in the future. > > - We have introduced changes in the compliance department, and our team > will monitor closely all changes in the Mozilla Root Store Policy as > they are reflected at the github repository. These changes will be > handled in a similar fashion to the CA/B Forum Baseline Requirements and > other similar compliance requirements. > - We have already created a linter that checks against the specific > requirements set by the Mozilla Root Store Policy. This linter is set up > to lint the tbsCertificates at the same time as the aforementioned linters. > - The compliance department will provide feedback to the team that > maintains the linter in order to keep it up to date. > > Best regards, > Fotis > > -- > Fotis Loukos, PhD > Director of Security Architecture > SSL Corp > e: fot...@ssl.com > w: https://www.ssl.com > _______________________________________________ > 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
