RE: Incidents involving the CA WoSign

[Richard Wang]

For security, the notBefore time is not the exact time of signing, random from 
20 minutes to 40 minutes ahead.

For 6 long delta time, we said it is a CT Post System bug;
For 2016-07-30 between 05:20 and 07:40 (CST), it is caused by the Internet 
connection problem from China to Google CT log server that need to resign after 
the internet connection is ok.
For normal case, it is OK, good.

Thanks.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, September 22, 2016 12:32 PM
To: Richard Wang 
Cc: Gervase Markham ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Wed, Sep 21, 2016 at 9:10 PM, Richard Wang  wrote:
>> Are you saying out of over 40,000 orders over the last year, only six 
>> "stopped to move forward" for a period of a week or more and these happen to 
>> all have been ordered on Sunday, December 20, 2015 (China time)?
>
> You mean we issued 40,000 certificates at Dec 20, 2015?

No, there slightly over 40418 certificates issued by CAs under the WoSign roots 
which have embedded Signed Certificate Timestamps.  They were issued over the 
course of approximately one year; the earliest notBefore date is 
2015-08-20T09:40:48Z and my CT data set was up to date as of 2015-09-05.

Of these 40418 certificates, 40394 had a delta between notBefore and the 
earliest SCT is less than 3 hours. Eighteen certificates have a delta between 5 
hours and 51 hours; all 18 of these have a notBefore on 2016-07-30 between 
05:20 and 07:40 (CST). The remaining 6 certificates have a delta of between 
262.3 hours (10.9 days) and 693.7 hours (28.9 days).  All six of these have a 
notBefore on 2015-12-20 (CST).

For with it is worth, the largest difference between the earliest embedded 
timestamp and the latest is less than 15 minutes in all certificates.

> We issued SHA-1 certificate at every day, Dec 20 is not a special day, why 
> you care about this day is Computest get the SHA-1 certificate used this date 
> that we still don't know how he get this, so we closed this API completely, 
> even deleted the API domain resolution.

I'm looking at all WoSign issued certificates, ignoring the hash algorithm used 
in the signature.  Two dates have certificates that are clear outliers when 
measuring the difference between notBefore and the timestamps.  I'm wondering 
what is special about these dates or these certificates.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Peter Bowen]

On Wed, Sep 21, 2016 at 9:10 PM, Richard Wang  wrote:
>> Are you saying out of over 40,000 orders over the last year, only six 
>> "stopped to move forward" for a period of a week or more and these happen to 
>> all have been ordered on Sunday, December 20, 2015 (China time)?
>
> You mean we issued 40,000 certificates at Dec 20, 2015?

No, there slightly over 40418 certificates issued by CAs under the
WoSign roots which have embedded Signed Certificate Timestamps.  They
were issued over the course of approximately one year; the earliest
notBefore date is 2015-08-20T09:40:48Z and my CT data set was up to
date as of 2015-09-05.

Of these 40418 certificates, 40394 had a delta between notBefore and
the earliest SCT is less than 3 hours. Eighteen certificates have a
delta between 5 hours and 51 hours; all 18 of these have a notBefore
on 2016-07-30 between 05:20 and 07:40 (CST). The remaining 6
certificates have a delta of between 262.3 hours (10.9 days) and 693.7
hours (28.9 days).  All six of these have a notBefore on 2015-12-20
(CST).

For with it is worth, the largest difference between the earliest
embedded timestamp and the latest is less than 15 minutes in all
certificates.

> We issued SHA-1 certificate at every day, Dec 20 is not a special day, why 
> you care about this day is Computest get the SHA-1 certificate used this date 
> that we still don't know how he get this, so we closed this API completely, 
> even deleted the API domain resolution.

I'm looking at all WoSign issued certificates, ignoring the hash
algorithm used in the signature.  Two dates have certificates that are
clear outliers when measuring the difference between notBefore and the
timestamps.  I'm wondering what is special about these dates or these
certificates.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

> Are you saying out of over 40,000 orders over the last year, only six 
> "stopped to move forward" for a period of a week or more and these happen to 
> all have been ordered on Sunday, December 20, 2015 (China time)?

You mean we issued 40,000 certificates at Dec 20, 2015?

Here is the last two weeks in 2015 issued SSL certificates statistics that I 
send it to Gerv:

   WEEK FRI SAT SUN MON TUE WED THU FRI 
SAT SUN MON TUE WED THU
Dec. 2015   18  19  20  21  22  23  24  25  
26  27  28  29  30  31
Issued No   419 321 278 348 746 463 407 424 
294 257 424 380 506 344
SHA-1 Cert  39  24  46  18  43  29  31  25  
3   0   29  31  37  13
SHA-2 Cert  380 297 232 330 703 434 376 399 
291 257 395 349 469 331


We issued SHA-1 certificate at every day, Dec 20 is not a special day, why you 
care about this day is Computest get the SHA-1 certificate used this date that 
we still don't know how he get this, so we closed this API completely, even 
deleted the API domain resolution.


Best Regards,

Richard


>Thanks,
 wrote:
> Hi Gerv,
>
> See below inline, thanks.
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Gervase Markham
> Sent: Wednesday, September 21, 2016 9:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> Hi Richard,
>
> Thanks for the additional information.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Second Discussion of LuxTrust Root Inclusion Request

[Ryan Sleevi]

On Friday, September 16, 2016 at 1:13:38 PM UTC-7, Kathleen Wilson wrote:
> On Thursday, September 8, 2016 at 9:07:33 AM UTC-7, Kathleen Wilson wrote:
> > Does anyone have comments, questions, or concerns about this request from 
> > LuxTrust to include the "LuxTrust Global Root 2" certificate, turn on the 
> > Websites trust bit, and enable EV treatment?
> > 
> > If not, I will close this discussion and recommend approval in the bug.
> 
> 
> I am leaving this discussion open, due to a request for more time to review 
> and comment on this CA's updated CP/CPS.

Hi Kathleen,

I've reviewed this CP/CPS set again, keeping in mind the previous comments on 
the first round of discussion, and I don't believe there's anything noted that 
should prevent this inclusion from continuing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

Thanks for your good test to have an experience to know more how we work.

What I told Gerv that you can place an order at our site today -- Sept. 22nd 
2016, but DON'T do the domain validation, leave it here. Four months later, you 
login your account to finish the domain validation, then system will post to CT 
log server to get SCT data, then the cert issued data is Jan 22nd 2017, the 
cert notBefore is Jan 22nd 2017. But the order data in our system is Sept 22nd 
2016. 

This is for explanation that Gerv ask why the order time is four month ago- Aug 
15th, but the notBefore (the issuance day) is Dec. 20th for a free DV SSL 
certificate that take so long time.

