CA/WoSign Issues: Difference between revisions

CA/WoSign Issues (view source)

Revision as of 13:23, 8 September 2016

930 bytes removed , 8 September 2016

→‎Issue S: Backdated SHA-1 Certs (January 2016)

Gerv

Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti

4,925

edits

@@ Line 239: / Line 239: @@
 For these 62, the notBefore date is some time between midnight and midnight on December 20th 2015, China time (+0800). (This pattern fits a system where code adjusted the date, but not the time, prior to issuance.) Here are five more examples: [https://crt.sh/?id=30741722 1], [https://crt.sh/?id=30741724 2], [https://crt.sh/?id=30773614 3], [https://crt.sh/?id=30773616 4], [https://crt.sh/?id=30773644 5].
-Secondly, the ID of certificates in WoSign's CT log can be used to show the logging sequence of a set of certificates even if they don't have embedded SCTs, because the IDs are sequential. If you order all certs in WoSign's log by ID, up to [https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a ID 109149], where the notBefore is on December 31st, the notBefore values are (approximately) chronologically ordered. Those which have embedded SCTs have timestamps which are about 2 hours later than the notBefore date. But after that follow 64 certificates which are all dated on December 20, 2015 (CST, UTC+8). This suggests that these were logged at the actual time of issuance but that time is not reflected in their notBefore date - i.e. they were backdated. And it further suggests that this behaviour only began after December 31st 2015, i.e. it was not a continuation of some previous behaviour.
+Secondly, some certificates which are suspected to be backdated were issued at the same time as SHA-256 certificates for the same domain; the timestamps on the SHA-256 certificates are more likely to be the accurate ones. One example is for congfubao.com, where there is a [https://crt.sh/?id=11900532 SHA-256 cert] with a notBefore of 5th January and an SCT timestamp of 5th January, 17 seconds later than the SCT timestamp in the [https://crt.sh/?id=30773528 backdated SHA-1 cert]. The simplest explanation is that both certs were issued together, on January 5th. Other pairs include for ebank.pcnkbank.com ([https://crt.sh/?id=30773634 SHA-1], [https://crt.sh/?id=15425430 SHA-256]) and mail.gd.gov.cn ([https://crt.sh/?id=12356371 SHA-1], [https://crt.sh/?id=12362293 SHA-256]).
-Thirdly, some certificates which are suspected to be backdated were issued at the same time as SHA-256 certificates for the same domain; the timestamps on the SHA-256 certificates are more likely to be the accurate ones. One example is for congfubao.com, where there is a [https://crt.sh/?id=11900532 SHA-256 cert] with a notBefore of 5th January and an SCT timestamp of 5th January, 17 seconds later than the SCT timestamp in the [https://crt.sh/?id=30773528 backdated SHA-1 cert]. The simplest explanation is that both certs were issued together, on January 5th. Other pairs include for ebank.pcnkbank.com ([https://crt.sh/?id=30773634 SHA-1], [https://crt.sh/?id=15425430 SHA-256]) and mail.gd.gov.cn ([https://crt.sh/?id=12356371 SHA-1], [https://crt.sh/?id=12362293 SHA-256]).
 Lastly, of the 62 suspect certs, there are three more certs with embedded SCTs where the gap between the notBefore date and the SCT date is multiple days (i.e. they were backdated, and this is cryptographically provable) but where the SCT date is nevertheless (just) before 1st January 2016, which means the backdating would not have the effect of avoiding browser blocks.