On 07 Sep 2016, at 14:52, Rob Stradling <rob.stradl...@comodo.com> wrote: > > 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.
Hi Rob, That makes sense, thanks. >> 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. Both of these are not examples of the certificates which I consider suspicious. To be precise, the suspicious certificates have: - A SHA-1 signature from WoSign. - A notBefore date on December 20, 2015 (CST). - An ID in the WoSign Certificate Transparency log ≥ 109153. In the gist which I posted, this is line 4 up to 65. The fact that these certificates weren’t logged to public Certificate Transparency servers soon after is not suspicious and I did not intend it as such. It was only meant to indicate the lack of evidence that could have proven their timestamps. What is suspicious is: - Twice as many SHA-1 certificates being issued on a specific Sunday in December than the daily average that month. (Which also happens to be the date on the certificates which I personally got from the StartEncrypt API.) - The long difference between the notBefore and the embedded SCTs, if any. - Some of these certificates having an almost identical copy issued using SHA-256 on a date in January. If the SHA-1 cert has embedded SCTs, then the SHA-256 cert has them too and the SCTs of both certs are less than a minute apart. Of course, I can’t present hard cryptographic evidence that these certificates did not exist then, but I fear nothing can. Best regards, Thijs Alkemade Computest • Pine Digital Security E: talkem...@computest.nl • I: www.computest.nl A: Signaalrood 25 • 2718 SH Zoetermeer Pine Digital Security is part of Computest _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