I wish I said this clearly, thanks.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, September 22, 2016 11:38 AM
To: Richard Wang 
Cc: Gervase Markham ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

I'm having a really hard time reconciling what you describe with what is found 
in the CT logs and what I observed today when doing as you suggested and 
getting a cert from https://buy.wosign.com/free/.

I pulled all the WoSign certificates from CT logs that have embedded SCTs.  
There are 40418 such certificates (as of a few days ago), of which 898 are EV 
certificates.  For the EV certificates, other than the six that were raised as 
potentially being backdated, the delta between the notBefore date and the 
earliest SCT embedded in the certificate ranged from 1130.54 to 9949.10 
seconds.  890 of the 898 EV certificates had a delta under one hour.  When 
looking at the full set of 40418, the delta ranges from 1128.91 to 182896.75 
seconds.  All the certificates with a delta greater than 1 seconds have a 
notBefore date of 2016-07-29, again with the exception of the six certificates 
Gerv raised.

Are you saying out of over 40,000 orders over the last year, only six "stopped 
to move forward" for a period of a week or more and these happen to all have 
been ordered on Sunday, December 20, 2015 (China time)?

I also would like to get your feedback on the timeline I observed today when I 
get a certificate at the site you suggested.  Here is what I observed (ordered 
by time):
2015-09-21 15:31UTC Order created
2015-09-21 19:58UTC Domain Validated
2015-09-21 20:05UTC Uploaded CSR (sorry, failed to log time,
approximate time)
State moved to "Pending" (shortly after uploading CSR)
2016-09-21 23:10:42 UTC Certificate NotBefore
2016-09-21 23:36:32 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:35 UTC WoSign Log SCT (using precertificate)
2016-09-21 23:37:08 UTC Date header on Certificate ready for collection email

Mail received headers: 23:37:13 (by mta1.wosign.com), 23:37:44 (by 
mx.google.com).

It would appear that the NotBefore was not set until after I completed 
validation, uploaded a CSR, and the order passed other (possibly
human) checks. From that point it was less than half an hour until I had my 
certificate.  Is this the behaviour you expect to see?

Thanks,
Peter

On Wed, Sep 21, 2016 at 7:26 AM, Richard Wang  wrote:
> Hi Gerv,
>
> See below inline, thanks.
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Gervase Markham
> Sent: Wednesday, September 21, 2016 9:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> Hi Richard,
>
> Thanks for the additional information.
>
> On 21/09/16 11:11, Richard Wang wrote:
>> Some SHA-1 certificate is free SSL certificate that no any reason for 
>> us to help them get the SHA-1 certificate if we are intentional, and 
>> some certificate is even never used or even not retrieved from our 
>> system, this also can be certified it is a normal order without any 
>> doubt.
>
> I have examined the spreadsheet you sent (note: may not be available to 
> mozilla.dev.security.policy participants due to lack of attachment support). 
> The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
> contains 12 certificates, which have no cost associated with them, and no 
> identity vetting other than domain control. Why did each of these take over a 
> month, and in some cases nearly 4 months, to be issued? What was the hold-up?
> -
> R: You can place order there and don't do the domain validation, 4 
> months later, you finished the domain control validation, then issue 
> the certificate. Please try it by yourself here: 
> https://buy.wosign.com/free/
> --
>> I think there are many reasons to stop to sign it due to double 
>> check, for EV order, it must pass at least 6 person’s 

Re: Incidents involving the CA WoSign

[Peter Bowen]

Richard,

I'm having a really hard time reconciling what you describe with what
is found in the CT logs and what I observed today when doing as you
suggested and getting a cert from https://buy.wosign.com/free/.

I pulled all the WoSign certificates from CT logs that have embedded
SCTs.  There are 40418 such certificates (as of a few days ago), of
which 898 are EV certificates.  For the EV certificates, other than
the six that were raised as potentially being backdated, the delta
between the notBefore date and the earliest SCT embedded in the
certificate ranged from 1130.54 to 9949.10 seconds.  890 of the 898 EV
certificates had a delta under one hour.  When looking at the full set
of 40418, the delta ranges from 1128.91 to 182896.75 seconds.  All the
certificates with a delta greater than 1 seconds have a notBefore
date of 2016-07-29, again with the exception of the six certificates
Gerv raised.

Are you saying out of over 40,000 orders over the last year, only six
"stopped to move forward" for a period of a week or more and these
happen to all have been ordered on Sunday, December 20, 2015 (China
time)?

I also would like to get your feedback on the timeline I observed
today when I get a certificate at the site you suggested.  Here is
what I observed (ordered by time):
2015-09-21 15:31UTC Order created
2015-09-21 19:58UTC Domain Validated
2015-09-21 20:05UTC Uploaded CSR (sorry, failed to log time,
approximate time)
State moved to "Pending" (shortly after uploading CSR)
2016-09-21 23:10:42 UTC Certificate NotBefore
2016-09-21 23:36:32 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:33 UTC Log SCT (using precertificate)
2016-09-21 23:36:35 UTC WoSign Log SCT (using precertificate)
2016-09-21 23:37:08 UTC Date header on Certificate ready for collection email

Mail received headers: 23:37:13 (by mta1.wosign.com), 23:37:44 (by
mx.google.com).

It would appear that the NotBefore was not set until after I completed
validation, uploaded a CSR, and the order passed other (possibly
human) checks. From that point it was less than half an hour until I
had my certificate.  Is this the behaviour you expect to see?

Thanks,
Peter

On Wed, Sep 21, 2016 at 7:26 AM, Richard Wang  wrote:
> Hi Gerv,
>
> See below inline, thanks.
>
> Regards,
>
> Richard
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Gervase Markham
> Sent: Wednesday, September 21, 2016 9:19 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
>
> Hi Richard,
>
> Thanks for the additional information.
>
> On 21/09/16 11:11, Richard Wang wrote:
>> Some SHA-1 certificate is free SSL certificate that no any reason for
>> us to help them get the SHA-1 certificate if we are intentional, and
>> some certificate is even never used or even not retrieved from our
>> system, this also can be certified it is a normal order without any
>> doubt.
>
> I have examined the spreadsheet you sent (note: may not be available to 
> mozilla.dev.security.policy participants due to lack of attachment support). 
> The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
> contains 12 certificates, which have no cost associated with them, and no 
> identity vetting other than domain control. Why did each of these take over a 
> month, and in some cases nearly 4 months, to be issued? What was the hold-up?
> -
> R: You can place order there and don't do the domain validation, 4 months 
> later, you finished the domain control validation, then issue the 
> certificate. Please try it by yourself here: https://buy.wosign.com/free/
> --
>> I think there are many reasons to stop to sign it due to double check,
>> for EV order, it must pass at least 6 person’s check:
>
> Yes, indeed. But at what point during these checks do the following events 
> happen?
>
> A) Pre-cert is created and signed (if needed)
> B) Pre-cert is sent to CT (if needed)
> C) Real cert is created and signed
> D) Cert is sent to the customer
>
> I would expect none of these things to happen until all checks are completed. 
> We know from previous conversations that your step 7 (next day review) 
> happens after C) and D). Where do those four events fit into your seven 
> steps, exactly?
> -
> R: not of all. The process is stopped after pre-signed the cert but not post 
> to CT log server.
> -
>> Not the case, only one simple bug from CT Post system. I try to say
>> more clearly.
>> https://crt.sh/?serial=6D24E483E27F55479C5C555B37745353 is ordered in
>> 19th Dec. 2015, and system pre-signed the pre-cert using SHA-1, no any
>> problem. But it is stopped due to some more check. At 4th Jan.
>> 2016, this order finished the final check and go to signing server,
>> signing 

