Attachments

(1 attachment)

The following was reported by Christiaan Ottow on July 1, 2016, in the mozilla.dev.security.policy forum.
""
If you plan on checking CT logs, make sure to check WoSign-signed certs as well. The "caID" parameter in the POST request to the StartEncrypt API allows you to select which CA will sign you certificate. The default, "2", makes that your request is signed by "StartCom Class 1 DV Server CA", "1" selects "WoSign CA Free SSL Certificate G2" and "0" selects "CA 沃通根证书". Perhaps the certificates are being logged into a different CT audit server because of this feature.
We selected "1" for a test certificate last week, and the certificate we obtained was dated 20 December 2015, and signed using a SHA-1 checksum. I've attached the certificate (excluding modulus and signature). The checksum (SHA256) of the full cert is D1:2F:AB:12:E2:40:70:40:B4:2B:FF:46:FF:9B:A8:BB:8C:1F:63:E4:7F:ED:F2:D3:70:D2:12:3B:54:28:D1:4B
""
Of particular note, WoSign has issued SSL certs that have a backdated issuance date, and are SHA-1.

Richard (of WoSign), please reply in this bug to the following questions as soon as possible.
1) When were you notified of this problem, and when was the problem contained/resolved?
2) What analysis have you done to determine which SHA-1 and backdated SSL certificates were issued?
Presumably, if Christiaan Ottow was able to use that API, anyone on the internet could have been using that API.
3) Please provide the information (in this bug) about which mis-issued certificates should be added to OneCRL.
4) What actions have and will you be taking to fully resolve the noted problems?
What is the timeline that you are targeting for implementation/resolution?

(In reply to Kathleen Wilson from comment #1)
> Richard (of WoSign), please reply in this bug to the following questions as
> soon as possible.
>
> 1) When were you notified of this problem, and when was the problem
> contained/resolved?
We got report from Computest before Computest public this bug, after we get this bug report, we checked that no anyone use this bug except Computest, we deleted the discard API parameter, and also ask StartCom stop to use this API. Here is the details:
+-----------------------------------------------------------------------------------------------------------
* domain | source IP | serial Number | requet time | issue time | Client |
------------------------------------------------------------------------------------------------------------
* startssl9.s.xnyhps.nl | 46.19.32.61 |6565e1710a48fbbe1e2b61835c789c39 | 2016-06-23 16:28:33 | 2016-06-23 16:28:37 | ssl_fairy-1.0.0-Linux.x86_64 StartEncrypt |
------------------------------------------------------------------------------------------------------------
* startssl9.s.xnyhps.nl | 46.19.32.61 |6745ed57fe25880fb7d93a774310cf59 | 2016-06-28 16:41:17 | 2016-06-28 16:41:19 | ssl_fairy-1.0.0-Linux.x86_64 StartEncrypt |
------------------------------------------------------------------------------------------------------------
> 2) What analysis have you done to determine which SHA-1 and backdated SSL
> certificates were issued?
> Presumably, if Christiaan Ottow was able to use that API, anyone on the
> internet could have been using that API.
Yes, anyone can use this bug to issue backdated SSL certificate that the issuance time is Dec 20, 2015, this date is the day we stop to use this code.
Luckily, we checked our PKI system that only two test cert from Computest issued this kind of certificate, no any one found this bug due to the API released less than one month.
this is non-used, non-public API parameter that Computest guess out.
> 3) Please provide the information (in this bug) about which mis-issued
> certificates should be added to OneCRL.
Only two test cert is issued that Computest don't use it, the two cert is attached in attachment 8779147[details]. I don't think it is need to add to OneCRL, we have revoked it.
> 4) What actions have and will you be taking to fully resolve the noted
> problems?
> What is the timeline that you are targeting for implementation/resolution?
After we got report from Computest, we delete this non-used API parameter, and stop this API in server side that no any one can call this API. And we also notice StartCom stop to use this API. StartCom also stop the StartEncrypt service that plan to use ACME protocol for the future version at July 4th.

To prevent the mis-issuance in the future, WoSign is logged all issued SSL certificates to Google log server and other log servers for full transparency: https://www.wosign.com/english/News/2016_wosign_CT.htm
For browsers, if any SSL certificate issued by WoSign after July 5th, 2016 that don’t include SCT data, browsers can distrust this SSL certificate and report to us as an incident. For WoSign customers, if you find the SSL certificate don’t include the SCT data, then you can refuse to accept it and ask for re-issuance or ask for refund, including free SSL certificate and charged certificate, including DV SSL, IV SSL, OV SSL and EV SSL certificate.