On 06/09/16 19:12, Thijs Alkemade wrote: <snip> > Hello, > > We obtained 2 certificates from the StartEncrypt API which had SHA-1 > signatures and which were backdated to December 20, 2015. > > After WoSign announced that all certificates issued in 2015 were logged to > their Certificate Transparency server, I analyzed them to check if any other > certificates using SHA-1 signatures show signs of being backdated. Using the > Python tools from Google’s Certificate Transparency repository I downloaded > all certificates from the log and then queried them from an sqlite database. > Considering this is the first time I’m working with Certificate Transparency > logs, it might be better if someone else tries to reproduce my results. I’ve > generated a table here: > https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 > (timestamps are in UTC). > > I found 1204 certificates with a SHA-1 signature issued after December 1, > 2015. 53 of them included embedded SCT data, so can be dated more accurately. > > The most interesting pattern I noticed was from sorting the certificates > based on the ID they have in WoSign’s Certificate Transparency log. Up to ID > 109149 > (https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a), > the notBefore values are (approximately) chronologically ordered. Those > which have embedded SCTs have timestamps which are about 2 hours later than > the notBefore date.
Hi Thijs. I agree that this pattern is interesting (and it'd be nice to see an explanation), but I'm not convinced that it proves everything you think it proves. > But after that follow 64 certificates which are all dated on December 20, > 2015 (CST, UTC+8), including our two test certificates. Six of these have > embedded SCT data, but they have a large discrepancy between the notBefore > and the earliest SCT: 3 have a SCT of December 31 (11 days later) and 1 even > has a SCT of January 18, 2016, almost a full month after the notBefore. > (Unless I misunderstand the use of pre-certificates, this by itself already > implies the certificate was signed using SHA-1 on or after January 18, 2016.) Yes. A certificate that has embedded SCTs cannot have been issued any earlier than any of the timestamps in those embedded SCTs (assuming those timestamps are accurate, of course). Of course, "implies...was signed...after" is only demonstrably true when you have a copy of both the precertificate and the corresponding certificate. You can't prove it if you only have a copy of the precertificate; the signature on a precertificate "indicates the certificate authority's intent to issue a certificate" [RFC6962 section 3.1], but this doesn't mean the CA is required to issue the certificate. > Aside from the 3 embedded SCTs on December 31, none of these certificates > have been logged to a Certificate Transparency server before January 1, 2016. When a precertificate is logged, there is no need for the corresponding certificate to be logged. If the corresponding certificate does get logged at some point later, so what? Let's look at one of your examples: aceeccdbb17b9096251dd11a84041ec75fe7a92e903ffe07c6d6b0a0c980d399 The fact that the certificate (https://crt.sh/?id=12367098) wasn't logged until late January 2016 is uninteresting, because the precertificate (https://crt.sh/?id=11751158) was logged on (and has a notBefore date of) 31st December 2015. Except for EV, certificates issued by WoSign aren't required (by Chrome) to be logged. If a certificate (for which there is no corresponding precertificate) does get logged at some point long after its issuance date, so what? Let's look at one of your examples: 61b6289b1d3786e8f362e4049a4c5e24bb1356c0776fadb3a8a569f99d071a98 I see no evidence to suggest that this certificate was not issued on 30th December 2015, as suggested by its notBefore date. <snip> -- 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