Re: Time to distrust (was: Sanctions short of distrust)

[Peter Kurrasch]

  Well, well. Here we are again, Ryan, with you launching into a bullying, personal attack on me instead of seeking to understand where I'm coming from and why I say the things I say. You may have noticed that I do not reply to your messages because I generally find your tone to be disrespectful of others and occasionally narrow-minded. This time, however, I will reply.‎You know nothing of my knowledge, my experience, or the things that I need to be taught. You are not the arbiter of what is reasonable or sensible in this forum. I hardly think you are the one person in here to determine if people agree or disagree with me--and, for that matter, who qualifies as an expert. If Kathleen or Gerv or Richard decide that I'm disruptive and not providing any value to the wider population, I'll happily withdraw from this forum. I participate here because I enjoy it, though I obviously don't enjoy being attacked personally.‎If I am a fool, let me be a fool. If I say things that don't make sense and you seek to know why, ask me questions. If you see no value in what I have to say, so be it; others in this forum might think otherwise. That's all I ask of anyone.From: Ryan SleeviSent: Wednesday, September 21, 2016 2:27 PM‎...snip...It's unclear who you're referring to here. I think, judging by some of your replies, that some of the experts in this space don't agree with you or your conclusions, but this may simply be a teachable opportunity.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[wangsn1206]

> Dear Peter,  Thanks for your comments! We think that there are some good 
> suggestions for our work. We’ll take notes and do better in our future work. 
> >> We have discussed these questions with our auditor. Here are our reply to 
> your comments: > 
> - The basic WebTrust for CA Report does not cover controls that provide 
> assurance that subordinate CA certificate requests are accurate, 
> authenticated, and approved (the management assertion does, so this indicates 
> the auditor might have found issues with the controls) > Reply: We've 
> communicated with our auditor, they said that in the period of time report, 
> we did not generate any subordinate certificates, which means that no 
> subordinate certificate request happened during the audit period. So that the 
> subordinate certificate request did not be mentioned in the audit report. >>  
> - The basic WebTrust for CA Management assertion does not include Subordinate 
> CA [cross-]certification in the list of CA services. > Reply: We do not have 
> any external sub-CAs, so it’s no need to include the cross-certs in the list. 
> >>  - The basic WebTrust for CA Management assertion does not include 
> "Subordinate CA Certificate Lifecycle Management Controls" in the list of 
> portions of criteria used > Reply: We do not have any external sub-CAs, so 
> it’s not applicable.
You have one or more CAs that have a non-zero path constraint. Therefore they 
are able to issue certificates to subordinate CAs, whether operated by your 
organization or externally operated. As such, it is important that the CA have 
controls around issuing CA certificates and that the auditor has reasonable 
assurance the controls function as designed.

Reply: We’ve communicated with our auditor and knew that they always performed 
design effectiveness audit to all of our controls, include controls around 
issuing CA certificates. As there is no subordinate certificate request 
happened during the audit period, it was not mentioned in the audit report. 
It’s a good suggestion, they would specify the controls around issuing CA 
certificates in the future report no matter if it happens. 


> - After the reporting period ended, GDCA issued at least two new subordinate 
> CA certificates from the R5 root.  These use the organization name of "Global 
> Digital Cybersecurity Authority Co., Ltd." and have keys and key IDs that are 
> identical to those found in CA certificates for GUANG DONG CERTIFICATE 
> AUTHORITY CO.,LTD.  This is problematic as re-use of key IDs with different 
> issuer names causes problems on some platforms.  Additionally the separate DN 
> means it is out of scope for the submitted report.  Combined with the lack of 
> audited controls around subordinate CA management, CAs outside of the scope 
> of the report may be a significant concern. > Reply: Our company has changed 
> the name from “GUANG DONG CERTIFICATE AUTHORITY CO.,LTD.” to “Global Digital 
> Cybersecurity Authority Co., Ltd.” in this year, which was after the period 
> in time audit. We have informed the Mozilla of the name change in advance. We 
> also announced the name change to the public in our official website. 
I understand it was a name change.  However you issued new CA certificates with 
the new name which means you do issue CA certificates from time to time. 
Reply: The issuing of new CA certificates was after the period of audit report. 
We’ve informed Mozilla of the situation that we’ve issued new CA certificates 
which only changed the DN because of our company’s name change to facilitate 
our customers' use. During the issuing process, we also consulted our auditor 
about the format of new CA certificates. Also, if we don't change the DN of 
certificates, it will be difficult for browser users to confirm the identity of 
us when they visit the website whose certificate was signed by us because the 
CA name in certificate is “Guangdong certificate…” while our actual name is 
“Global Digital…”. It may cause unnecessary puzzle to browser users. 


> - The Baseline + Network Security Requirements report and management 
> assertion only covers two of the CAs. However the cross-certs issued by the 
> root to the subordinate CAs do not include EKU constraints, so the 
> subordinate CAs are capable of issuing server authentication ("SSL") 
> certificates.  The assertion and report should include all CAs that are 
> capable of issuing server authentication certificates. 
> Reply: We do not have any external sub-CAs.

The question is not whether you have external sub-CAs, but whether all the CAs 
that are subordinate to your root have controls around issuance of server 
authentication certificates.

Reply: Our CA system has realized the control that only appointed CA 
certificates can issue SSL certificates. We’ve communicated with our auditor 
and confirmed that the control effectiveness has been covered in their audit 
work. So only CA certificates mentioned in the management 

Sanctions short of distrust

[Richard Wang]

I know WoSign make some mistakes in 2015, and I accept any reasonable fair 
enough sanction. But WoSign will continue to do our best to provide best 
products and best service to worldwide customers, no matter what the sanction 
is.
Here is the answer for your questions:

> Do we trust that WoSign will honor requests for certs to be revoked?

