On 07/09/2016 16:01, Thijs Alkemade wrote:
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.
Wait, are you saying the certificates themselves contain embedded SCT
entries dated after the notBefore date? If so, that would be
cryptographic evidence that the certificates were signed after those
SCT entries were generated.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
