Google provides SCTs via embedding and during SSL handshaking depending on the certificate and how it is served. In this case, all of the affected certs used embedded SCTs and the issue was the selection of which SCTs to include because we submit to more CT logs than required, but only embed the required number of SCTs to keep cert sizes as small as possible. These certs were submitted to 4 CT logs, 2 Google, 2 non-Google, but the embedded certs were only from the 2 Google logs, not one Google and one non-Google. The CA signed 4 correct SCTs and all 4 were submitted to CT logs, the problem was the embedding logic for the SCTs.
In response to Q1, the logic involved was specific to selection and embedding of SCTs, not part of validation logic, so a related error would not affect validation. An unrelated error in validation logic could of course affect validation, but all CAs have that risk and like other CAs we have multiple layers of safeguards on validation logic. For Q2, we sample certs regularly and make use of proven external linting libraries and our own linting and audit logic. In this case because the issue was not something normally checked by external tools and the behavior was perfectly fine until the Chrome deadline in April, I can only posit that we would have discovered it fairly quickly via other means. We now have specific checks for this issue and other similar problems we could foresee. For Q3, we could account for the initial submission fully and understand exactly what happened. Google has rigorous version control and enforcement systems to ensure only properly reviewed and built code can enter production and to reconcile running code against the cut point for an approved release. Our CA systems have additional safeguards on top of those standard tools to further ensure that we have strong knowledge of the pedigree of all code and how it was built and deployed. On Thu, Aug 23, 2018 at 10:55 AM Nick Lamb <[email protected]> wrote: > On Thu, 23 Aug 2018 05:50:05 -0700 (PDT) > Andy Warner via dev-security-policy > <[email protected]> wrote: > > > May 21st 2018, a new tool for issuing certificates within Google was > > made available to internal customers. Within hours we started to > > receive reports that Chrome Canary (v67) with Certificate > > Transparency checks enabled was showing warnings. A coding error led > > to the new tool providing Signed Certificate Timestamps (SCTs) from 2 > > Google CT logs instead of one Google and one non-Google log. > > Feel free to jump in anywhere I've made a mistake, this might totally > invalidate some of my questions. > > Presumably, since you eventually "fixed" this by asking Subscribers to > re-issue, the SCTs are baked into a signed certificate, rather than > provided separately so that the Subscriber can use them with e.g. > Stapling technologies ? > > Which means that this "new tool" also involved a Google controlled > subCA signing these certificates with, as it turns out, the wrong SCTs > in them. It's not clear to me if the tool and CA are operationally one > and the same. > > Q1: Could a more significant "coding error" in this tool have resulted > in certificates being mis-issued (for example with SANs that don't > belong to Google, or lacking mandatory X.509 fields, or without being > CT logged)? If not please explain why the tool couldn't cause this. > > Q2: If this error hadn't caused a negative end-user experience, what > mechanisms if any do you believe would have brought it to your > attention and how soon? e.g. does a team sample resulting certificates > from this tool at some interval? If it samples pre-certificates that > would not have detected this error, but is worth mentioning. > > Q3: Such mistakes are of course inevitable in software development. But > they could also be introduced maliciously. Were you able to confidently > identify which specific individual(s) made the relevant change? (I don't > want names). Are you confident you'd be able to do this even if somehow > the production tool turned out not to match your revision control > systems? > > Thanks as always for satisfying my curiosity > > Nick. >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