Yes, we honor your requests for certs to be revoked for FREE according to our 
CPS. We used Akamai CDN for worldwide customer to provide best CRL/OCSP service.

> Do we trust that revocation will take place in a timely matter?

Yes, we will take place your revocation request in a timely matter that exceed 
your expectation – within 24 hours (24 x 365 non-stop).

> Do we trust that WoSign will not collect information on hits to any OCSP 
> responders they have set up and share that info with...whomever?

Yes, any CA can do this if need. But you can use OCSP Stapling in your web 
server.
We don’t worry about most China online banking system and many ecommerce 
website using the foreign CA certificate, what do you worry about? As I said, 
we used Akamai CDN service that all hits will go to Akamai Edge servers first.


Best Regards,

Richard Wang
CEO
WoSign CA limited


From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Kurrasch
Sent: Thursday, September 22, 2016 3:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Time to distrust (was: Sanctions short of distrust)

Do we trust that WoSign will honor requsts for certs to be revoked? Do we trust 
that revocation will take place in a timely matter? Do we trust that WoSign 
will not collect information on hits to any OCSP responders they have set up 
and share that info with...whomever?

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sanctions short of distrust

[Rob Stradling]

On 21/09/16 15:06, Rob Stradling wrote:

> I ran some queries earlier today on the crt.sh DB, to find all CNs,
> dNSNames and iPAddresses in all unexpired certs whose issuer names
> include either "WoSign" or "StartCom".  Then I cross-referenced that
> with the latest PSL data to discover the unique base domains:

Someone contacted me off-list (thanks!) to point out that my lists were
incomplete.  I'd missed a load of base domains delegated below the new
gTLDs.  (I hadn't spotted that my local copy of
https://data.iana.org/TLD/tlds-alpha-by-domain.txt was rather out of date).

Updated count and gists...

WoSign:
  Unique Base Domains: 127,355

StartCom:
  Unique Base Domains: 259,712

https://gist.githubusercontent.com/robstradling/813138699b8527c1af58b4aa784c2d8f/raw/11fc8efbb0e594a12b3c5e2e76d9a9e474e24ea9/wosign_base_domains.txt

https://gist.githubusercontent.com/robstradling/813138699b8527c1af58b4aa784c2d8f/raw/11fc8efbb0e594a12b3c5e2e76d9a9e474e24ea9/startcom_base_domains.txt

> WoSign:
>   Unique CNs/dNSNames: 395,222
>   Unique Base Domains: 118,785
>   Unique IP Addresses: 154
> 
> StartCom:
>   Unique CNs/dNSNames: 706,020
>   Unique Base Domains: 249,841
>   Unique IP Addresses: 0


-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed.  If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Time to distrust (was: Sanctions short of distrust)

[Ryan Sleevi]

On Wednesday, September 21, 2016 at 12:05:49 PM UTC-7, Peter Kurrasch wrote:
> I have a hard time seeing how any sort of white list solution will actually 
> mitigate any of the bad behavior exhibited by WoSign. 

This doesn't help understand where your disconnect is, or how we might educate 
and inform you about different perspectives.

> So the problem I have with a white list is the implication that while we 
> don't trust the CA to issue new certs, we do have trust in the continued 
> operation of other parts of the CA. 

Once a certificate is issued, it's issued. What continued operations, beyond 
revocation (which doesn't work in the Web PKI) do you see as necessary?
 
> I'm just having a hard time seeing how there is anything left to trust when 
> it comes to WoSign. Maybe the best outcome would be a finding of 
> irreconcilable differences and for us to go our separate ways? Maybe we just 
> want different things in a global PKI system?

It's unclear who you're referring to here. I think, judging by some of your 
replies, that some of the experts in this space don't agree with you or your 
conclusions, but this may simply be a teachable opportunity.

To try to explain to you:
A wholesale distrust is, in effect, a statement that we believe no certificate, 
past, present, or future, is trustworthy. This is a very strong statement, and 
it's very hard to make, even under significant evidence, but is sometimes 
necessary (for example, when an unknown number of unconstrained sub-CAs have 
been issued).

However, if you're willing to believe that no unconstrained sub-CAs exist, and 
if you're willing to accept that most, but not all, certificates were issued 
according to the policies and community expectations, then such a statement is 
overly harsh. By overly harsh, I'm not considering the reception of the CA, I'm 
considering the message that browser vendors would be sending to users and to 
sites that have chosen to use such certificates.

For example, do you believe that if a user tries to access 
https://www.wosign.com, they should be shown an interstitial? Do you believe 
that is a helpful message to end users? Do we believe that the specific 
certificate is untrustworthy?

In most CA cases, when evidence of malfeasance is discovered, it's not 100% of 
the certificates. It might be .001%. But that .001% is significant enough to be 
uncomfortable to trust NEW certificates, because that margin is too high. 
Further, once disclosed via CT, we can reasonably be confident that EXISTING 
certificates conform to appropriate policies.

The only continuinity of business that a CA would potentially need to provide, 
in the event of a distrusting, is OCSP and CRLs. And we know those simply don't 
work at the WebPKI, which is why CRLSets and OneCRL and Certificate Distrust 
List exists. So I have trouble with your suggestion that a whitelist is an 
indication of continued trust in a CA, other than it's a recognition of the 
fact: "Most" of the certs are probably OK, but "new" certs have too high a 
margin of risk to continue to be accepted.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Time to distrust (was: Sanctions short of distrust)

[Peter Kurrasch]

  I have a hard time seeing how any sort of white list solution will actually mitigate any of the bad behavior exhibited by WoSign. From my perspective, I think we can make a pretty clear case that WoSign is a poorly run CA and poses a threat to the secure Internet that many of us are trying to achieve. They have many, serious bugs in their systems. Their responsiveness in fixing these problems is slow. Their understanding of security threats is limited. Their interest in compliance seems minimal.‎ Their willingness to be forthright, honest, open in this forum can only be described as unacceptable. So the problem I have with a white list is the implication that while we don't trust the CA to issue new certs, we do have trust in the continued operation of other parts of the CA. Chief among these is revocation as cert holders move away from WoSign to a new CA. Do we trust that WoSign will honor requsts for certs to be revoked? Do we trust that revocation will take place in a timely matter? Do we trust that WoSign will not collect information on hits to any OCSP responders they have set up and share that info with...whomever?I'm just having a hard time seeing how there is anything left to trust when it comes to WoSign. Maybe the best outcome would be a finding of irreconcilable differences and for us to go our separate ways? Maybe we just want different things in a global PKI system?From: Peter BowenSent: Wednesday, September 21, 2016 10:04 AMTo: Gervase MarkhamCc: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Sanctions short of distrustOn Wed, Sep 21, 2016 at 2:21 AM, Gervase Markham  wrote:> On 12/09/16 22:46, Ryan Sleevi wrote:>> Consider if we start with the list of certificates issued by StartCom>> and WoSign, assuming the two are the same party (as all reasonable>> evidence suggests). Extract the subjectAltName from every one of>> these certificates, and then compare against the Alexa Top 1M. This>> yields more than 60K certificates, at 1920K in a 'naive' whitelist. However, if you compare based on base domain (as it appears in>> Alexa), you end up with 18,763 unique names, with a much better>> compressibility. For example, when compared with Chrome's Public>> Suffix List DAFSA implementation (as one such compressed data>> structure implementation), this ends up occupying 126K of storage.>> Can you tell us how many unique base domains (PSL+1) there are across> WoSign and StartCom's entire certificate corpus, and what that might> look like as a DAFSA?I'm not sure about a DAFSA, but I wrote a semi-naive implementation ofa compressed trie and got 1592272 bytes.  That is assuming each issuerhas its own trie.  It could be optimized to be smaller if it was justa single trie of eTLD+1 for all issuers.Thanks,Peter___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Richard Wang]

Not this case.
Gerv ask why the order is placed at Aug. 12th 2015, why it is issued at Dec. 
20th 2015, since he finished the domain validation at Dec 20th.


Best Regards,

Richard

On Sep 21, 2016, at 22:54, Kurt Roeckx > 
wrote:

On 2016-09-21 16:26, Richard Wang wrote:
R: You can place order there and don't do the domain validation, 4 months 
later, you finished the domain control validation, then issue the certificate. 
Please try it by yourself here: https://buy.wosign.com/free/

So the date in the certificate is from when the order was placed? This seems to 
contradict other things that have been stated, including why for instance issue 
F happens.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-21 16:26, Richard Wang wrote:

R: You can place order there and don't do the domain validation, 4 months 
later, you finished the domain control validation, then issue the certificate. 
Please try it by yourself here: https://buy.wosign.com/free/


So the date in the certificate is from when the order was placed? This 
seems to contradict other things that have been stated, including why 
for instance issue F happens.



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 24/08/16 14:08, Gervase Markham wrote:
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these
> incidents. 

I have recently updated
https://wiki.mozilla.org/CA:WoSign_Issues
to draw some conclusions for some of the issues, so I wanted to re-draw
the group's attention to this document. Investigations are continuing,
however, and this is not the last word on some of the matters listed.

Gerv



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

See below inline, thanks.

Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham
Sent: Wednesday, September 21, 2016 9:19 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

Thanks for the additional information.

On 21/09/16 11:11, Richard Wang wrote:
> Some SHA-1 certificate is free SSL certificate that no any reason for 
> us to help them get the SHA-1 certificate if we are intentional, and 
> some certificate is even never used or even not retrieved from our 
> system, this also can be certified it is a normal order without any 
> doubt.

I have examined the spreadsheet you sent (note: may not be available to 
mozilla.dev.security.policy participants due to lack of attachment support). 
The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
contains 12 certificates, which have no cost associated with them, and no 
identity vetting other than domain control. Why did each of these take over a 
month, and in some cases nearly 4 months, to be issued? What was the hold-up?
-
R: You can place order there and don't do the domain validation, 4 months 
later, you finished the domain control validation, then issue the certificate. 
Please try it by yourself here: https://buy.wosign.com/free/ 
--
> I think there are many reasons to stop to sign it due to double check, 
> for EV order, it must pass at least 6 person’s check:

Yes, indeed. But at what point during these checks do the following events 
happen?

A) Pre-cert is created and signed (if needed)
B) Pre-cert is sent to CT (if needed)
C) Real cert is created and signed
D) Cert is sent to the customer

I would expect none of these things to happen until all checks are completed. 
We know from previous conversations that your step 7 (next day review) happens 
after C) and D). Where do those four events fit into your seven steps, exactly?
-
R: not of all. The process is stopped after pre-signed the cert but not post to 
CT log server.
-
> Not the case, only one simple bug from CT Post system. I try to say 
> more clearly.
> https://crt.sh/?serial=6D24E483E27F55479C5C555B37745353 is ordered in 
> 19th Dec. 2015, and system pre-signed the pre-cert using SHA-1, no any 
> problem. But it is stopped due to some more check. At 4th Jan.
> 2016, this order finished the final check and go to signing server, 
> signing server generated a new SHA-2 pre-cert to post to CT log server 
> since SHA-1 is not allowed, and get SCT data to the certificate, this 
> is the second certificate:
> https://crt.sh/?serial=31742a2b12809bfca04cffc050903837, also no any 
> problem. The problem is the CT post system have a bug that posted the 
> two related pre-cert to CT log server (SHA-1 pre-cert is the original 
> one, and SHA-2 pre-cert is the new copied one), then get two 
> certificates one signed with SHA-1 and one is SHA-2.  We also posted 
> the two issued certificates to CT log server later.

But that's not how CT works. You don't sent the CT server a pre-cert and get a 
cert back. You send it a pre-cert, and it sends SCTs back. You then need to get 
those SCTs, incorporate them into a new certificate which has the SCTs but not 
the poison extension, and then sign that using your signing server, and then 
store it in your database. All that happened by mistake, due to a single bug? 
You stored the certificate in your system for a number of months because you 
still had it in September when you uploaded it to CT.
--
R: let me try to draw a work flow:
1) SHA-1 cert request at Dec 19th 2015, system pre-signed it as "Pre-cert A" in 
our database, this order is in pending issuance status;
2) but this order is reviewed and stopped to move forward by some reason; so 
this order still in pending status;
3) at Jan 4th 2016, this order is released to move forward. But today is Jan 
4th that SHA-1 cert is forbidden, so the signing server sign the same CSR again 
using SHA-2 to be "Pre-cert B";
4) then the CT Post system posted the two pre-cert into CT log server since 
this two pre-cert is in one order record, this is the bug, it must post the 
Pre-cert B to CT log server, not Pre-cert A, but it posted both;
5) the two pre-cert get SCT data, back to signing server, the signing server 
signed the two cert out: one is SHA-1 with notBefore Dec 19th 2015, one is 
SHA-2 with notBefore Jan 4th 2016;
6) this means the original order copied to two orders in system with two signed 
certificate. The interesting thing is customer just retrieve the SHA-2 cert and 
installed it in his website.
We don't know this bug till someone expose this in the email discussion since 
we issued few EV SSL certificate. So only 6 cases happened in this bug. Sure, 
we fixed the bug and 

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Richard,

Thanks for the additional information.

On 21/09/16 11:11, Richard Wang wrote:
> Some SHA-1 certificate is free SSL certificate that no any reason
> for us to help them get the SHA-1 certificate if we are intentional,
> and some certificate is even never used or even not retrieved from
> our system, this also can be certified it is a normal order without
> any doubt.

I have examined the spreadsheet you sent (note: may not be available to
mozilla.dev.security.policy participants due to lack of attachment
support). The "Categrory 4 - 3:  12 Normal FREE DV SSL Certificates"
contains 12 certificates, which have no cost associated with them, and
no identity vetting other than domain control. Why did each of these
take over a month, and in some cases nearly 4 months, to be issued? What
was the hold-up?

> I think there are many reasons to stop to sign it due to double 
> check, for EV order, it must pass at least 6 person’s check:

Yes, indeed. But at what point during these checks do the following
events happen?

A) Pre-cert is created and signed (if needed)
B) Pre-cert is sent to CT (if needed)
C) Real cert is created and signed
D) Cert is sent to the customer

I would expect none of these things to happen until all checks are
completed. We know from previous conversations that your step 7 (next
day review) happens after C) and D). Where do those four events fit into
your seven steps, exactly?

> Not the case, only one simple bug from CT Post system. I try to say 
> more clearly.
> https://crt.sh/?serial=6D24E483E27F55479C5C555B37745353 is ordered in
> 19th Dec. 2015, and system pre-signed the pre-cert using SHA-1, no
> any problem. But it is stopped due to some more check. At 4th Jan.
> 2016, this order finished the final check and go to signing server,
> signing server generated a new SHA-2 pre-cert to post to CT log
> server since SHA-1 is not allowed, and get SCT data to the
> certificate, this is the second certificate: 
> https://crt.sh/?serial=31742a2b12809bfca04cffc050903837, also no any 
> problem. The problem is the CT post system have a bug that posted
> the two related pre-cert to CT log server (SHA-1 pre-cert is the
> original one, and SHA-2 pre-cert is the new copied one), then get
> two certificates one signed with SHA-1 and one is SHA-2.  We also
> posted the two issued certificates to CT log server later.

But that's not how CT works. You don't sent the CT server a pre-cert and
get a cert back. You send it a pre-cert, and it sends SCTs back. You
then need to get those SCTs, incorporate them into a new certificate
which has the SCTs but not the poison extension, and then sign that
using your signing server, and then store it in your database. All that
happened by mistake, due to a single bug? You stored the certificate in
your system for a number of months because you still had it in September
when you uploaded it to CT.

> The six certificates are revoked after someone pointed it out in the
> email discussion, then we try to find out the reason and know that
> this is a bug from CT Post system, then we revoked the six
> certificate, 

So you discovered the bug in January and fixed it, but did not look to
see if it had led to any misissued certificates until the bug was
discussed in August/September?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

See below inline, thanks.



Best Regards,



Richard



-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, September 20, 2016 7:37 PM
To: Richard Wang >
Subject: Re: Incidents involving the CA WoSign



Hi Richard,



On 16/09/16 11:05, Richard Wang wrote:

> Hi Gerv,

>

> This is the final report:

> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf

>

> Please let me if you have any questions about the report, thanks.



Thank you for this report. I have a few follow-up questions:



Issue H: Duplicate Serial Numbers



1) You write: "Firstly 313 certificates and secondly 27 certificates were 
affected by a system bug with the serial number generation, generating a serial 
number starting with “0” in the first left position. The signing system had a 
bug that didn’t know how to deal with this kind of serial number."



Can you explain a bit more how such a bug can lead to all the certificates 
having the same serial number?

---

Richard:  please check the first 313 certificate serial is 
“56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is 
“D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number 
rule is 32 bytes, so the real two serial number is 
“056D1570DA645BF6B44C0A7077CC6769” and “0D3BBDC3A0175E38F9D0070CD050986A” that 
the signing system has a bug that don’t know how to deal with this kind of 
serial and locked to use this same serial number to sign the certificate.

Please notice the two case (313 and 27) happened in the same time that the 
first 313 certificate is issued by one intermediate CA in English, and the 
second 27 certificate is signed by another intermediate CA in Chinese. This is 
why two case, but we fix the bug, then no more happened.

--



Issue S: Backdated SHA-1 Certs



2) You say that you "found only 8 SHA-1 SSL certificates that were mis-issued 
after January 1st 2016 until June 28th 2016." Why did your searching end at 
June 28th? Have you looked at the rest of June, July and August?

-

Richard: I checked every system to make sure every procedure step has closed 
the SHA-1 option for SSL certificate at June 28th 2016 after we got report from 
Computest, there are another place in API can go to signing server that don’t 
go to SHA-1 blocking system first, this is a bug from the unused API code for 
StartEncrypt. So I can guarantee no more after that day.





3) You say you sent an email to all your staff at the end of December 
forbidding SHA-1 issuance. Does that mean the staff have control of whether a 
cert uses SHA-1 or not? Does WoSign employ certificate templates to make sure 
all appropriate fields are set correctly? If not, why not? If so, is the hash 
algorithm used something that employees can set or override?

---

Richard: as I said in the report, after my email, the Buy website don’t accept 
SHA-1 request after Dec. 30th 2015. But due to some pending request in the 
system that ordered before Dec. 30th 2015, so the PKI system still allow to 
sign SHA-1, this is the problem, we have 3 systems: Buy – CMS – PKI. No anyone 
can change the setting since the certificate template setting is controlled by 
me only.

---



4) All 64 of the certificates being considered here have a notBefore date of 
Sunday, 20th December 2015. Does that correctly reflect the date the 
certificates were created (to within a day)? (For this question, ignore the 2 
certificates mis-issued to CompuTest via the StartEncrypt API.)

If not, what is the technical reason for this back/forward dating? And can you 
please provide a list of the 64 certificates along with their actual dates of 
creation?

---

Richard: For the 62 certificates, there are 22 certificates issued at 19th Dec, 
40 certificates is issued at 20th Dec. 2015.  I checked our system, Dec 20th is 
very normal day, we issued SHA-1 certificate at every day, just one day no 
SHA-1 cert. We provide 24 x 365 service for worldwide customers.
Here is the statistics for the last two weeks SSL certificate issuance in 2015.

[cid:image001.png@01D21431.B2C05D70]

Some SHA-1 certificate is free SSL certificate that no any reason for us to 
help them get the SHA-1 certificate if we are intentional, and some certificate 
is even never used or even not retrieved from our system, this also can be 
certified it is a normal order without any doubt.

--



Issue S, Category 1



These questions relate to your first category, the six certificates which were 
mis-issued due to a bug.



5) You say that the certificates were pre-signed, at some point before midnight 
on 31st December 2016, but then the process was stopped for payment or proof 
document problems. Is it WoSign's normal practice to sign certificates before 
payment has been received? Is it normal 

Re: Incidents involving the CA WoSign

[Peter Bowen]

On Tue, Sep 20, 2016 at 12:23 AM, 谭晓生  wrote:
> I’m Xiaosheng Tan, the Chief Security Officer of Qihoo 360, on the inquiry of 
> the disclosure of Wosign deal, we are not obligated to disclose it under the 
> SEC regulation

I apologize if I implied that you were.  I am sure that WoSign is too
small of an interest to require disclosure.

> Even Richard is the CEO of Wosign, he is not authorized to do any comments to 
> Qihoo 360 legally, thanks for the understanding.

While you are here, I hope you can answer a couple of questions.

1) Are the first three shareholders listed in the attached file the
same companies as the "Qihoo 360 Software (Beijing) Co., Ltd.",
"Beijing Qifutong
Technology Co., Ltd.", and "Beijing Yuan Tu Technology Co., Ltd."
entities listed in Qihoo 360 SEC reports as VIEs or subsidiaries of
VIEs?

2) Does Qihoo 360, a Qihoo 360 subsidiary, a Qihoo 360 VIE, or a Qihoo
360 VIE subsidiary, or a combination of those own or control a
majority of shares in WoSign?

Thanks,
Peter


>
> Thanks,
> Xiaosheng
>
> Xiaosheng Tan, Chief Security Officer
> Qihoo 360
> E-Mail: tanxiaosh...@360.cn
> Web: www.360.cn 
> Address: Bldg 2, 6 Haoyuan, Jiuxianqiao Rd, Chaoyang Dist, Beijing, China 
> 100015
>
>
> 在 16/9/20 下午2:05，“dev-security-policy 代表 
> Percy” percyal...@gmail.com> 写入:
>
> On Monday, September 19, 2016, Richard Wang  wrote:
>
> > Thanks for your pointing out one of the very important evidence for the
> > transaction is NOT completed till yesterday that we released the news 
> after
> > it is finished at the first phase. We just finished the UK company
> > investment.
> >
> > For Qihoo 360, I don't know anything and I don’t have the right to do 
> any
> > comment. Sorry.
>
> Considering that StartCom is hosted by Qihoo 360
> 
> https://pierrekim.github.io/blog/2016-02-16-why-i-stopped-using-startssl-because-of-qihoo-360.html
> and
> that you're the sole director of StartCom, it's hard for me to believe 
> that
> you "don't know anything" about Qihoo 360.
>
> >
> > Best Regards,
> >
> > Richard
> >
> > -Original Message-
> > From: Peter Bowen [mailto:pzbo...@gmail.com ]
> > Sent: Tuesday, September 20, 2016 10:18 AM
> > To: Richard Wang >
> > Cc: Nick Lamb >;
> > mozilla-dev-security-pol...@lists.mozilla.org 
> > Subject: Re: Incidents involving the CA WoSign
> >
> > Richard,
> >
> > As someone pointed out on Twitter this morning, it seems that the PSC
> > notification for Startcom UK was filed recently:
> > https://s3-eu-west-1.amazonaws.com/document-api-images-prod/docs/
> > UdxHYAlFj6U9DNs6VBJdnIDv4IQAWd4YKYomMERO_2o/application-pdf
> >  Were you unaware of this filing?
> >
> > Additionally, companies that register to trade on the New York Stock
> > Exchange have to file reports with the US Security and Exchange
> > Commission.  Qihoo 360 filed a report that included a list of their
> > variable interest entities and Qihoo's percent of economic interest in 
> each
> > (https://www.sec.gov/Archives/edgar/data/1508913/
> > 000114420413022823/v341745_20f.htm
> > page F-10).  It also describes all the ways in which Qihoo 360 controls
> > these entities, including assuring that Qihoo has decision making 
> authority
> > over the entities.
> >
> > I agree that Mozilla does not require reporting that multiple Root CAs 
> are
> > Affiliates.  Perhaps it should.  However, as you know, the CA/Browser 
> Forum
> > does require such.  So I don't think it would be a stretch for Mozilla 
> to
> > do so.  It is something that should probably be added to the 2.3 policy
> > discussion.
> >
> > Thanks,
> > Peter
> >
> >
> > On Mon, Sep 19, 2016 at 6:51 PM, Richard Wang  > > wrote:
> > > Thanks for your detail info.
> > > No worry about this, all companies must be complied with local law.
> > >
> > > But I really don't care who is my company's shareholder's 
> shareholder's
> > shareholder, you need to find out this by yourself if you care.
> > >
> > > If you think Mozilla must require this, please add to the Mozilla 
> policy
> > that require all CA disclose its nine generation including all 
> subordinate
> > companies and all parent companies.
> > >
> > >
> > > Best Regards,
> > >
> > > Richard
> > >
> > > -Original Message-
> > > From: dev-security-policy
> > > [mailto:dev-security-policy-bounces+richard 
> > =wosign.com@lists.mozilla.o
> > > rg] On Behalf Of Nick Lamb
> > > Sent: Tuesday, September 20, 2016 

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 21/09/16 11:10, Kurt Roeckx wrote:
> I didn't read it like that, and that the assets they have in WoSign
> should be more than 10% of the total assets.  So that WoSign would be
> more than 10% of the USD$9.99B.

Oops. You are right. My apologies! I thought the benchmark was the size
of the subsidiary, not the size of the registrant.

Anyway, as I said, no wrongdoing has been suggested by Mozilla.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-21 12:11, Richard Wang wrote:

Please check the first 313 certificate serial is 
“56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is 
“D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number 
rule is 32 bytes.


This is a little misleading. The hex encoding is 31 / 32 characters. 
It's probably more useful to say that it has 128 bit, and you had a 
problem is the top 4 bits where all a 0.



the signing system has a bug that don’t know how to deal with this kind of 
serial and locked to use this same serial number to sign the certificate.


That's a rather weird failure mode. But it was perfectly able to sign 
it, it just didn't generate a new one. And I'm a little concerned that 
this failure mode can happen again.



3) You say you sent an email to all your staff at the end of December 
forbidding SHA-1 issuance. Does that mean the staff have control of whether a 
cert uses SHA-1 or not? Does WoSign employ certificate templates to make sure 
all appropriate fields are set correctly? If not, why not? If so, is the hash 
algorithm used something that employees can set or override?
---
Richard:
As I said in the report, after my email, the Buy website don’t accept SHA-1 
request after Dec. 30th 2015. But due to some pending request in the system 
that ordered before Dec. 30th 2015, so the PKI system still allow to sign 
SHA-1, this is the problem, we have 3 systems: Buy – CMS – PKI. No anyone can 
change the setting since the certificate template setting is controlled by me 
only.


Why is the SHA-1 blocked at the Buy level and not at the PKI level?


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

See below inline, thanks.

Best Regards,

Richard

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Tuesday, September 20, 2016 7:37 PM
To: Richard Wang 
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 16/09/16 11:05, Richard Wang wrote:
> Hi Gerv,
> 
> This is the final report: 
> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf
> 
> Please let me if you have any questions about the report, thanks.

Thank you for this report. I have a few follow-up questions:

Issue H: Duplicate Serial Numbers

1) You write: "Firstly 313 certificates and secondly 27 certificates were 
affected by a system bug with the serial number generation, generating a serial 
number starting with “0” in the first left position. The signing system had a 
bug that didn’t know how to deal with this kind of serial number."

Can you explain a bit more how such a bug can lead to all the certificates 
having the same serial number?
---
Richard:  
Please check the first 313 certificate serial is 
“56D1570DA645BF6B44C0A7077CC6769” and the second 27 certificate is 
“D3BBDC3A0175E38F9D0070CD050986A” that only 31 bytes. But our serial number 
rule is 32 bytes, so the real two serial number is 
“056D1570DA645BF6B44C0A7077CC6769” and “0D3BBDC3A0175E38F9D0070CD050986A” that 
the signing system has a bug that don’t know how to deal with this kind of 
serial and locked to use this same serial number to sign the certificate. 
Please notice the two case (313 and 27) happened in the same time that the 
first 313 certificate is issued by one intermediate CA in English, and the 
second 27 certificate is signed by another intermediate CA in Chinese. This is 
why two case, but we fix the bug, then no more happened.
--

Issue S: Backdated SHA-1 Certs

2) You say that you "found only 8 SHA-1 SSL certificates that were mis-issued 
after January 1st 2016 until June 28th 2016." Why did your searching end at 
June 28th? Have you looked at the rest of June, July and August?
-
Richard: 
I checked every system to make sure every procedure step has closed the SHA-1 
option for SSL certificate at June 28th 2016 after we got report from 
Computest, there are another place in API can go to signing server that don’t 
go to SHA-1 blocking system first, this is a bug from the unused API code for 
StartEncrypt. So I can guarantee no more after that day. 


3) You say you sent an email to all your staff at the end of December 
forbidding SHA-1 issuance. Does that mean the staff have control of whether a 
cert uses SHA-1 or not? Does WoSign employ certificate templates to make sure 
all appropriate fields are set correctly? If not, why not? If so, is the hash 
algorithm used something that employees can set or override?
---
Richard: 
As I said in the report, after my email, the Buy website don’t accept SHA-1 
request after Dec. 30th 2015. But due to some pending request in the system 
that ordered before Dec. 30th 2015, so the PKI system still allow to sign 
SHA-1, this is the problem, we have 3 systems: Buy – CMS – PKI. No anyone can 
change the setting since the certificate template setting is controlled by me 
only.
---

4) All 64 of the certificates being considered here have a notBefore date of 
Sunday, 20th December 2015. Does that correctly reflect the date the 
certificates were created (to within a day)? (For this question, ignore the 2 
certificates mis-issued to Computest via the StartEncrypt API.)
If not, what is the technical reason for this back/forward dating? And can you 
please provide a list of the 64 certificates along with their actual dates of 
creation?
---
Richard: 
For the 62 certificates, there are 22 certificates issued at 19th Dec, 40 
certificates is issued at 20th Dec. 2015.  I checked our system, Dec 20th is 
very normal day, we issued SHA-1 certificate at every day, just one day no 
SHA-1 cert. We provide 24 x 365 service for worldwide customers. 
 
Some SHA-1 certificate is free SSL certificate that no any reason for us to 
help them get the SHA-1 certificate if we are intentional, and some certificate 
is even never used or even not retrieved from our system, this also can be 
certified it is a normal order without any doubt.
--

Issue S, Category 1

These questions relate to your first category, the six certificates which were 
mis-issued due to a bug.

5) You say that the certificates were pre-signed, at some point before midnight 
on 31st December 2016, but then the process was stopped for payment or proof 
document problems. Is it WoSign's normal practice to sign certificates before 
payment has been received? Is it normal practice to sign certificates before 
all identity checks have been completed?
---
Richard: 
I think there are many reasons to stop to sign it due to double check, 

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-21 11:16, Gervase Markham wrote:

Hi Xiaosheng,

On 20/09/16 16:31, 谭晓生 wrote:

Qihoo 360 is a company valued at USD$9.99B as it finished the
privatization on July 15th 2016, we have invested in more than 200
companies across the world, Wosign is just a very small one and we
even do not have any people sent to this company after the
investment, the major businesses of Qihoo 360 are security software
for consumer, we are the largest player of anti-virus software in
China, No.2 search engine in China and one of the top gaming platform
in China, No.1 PC browser in China, the total revenue is about
USD$1.6B last year, that’s might help to understand that why the
layers don’t think Wosign is a "significant subsidiary".


Well, if we were using a dictionary definition of "significant" as used
in normal English conversation, that would make sense :-) However, the
SEC's definition is not related to the size of the company compared to
its parent, or related to whether the parent company's employees start
running the subsidiary company, or whether the company's activities are
supporting the parent's key business areas. The SEC cares about what
percentage of the subsidiary company is owned or controlled by the
parent. And 84%, which appears to be the correct figure here, is much
more than the minimum thresholds set out in the part of the regulations
you helpfully quoted.


I didn't read it like that, and that the assets they have in WoSign 
should be more than 10% of the total assets.  So that WoSign would be 
more than 10% of the USD$9.99B.



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Xiaosheng,

On 20/09/16 16:31, 谭晓生 wrote:
> Qihoo 360 is a company valued at USD$9.99B as it finished the
> privatization on July 15th 2016, we have invested in more than 200
> companies across the world, Wosign is just a very small one and we
> even do not have any people sent to this company after the
> investment, the major businesses of Qihoo 360 are security software
> for consumer, we are the largest player of anti-virus software in
> China, No.2 search engine in China and one of the top gaming platform
> in China, No.1 PC browser in China, the total revenue is about
> USD$1.6B last year, that’s might help to understand that why the
> layers don’t think Wosign is a "significant subsidiary".

Well, if we were using a dictionary definition of "significant" as used
in normal English conversation, that would make sense :-) However, the
SEC's definition is not related to the size of the company compared to
its parent, or related to whether the parent company's employees start
running the subsidiary company, or whether the company's activities are
supporting the parent's key business areas. The SEC cares about what
percentage of the subsidiary company is owned or controlled by the
parent. And 84%, which appears to be the correct figure here, is much
more than the minimum thresholds set out in the part of the regulations
you helpfully quoted.

But again, this is for you and the SEC to sort out :-)

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy