RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv,

Forgive me my bad English, you know my English level. :-) 

It seems my bad English mislead you to wrong place, so I try to correct:
(1) Don't care about the marketing word, it is an advertisement;
(2) What I mean is please think about the current users if any action; 10% from 
government website, 6 customers is the top 10 eCommerce website in China;
(3) We have quality control; I will send the blocking system screenshot to you 
since this mail list can't send.  But we think CT is a good solution for 
mis-issued problem.


Best Regards,

Richard

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Friday, September 2, 2016 6:07 PM
To: Richard Wang ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi Richard,

On 01/09/16 04:04, Richard Wang wrote:
> First, please treat WoSign as a global trusted CA, DON'T stamp as 
> China CA. We need a fair treatment as other worldwide CAs that I am 
> sure WoSign is not the first CA that have incident and not the serious 
> one;

We are keen to treat WoSign as a global CA. It's certainly true that we would 
be having this discussion about any other global CA which had had such a list 
of incidents. However, it seems that you are advancing arguments - such as "we 
are Chinese; we can't be expected to fully understand standards written in 
English" - which ask for special consideration as a Chinese CA rather than a 
global CA. And, as others have pointed out in this thread, WoSign is very happy 
to be seen as a China CA for marketing purposes inside China.

> Second, I supplement some data for your reference, please consider 
> those subscribers benefit, especially from many underdeveloped 
> countries that can't afford the too expansive SSL certificate.

WoSign is not the only company to offer free SSL certificates. But also, this 
seems like arguing "we're too big for you to take action against us".

> Third, I believe no one dare to say his system no bug, WoSign admitted 
> we have system bug that issued the wrong certificate and fixed. This 
> is why WoSign is the first CA in the world for volunteering to 
> "Require CT", we like to use CT mechanism to find out the bug quickly 
> and reduce the lost to minimum,

That seems to me to be outsourcing your quality control to a set of third 
parties. I would say that any CA should have independent systems which check 
every certificate issued, before it is sent to the customer, for a long list of 
possible faults, and hold the certificate for manual review if any of those 
faults are found. That's what I'd do if I were running a CA, anyway. Saying 
"it's all in CT, so we can find problems after issuance" does not, to my mind, 
take misissuance appropriately seriously.

> Thanks a million.

(Just as a note, I would advise against using this English phrase, as it has 
acquired a sarcastic overtone in normal usage.)

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]

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Friday, September 2, 2016 6:07 PM
To: Richard Wang ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

> And, as others have pointed out in this thread, WoSign is very happy to be 
> seen as a China CA for marketing purposes inside China.

We deleted the related two pages.

Best Regards,

Richard
___
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 Fri, Sep 2, 2016 at 12:37 AM, Richard Wang  wrote:
> We finished the CT posting, all 2015 issued SSL certificate is posted to 
> WoSign CT log server: https://ctlog.wosign.com, total 101,410 certificates.

Richard,

Based on CT logs, I have seen certificates from the CAs below, all of
which have "WoSign" in the name.  Have you logged all certificates
which are signed by these CAs and have a notBefore date of
2015010100Z or later to the WoSign CT log?

Do you also plan to submit these to at least one Google-operated log?

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]

(forgot the list)

On Fri, Sep 2, 2016 at 7:55 AM, Peter Bowen  wrote:
> On Fri, Sep 2, 2016 at 12:37 AM, Richard Wang  wrote:
>> We finished the CT posting, all 2015 issued SSL certificate is posted to 
>> WoSign CT log server: https://ctlog.wosign.com, total 101,410 certificates.
>
> Richard,
>
> Based on CT logs, I have seen certificates from the CAs below, all of
> which have "WoSign" in the name.  Have you logged all certificates
> which are signed by these CAs and have a notBefore date of
> 2015010100Z or later to the WoSign CT log?
>
> Do you also plan to submit these to at least one Google-operated log?
>
> Thanks,
> Peter

CN=360 EV Server CA G2,O=WoSign CA Limited,C=CN
CN=360 OV Server CA G2,O=WoSign CA Limited,C=CN
CN=CA WoSign ECC Root,O=WoSign CA Limited,C=CN
CN=CA 沃通 Email 客户端证书 G2,O=WoSign CA Limited,C=CN
CN=CA 沃通 EV Pro 服务器证书 G2,O=WoSign CA Limited,C=CN
CN=CA 沃通 EV 服务器证书 G2,O=WoSign CA Limited,C=CN
CN=CA 沃通 IV 服务器证书 G2,O=WoSign CA Limited,C=CN
CN=CA 沃通 OV Pro 服务器证书 G2,O=WoSign CA Limited,C=CN
CN=CA 沃通 OV 服务器证书 G2,O=WoSign CA Limited,C=CN
CN=CA 沃通免费SSL证书 G2,O=WoSign CA Limited,C=CN
CN=CA 沃通免费SSL证书,O=WoSign CA Limited,C=CN
CN=CA 沃通根证书,O=WoSign CA Limited,C=CN
CN=Certification Authority of WoSign G2,O=WoSign CA Limited,C=CN
CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN
CN=Certification Authority of WoSign,O=WoSign eCommerce Services Limited,C=CN
CN=GZCA EV Server CA,OU=WoSign Trust Network,O=广州市电子签名中心,C=CN
CN=IMS CA,O=WoSign CA Limited,C=CN
CN=IMS Class 4 EV Pro Server CA,O=WoSign CA Limited,C=CN
CN=IMS Class 4 EV Server CA,O=WoSign CA Limited,C=CN
CN=IMS CT Monitor CA,O=WoSign CA Limited,C=CN
CN=IMS EV 服务器根证书,O=WoSign CA Limited,C=CN
CN=IMS 根证书,O=WoSign CA Limited,C=CN
CN=WoSign CA Free SSL Certificate G2,O=WoSign CA Limited,C=CN
CN=WoSign CA Free SSL Certificate,O=WoSign CA Limited,C=CN
CN=WoSign Class 1 Client CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Class 1 Client CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 1 DV Server CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Class 1 DV Server CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 1 DV Server CA,O=WoSign eCommerce Services Limited,C=CN
CN=WoSign Class 2 IV Server CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Class 2 IV Server CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 3 Code Signing CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 3 OV Pro Server CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Class 3 OV Pro Server CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 3 OV Server CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Class 3 OV Server CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 3 OV Server CA,O=WoSign eCommerce Services Limited,C=CN
CN=WoSign Class 4 EV ECC Server CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 4 EV ECC SSL CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 4 EV Pro Server CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Class 4 EV Pro Server CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 4 EV Server CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Class 4 EV Server CA,O=WoSign CA Limited,C=CN
CN=WoSign Class 4 EV SSL CA G2,O=WoSign CA Limited,C=CN
CN=WoSign Premium Server Authority,O=WoSign\, Inc.,C=US
CN=WoSign Server Authority,O=WoSign\, Inc.,C=US
CN=WoSign SGC Server Authority,O=WoSign\, Inc.,C=US
CN=中国湖南 EV 服务器证书,OU=WoSign Trust Network,O=东方新诚信数字认证中心,C=CN
CN=沃通 Email 客户端根证书,O=WoSign CA Limited,C=CN
CN=沃通 EV 服务器根证书,O=WoSign CA Limited,C=CN
L=ShenZhen,ST=GuangDong,O=WoSign CT Monitor Intermediate,C=CN
___
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]

Yes, we posted all 2015 issued SSL from WoSign trusted root.

Your list -- ims root is our test root that not trusted by any browser, we 
don't post the test cert.

And some intermediate ca in the list is for client certificate like CN=沃通 Email 
客户端根证书, CN=CA 沃通 Email 客户端证书 G2;

And some is the code signing intermediate ca: CN=WoSign Class 3 Code Signing CA

And some is very old before we have our own root, like CN=WoSign Server 
Authority that never used now.


Regards,

Richard

> On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
> 
> (forgot the list)
> 
>> On Fri, Sep 2, 2016 at 7:55 AM, Peter Bowen  wrote:
>>> On Fri, Sep 2, 2016 at 12:37 AM, Richard Wang  wrote:
>>> We finished the CT posting, all 2015 issued SSL certificate is posted to 
>>> WoSign CT log server: https://ctlog.wosign.com, total 101,410 certificates.
>> 
>> Richard,
>> 
>> Based on CT logs, I have seen certificates from the CAs below, all of
>> which have "WoSign" in the name.  Have you logged all certificates
>> which are signed by these CAs and have a notBefore date of
>> 2015010100Z or later to the WoSign CT log?
>> 
>> Do you also plan to submit these to at least one Google-operated log?
>> 
>> Thanks,
>> Peter
> 
> CN=360 EV Server CA G2,O=WoSign CA Limited,C=CN
> CN=360 OV Server CA G2,O=WoSign CA Limited,C=CN
> CN=CA WoSign ECC Root,O=WoSign CA Limited,C=CN
> CN=CA 沃通 Email 客户端证书 G2,O=WoSign CA Limited,C=CN
> CN=CA 沃通 EV Pro 服务器证书 G2,O=WoSign CA Limited,C=CN
> CN=CA 沃通 EV 服务器证书 G2,O=WoSign CA Limited,C=CN
> CN=CA 沃通 IV 服务器证书 G2,O=WoSign CA Limited,C=CN
> CN=CA 沃通 OV Pro 服务器证书 G2,O=WoSign CA Limited,C=CN
> CN=CA 沃通 OV 服务器证书 G2,O=WoSign CA Limited,C=CN
> CN=CA 沃通免费SSL证书 G2,O=WoSign CA Limited,C=CN
> CN=CA 沃通免费SSL证书,O=WoSign CA Limited,C=CN
> CN=CA 沃通根证书,O=WoSign CA Limited,C=CN
> CN=Certification Authority of WoSign G2,O=WoSign CA Limited,C=CN
> CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN
> CN=Certification Authority of WoSign,O=WoSign eCommerce Services Limited,C=CN
> CN=GZCA EV Server CA,OU=WoSign Trust Network,O=广州市电子签名中心,C=CN
> CN=IMS CA,O=WoSign CA Limited,C=CN
> CN=IMS Class 4 EV Pro Server CA,O=WoSign CA Limited,C=CN
> CN=IMS Class 4 EV Server CA,O=WoSign CA Limited,C=CN
> CN=IMS CT Monitor CA,O=WoSign CA Limited,C=CN
> CN=IMS EV 服务器根证书,O=WoSign CA Limited,C=CN
> CN=IMS 根证书,O=WoSign CA Limited,C=CN
> CN=WoSign CA Free SSL Certificate G2,O=WoSign CA Limited,C=CN
> CN=WoSign CA Free SSL Certificate,O=WoSign CA Limited,C=CN
> CN=WoSign Class 1 Client CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Class 1 Client CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 1 DV Server CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Class 1 DV Server CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 1 DV Server CA,O=WoSign eCommerce Services Limited,C=CN
> CN=WoSign Class 2 IV Server CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Class 2 IV Server CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 3 Code Signing CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 3 OV Pro Server CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Class 3 OV Pro Server CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 3 OV Server CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Class 3 OV Server CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 3 OV Server CA,O=WoSign eCommerce Services Limited,C=CN
> CN=WoSign Class 4 EV ECC Server CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 4 EV ECC SSL CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 4 EV Pro Server CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Class 4 EV Pro Server CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 4 EV Server CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Class 4 EV Server CA,O=WoSign CA Limited,C=CN
> CN=WoSign Class 4 EV SSL CA G2,O=WoSign CA Limited,C=CN
> CN=WoSign Premium Server Authority,O=WoSign\, Inc.,C=US
> CN=WoSign Server Authority,O=WoSign\, Inc.,C=US
> CN=WoSign SGC Server Authority,O=WoSign\, Inc.,C=US
> CN=中国湖南 EV 服务器证书,OU=WoSign Trust Network,O=东方新诚信数字认证中心,C=CN
> CN=沃通 Email 客户端根证书,O=WoSign CA Limited,C=CN
> CN=沃通 EV 服务器根证书,O=WoSign CA Limited,C=CN
> L=ShenZhen,ST=GuangDong,O=WoSign CT Monitor Intermediate,C=CN


smime.p7s
Description: S/MIME cryptographic signature
___
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]

Yes, we plan to post to one of the Google log server tommorrow.

Regards,

Richard

> On 2 Sep 2016, at 22:54, Peter Bowen  wrote:
> 
>> On Fri, Sep 2, 2016 at 12:37 AM, Richard Wang  wrote:
>> We finished the CT posting, all 2015 issued SSL certificate is posted to 
>> WoSign CT log server: https://ctlog.wosign.com, total 101,410 certificates.
> 
> Richard,
> 
> Based on CT logs, I have seen certificates from the CAs below, all of
> which have "WoSign" in the name.  Have you logged all certificates
> which are signed by these CAs and have a notBefore date of
> 2015010100Z or later to the WoSign CT log?
> 
> Do you also plan to submit these to at least one Google-operated log?
> 
> Thanks,
> Peter


smime.p7s
Description: S/MIME cryptographic signature
___
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 Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>
> On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
>> Based on CT logs, I have seen certificates from the CAs below, all of
>> which have "WoSign" in the name.  Have you logged all certificates
>> which are signed by these CAs and have a notBefore date of
>> 2015010100Z or later to the WoSign CT log?

Richard,

It seems then there is a newly exposed bug.
https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
shows a certificate issued by your CA that has a notBefore in March
2015.  It does not appear in the CT log.  However another certificate
with identical serial number and subject, but different Validity, does
appear in the log.

Are you aware of a bug where you were issuing certificates identical
except for validity period?

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]

We will check this tomorrow.
Now our time is 23:32 at night.


Regards,

Richard

> On 2 Sep 2016, at 23:20, Peter Bowen  wrote:
> 
>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>> 
>>> On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
>>> Based on CT logs, I have seen certificates from the CAs below, all of
>>> which have "WoSign" in the name.  Have you logged all certificates
>>> which are signed by these CAs and have a notBefore date of
>>> 2015010100Z or later to the WoSign CT log?
> 
> Richard,
> 
> It seems then there is a newly exposed bug.
> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> shows a certificate issued by your CA that has a notBefore in March
> 2015.  It does not appear in the CT log.  However another certificate
> with identical serial number and subject, but different Validity, does
> appear in the log.
> 
> Are you aware of a bug where you were issuing certificates identical
> except for validity period?
> 
> Thanks,
> Peter


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Andrew Ayer]

On Fri, 2 Sep 2016 11:19:18 +0100
Gervase Markham  wrote:

> On 31/08/16 19:13, Ryan Sleevi wrote:
> > A) Remove the CA. Users may manually trust it if they re-add it,
> > but it will not be trusted by default.
> 
> 
> F) Distrust all certs with a notBefore date after date X, and require
> the CA to apply for re-inclusion to get the distrust lifted. (I.e.
> what happened to CNNIC.) It's theoretically possible for a CA to
> backdate notBefore, but if they are logging everything to CT, that
> will be noticable. And if they didn't log to CT, they would be
> breaking their promise to log everything to CT, which would be
> evidence of untrustworthiness.

Considering that:

1. WoSign has already been caught backdating the notBefore date, and

2. A certificate has already been found which they didn't log to CT
despite their assertion that they had logged all certificates,

I don't think relying on the notBefore date is a viable option.
WoSign seems to have such a poor handle on their operations that I
think it would be inevitable that someone would find a certificate in
the wild with a notBefore date in the past that had not been
disclosed.  What action would Mozilla take if that happened?

Regards,
Andrew
___
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 Fri, Sep 02, 2016 at 10:00:28AM -0700, Andrew Ayer wrote:
> 2. A certificate has already been found which they didn't log to CT
> despite their assertion that they had logged all certificates,

Can you please point to those that weren't logged?


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

[Kurt Roeckx]

On Fri, Sep 02, 2016 at 07:27:13PM +0200, Kurt Roeckx wrote:
> On Fri, Sep 02, 2016 at 10:00:28AM -0700, Andrew Ayer wrote:
> > 2. A certificate has already been found which they didn't log to CT
> > despite their assertion that they had logged all certificates,
> 
> Can you please point to those that weren't logged?

I of course didn't see the mail yet that mentions:
https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad



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

[Percy]

Some facts for Mozilla to consider.  WoSign Root is never trusted by Apple 
https://support.apple.com/en-ca/HT205205 
https://support.apple.com/en-ca/HT205204 

However,  all WoSign leaf certs are trusted on Apple devices because WoSign 
intermediate authority is signed by StartCom. 
___
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

[Percy]

On Friday, September 2, 2016 at 3:07:46 AM UTC-7, Gervase Markham wrote:
> Hi Richard,
> 
> On 01/09/16 04:04, Richard Wang wrote:
> > First, please treat WoSign as a global trusted CA, DON'T stamp as
> > China CA. We need a fair treatment as other worldwide CAs that I am
> > sure WoSign is not the first CA that have incident and not the
> > serious one;
> 
> We are keen to treat WoSign as a global CA. It's certainly true that we
> would be having this discussion about any other global CA which had had
> such a list of incidents. However, it seems that you are advancing
> arguments - such as "we are Chinese; we can't be expected to fully
> understand standards written in English" - which ask for special
> consideration as a Chinese CA rather than a global CA. And, as others
> have pointed out in this thread, WoSign is very happy to be seen as a
> China CA for marketing purposes inside China.

WoSign in fact actively emphasis that it's a China CA and the global politics 
in marketing. WoSign claimed foreign CA might revoke certs to Chinese orgs due 
to politics and claimed that foreign CA will collect all users information.  
This is a typical marketing email they sent.  
https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:large Translated below.
---
Dear friend:
I'm *** from WoSign CA. WoSign is the first SSL cert company in China. Your 
website *'s SSL cert is from Let's Encrypt, expiring at Oct, 2016. If you 
switch to WoSign before the expiration you can enjoy buy one year get one year 
free. 

The risks associated with foreign CA:
1. Cert revocation 
If foreign CA is influenced by politics and revoke certs for important Chinese 
organizations, the entire system will be paralyzed. 

2. Information security risks
If the website uses foreign certs, users need to send information to foreign 
servers in every visit. Time of the visit, the location of the visit, IP 
addresses, and the browser, frequency of the visits are all collected by 
foreign CA. This will leak commercial secrets and sensitive data, and is a very 
risky!

3. Server latency
Foreign CA cannot provide 24*7 local support. Servers are overseas and affected 
by submarine cables, latency is 10X. If something happens to submarine cables, 
and cert revocation list is not accessible, important systems with foreign 
certs will be paralyzed. In 2012, there is a incident that submarine cables was 
broken. 

 (contact info stuff)

Best regards and thanks,

WoSign CA Limited. 

___
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

[Erwann Abalea]

Le vendredi 2 septembre 2016 19:45:37 UTC+2, Percy a écrit :
> Some facts for Mozilla to consider.  WoSign Root is never trusted by Apple 
> https://support.apple.com/en-ca/HT205205 
> https://support.apple.com/en-ca/HT205204 
> 
> However,  all WoSign leaf certs are trusted on Apple devices because WoSign 
> intermediate authority is signed by StartCom.

That's not WoSign's fault. It's really hard to communicate with Apple and their 
Root Program, it's a concern for other CAs as well.
___
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

[Matt Palmer]

On Fri, Sep 02, 2016 at 09:01:47AM +, Richard Wang wrote:
> You mean if a Chinese, a Chinese company own a USA CA, then the USA CA become 
> un-trustworthiness?

If the Chinese company or US CA are making legal threats to try and suppress
disclosure of the ownership, and the Chinese company is running another CA
with some pretty serious concerns over its trustworthiness, then yes, I'd be
concerned over the trustworthiness of the US CA.

> I still think this topic is out of THE Topic - Incident.

Perhaps, but you didn't say "let's start a new thread", you said "mail me
privately", indicating that you want to avoid public discussion of these
issues of trustworthiness and fidelity.

- Matt

___
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

[Matt Palmer]

On Fri, Sep 02, 2016 at 07:55:36AM -0700, Peter Bowen wrote:
> Do you also plan to submit these to at least one Google-operated log?

Did you mean "non-Google-operated log"?  I was under the impression that we
didn't want everything being stuffed into just Google logs.

- Matt

-- 
I really didn't foresee the Internet.  But then, neither did the computer
industry.  Not that that tells us very much of course -- the computer
industry didn't even foresee that the century was going to end.
-- Douglas Adams

___
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 Sat, Sep 03, 2016 at 09:24:33AM +1000, Matt Palmer wrote:
> On Fri, Sep 02, 2016 at 07:55:36AM -0700, Peter Bowen wrote:
> > Do you also plan to submit these to at least one Google-operated log?
> 
> Did you mean "non-Google-operated log"?  I was under the impression that we
> didn't want everything being stuffed into just Google logs.

It's now only in their own log, it's useful to have it in at least
2 logs.


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

[Matt Palmer]

On Fri, Sep 02, 2016 at 10:27:04AM +, Richard Wang wrote:
> (2) What I mean is please think about the current users if any action; 10%
> from government website, 6 customers is the top 10 eCommerce website in
> China;

I'm reminded of a line from an old episode of a rather crass TV show, which
happens to be rather on-point: "we know you have a choice in airlines, and
it looks like you made the wrong one".

> (3) We have quality control; I will send the blocking system screenshot to
> you since this mail list can't send.  But we think CT is a good solution
> for mis-issued problem.

I think you've got the wrong impression of CT.  The purpose of transparency
isn't to help CAs outsource their quality control to the crowd; it's to
allow easier identification of misissuance so that a more comprehensive case
can be made to revoke a CA's trust status.  If you mis-issue a cert and log
it to CT, you don't get points for logging it to CT: you get dinged because
*you misissued a cert*.

- Matt

___
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

[Matt Palmer]

On Sat, Sep 03, 2016 at 01:31:39AM +0200, Kurt Roeckx wrote:
> On Sat, Sep 03, 2016 at 09:24:33AM +1000, Matt Palmer wrote:
> > On Fri, Sep 02, 2016 at 07:55:36AM -0700, Peter Bowen wrote:
> > > Do you also plan to submit these to at least one Google-operated log?
> > 
> > Did you mean "non-Google-operated log"?  I was under the impression that we
> > didn't want everything being stuffed into just Google logs.
> 
> It's now only in their own log, it's useful to have it in at least
> 2 logs.

Aaaah, I see.  I didn't realise they'd stuffed them in their own log. 
Thanks for the clarification.

- Matt

___
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]

From the screenshot, we know why Percy hate WoSign so deeply, we know he 
represent which CA, everything is clear now.

BTW, as I said that the two related pages in our website are deleted. 

Regards,

Richard

> On 3 Sep 2016, at 02:16, Percy  wrote:
> 
>> On Friday, September 2, 2016 at 3:07:46 AM UTC-7, Gervase Markham wrote:
>> as others have pointed out in this thread, WoSign is very happy to be seen 
>> as a
>> China CA for marketing purposes inside China.
> 
> WoSign in fact actively emphasis that it's a China CA and the global politics 
> in marketing. WoSign claimed foreign CA might revoke certs to Chinese orgs 
> due to politics and claimed that foreign CA will collect all users 
> information.  This is a typical marketing email they sent.  
> https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:large Translated below.
> ---
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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 Fri, Sep 2, 2016 at 5:04 PM, Richard Wang  wrote:
> From the screenshot, we know why Percy hate WoSign so deeply, we know he 
> represent which CA, everything is clear now.

Richard,

With all due respect, many of the people who participate in this
dev-security-policy group work for companies that operate publicly
trusted certificate authorities.  This should not be surprising to
anyone in this group.  Some contribute to this group in their personal
capacity (such as I'm doing now, using my personal email address)
while others contribute in their capacity as a company representative.
This is not new -- the archives of this group are public and you will
see this has been true for years.

What is important is the content of the contribution that is valuable,
not the sender.  If the contribution is factual information, then the
contributor should not matter nor should any perceived underlying
reason for the contribution.

If the screenshot has been modified to contain content that was not in
the original email or the whole thing was forged, then that is
relevant information to know.  The same is true for the documents
referenced elsewhere in this thread.  If people are posting forgeries,
then please let this group know, so they are not given credence.

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

[Percy]

Percy Alpha(PGP
)


On Fri, Sep 2, 2016 at 5:04 PM, Richard Wang  wrote:

> From the screenshot, we know why Percy hate WoSign so deeply, we know he
> represent which CA, everything is clear now.
>

Are you f**king kidding me? I current do not and have not worked for Let's
Encrypt or EFF in general. Are you accusing me and EFF to collude to take
down WoSign?



>
> BTW, as I said that the two related pages in our website are deleted.
>
> Regards,
>
> Richard
>
> > On 3 Sep 2016, at 02:16, Percy  wrote:
> >
> >> On Friday, September 2, 2016 at 3:07:46 AM UTC-7, Gervase Markham wrote:
> >> as others have pointed out in this thread, WoSign is very happy to be
> seen as a
> >> China CA for marketing purposes inside China.
> >
> > WoSign in fact actively emphasis that it's a China CA and the global
> politics in marketing. WoSign claimed foreign CA might revoke certs to
> Chinese orgs due to politics and claimed that foreign CA will collect all
> users information.  This is a typical marketing email they sent.
> https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:large Translated below.
> > ---
> >
> > ___
> > 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

[Percy]

Richard, 
You claimed on weibo (https://pbs.twimg.com/media/CrZ1Oc6WIAABtrg.jpg:large 
)that "WoSign has been oppressed by large American companies over the years but 
has been growing steadily over the past 10 years and is now the 8th largest CA 
in the world".  Is EFF one of your so called oppressors?  Do you even know what 
EFF is?
___
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

[Percy]

On Friday, September 2, 2016 at 9:57:24 PM UTC-7, Percy wrote:
> Richard, 
> You claimed on weibo (https://pbs.twimg.com/media/CrZ1Oc6WIAABtrg.jpg:large 
> )that "WoSign has been oppressed by large American companies over the years 
> but has been growing steadily over the past 10 years and is now the 8th 
> largest CA in the world".  Is EFF one of your so called oppressors?  Do you 
> even know what EFF is?

You also claimed (https://pbs.twimg.com/media/CrZ4GV7WgAESKyn.jpg:large) way 
back in 2014 that "If you deploy foreign certificates, you still will not have 
any security in online commerce".  Is it what you truly believe in or were you 
actively trying to mislead potential customers?
___
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 02/09/16 18:00, Andrew Ayer wrote:
> I don't think relying on the notBefore date is a viable option.
> WoSign seems to have such a poor handle on their operations that I
> think it would be inevitable that someone would find a certificate in
> the wild with a notBefore date in the past that had not been
> disclosed.  What action would Mozilla take if that happened?

A fair question. I think one would need to have the consequences of
further issues mapped out beforehand.

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

[Percy]

I did an analysis of the new StartCom website and determined that it was 
designed and implemented solely in China.  
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html  I'm 
further concerned with the security of "StartResell - Setup your own website, 
start to sell your brand SSL certificate to your customers". Details here
___
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 02/09/16 16:21, Peter Bowen wrote:
> It seems then there is a newly exposed bug.
> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> shows a certificate issued by your CA that has a notBefore in March
> 2015.  It does not appear in the CT log.  However another certificate
> with identical serial number and subject, but different Validity, does
> appear in the log.

https://crt.sh/?id=30326062 appears in the log; I assume that's the cert
you mean.

> Are you aware of a bug where you were issuing certificates identical
> except for validity period?

Well, the _period_ is the same; the start and end dates are offset by an
identical amount ;-)

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 Sat, Sep 03, 2016 at 09:29:45AM +0100, Gervase Markham wrote:
> On 02/09/16 16:21, Peter Bowen wrote:
> > It seems then there is a newly exposed bug.
> > https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> > shows a certificate issued by your CA that has a notBefore in March
> > 2015.  It does not appear in the CT log.  However another certificate
> > with identical serial number and subject, but different Validity, does
> > appear in the log.
> 
> https://crt.sh/?id=30326062 appears in the log; I assume that's the cert
> you mean.
> 
> > Are you aware of a bug where you were issuing certificates identical
> > except for validity period?
> 
> Well, the _period_ is the same; the start and end dates are offset by an
> identical amount ;-)

That offset being 37 seconds.

I've submitted it to Google's aviator log.


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

[Kurt Roeckx]

On Sat, Sep 03, 2016 at 11:45:21AM +0200, Kurt Roeckx wrote:
> On Sat, Sep 03, 2016 at 09:29:45AM +0100, Gervase Markham wrote:
> > On 02/09/16 16:21, Peter Bowen wrote:
> > > It seems then there is a newly exposed bug.
> > > https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> > > shows a certificate issued by your CA that has a notBefore in March
> > > 2015.  It does not appear in the CT log.  However another certificate
> > > with identical serial number and subject, but different Validity, does
> > > appear in the log.
> > 
> > https://crt.sh/?id=30326062 appears in the log; I assume that's the cert
> > you mean.
> > 
> > > Are you aware of a bug where you were issuing certificates identical
> > > except for validity period?
> > 
> > Well, the _period_ is the same; the start and end dates are offset by an
> > identical amount ;-)
> 
> That offset being 37 seconds.
> 
> I've submitted it to Google's aviator log.

So the two are:
https://crt.sh/?id=30326062
https://crt.sh/?id=30736090


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

[Andy Ligg]

You are completely wrong!

StartCom not only have office in Israel and in China, but also have 
office in UK, welcome to visit our UK office: T05, Castlemead, Lower 
Castle Street, Bristol, BS1 3AG, UK.


And We will setup office in Bilbao, Spain in this month, Inigo Barreia 
is the general manager of StartCom Europe that Eddy announced this in 
CABF mail list.


Regards,

Andy

On 2016/9/3 16:17, Percy wrote:

I did an analysis of the new StartCom website and determined that it was designed and 
implemented solely in China.  
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html  I'm further 
concerned with the security of "StartResell - Setup your own website, start to sell 
your brand SSL certificate to your customers". Details here
___
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

[Percy]

Andy, are you from the UK office?  Can you explain why your office in UK
fails to identify even the most obvious mistakes on the StartCom website as
outlined in
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html ?
E.g

Start to sell, make big money!
Setup your own website, start to sell your brand SSL certificate to your
customers. Post customer’s identity information to StartSSL, StartCom
charge the validation cost only with 50% off discount, all certificates
issued from your intermediate CA is FREE. StartCom don’t charge your
certificate cost, you make big money!

StartResell is in the background, you focus your sales, we do everything
for you including PKI system, CRL and OCSP distribution, identity
validation etc., we will use your company name to call your customer for
identity validation, no other contact to your customer


Percy Alpha(PGP
)


On Sat, Sep 3, 2016 at 10:29 AM, Andy Ligg  wrote:

> You are completely wrong!
>
> StartCom not only have office in Israel and in China, but also have office
> in UK, welcome to visit our UK office: T05, Castlemead, Lower Castle
> Street, Bristol, BS1 3AG, UK.
>
> And We will setup office in Bilbao, Spain in this month, Inigo Barreia is
> the general manager of StartCom Europe that Eddy announced this in CABF
> mail list.
>
> Regards,
>
> Andy
>
>
> On 2016/9/3 16:17, Percy wrote:
>
>> I did an analysis of the new StartCom website and determined that it was
>> designed and implemented solely in China.  http://www.percya.com/2016/09/
>> startcom-operated-solely-in-china.html  I'm further concerned with the
>> security of "StartResell - Setup your own website, start to sell your brand
>> SSL certificate to your customers". Details here
>> ___
>> 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

[Ryan Sleevi]

Percy,

As I suggested in the other thread, this does not seem a productive or fruitful 
line of inquiry, nor does it seem relevant to the issue at hand, nor does it 
seem to be done respectfully.

That is, the extent of the country of origin of a CA is not itself a 
fundamental issue of trust, nor should translation errors be. I agree that 
there's a line where elements such as actively misleading the public become a 
matter of public concern, but let's try not to suggest there is something wrong 
with being from a particular country, nor that it represents proof of 
wrongdoing.

I believe we are on the cusp of crossing a line here, and would love if we 
could focus on the technical and factual issues, without attempting to imply 
fundamental guilt by association or pseudo-phrenological analysis of speech 
patterns to show some form of wrongdoing.
___
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

[Percy]

Ryan,
I agree completely that we shouldn't imply fundamental guilt by
association. However, WoSign threatened legal actions against Itzhak
Daniel's disclosure compiled purely from public sources. I just want to
make sure the disclosure was not buried after the content was taken down.

Richard, the CEO of WoSign, stated "From the screenshot, we know why Percy
hate WoSign so deeply, we know he represent which CA, everything is clear
now." The screenshot refers to
https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/5Lelu0oyDQAJ
and the screenshot proves WoSign is actively misleading the public.
He further seems to think I'm working for Let's Encrypt and consequently
want to undermine WoSign. It is he that needs to answer the questions and
concerned raised rather than discrediting the questioners
or threatening legal actions. For the record, I'm not and have not worked
for Let's Encrypt or any CA.

Percy Alpha(PGP
)


On Sat, Sep 3, 2016 at 12:51 PM, Ryan Sleevi  wrote:

> Percy,
>
> As I suggested in the other thread, this does not seem a productive or
> fruitful line of inquiry, nor does it seem relevant to the issue at hand,
> nor does it seem to be done respectfully.
>
> That is, the extent of the country of origin of a CA is not itself a
> fundamental issue of trust, nor should translation errors be. I agree that
> there's a line where elements such as actively misleading the public become
> a matter of public concern, but let's try not to suggest there is something
> wrong with being from a particular country, nor that it represents proof of
> wrongdoing.
>
> I believe we are on the cusp of crossing a line here, and would love if we
> could focus on the technical and factual issues, without attempting to
> imply fundamental guilt by association or pseudo-phrenological analysis of
> speech patterns to show some form of wrongdoing.
>
___
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

[Ryan Sleevi]

Trust me, the disclosure was not buried, and the factual details are being 
sorted. However, it would be better for the tone and focus of the thread that 
we make sure to focus on the factual elements, which, as you note, can be 
publicly obtained easily, than to try to imply there's something wrong with 
poor translations.

In any event, we have significant information here to evaluate, ranging from 
the original issues to matters such as the incomplete disclosure of issues 
certificates, and we should be focusing on those elements, the expectations 
under the Mozilla policies, and what responses that best balance the need of 
Mozilla users (relying parties) and the Internet at large.

For example, a key question remains is: Can/Should WoSign be trusted after 
these incidents? If so, is that trust unconditional, or do there need to be 
improvements, and in what form? If WoSign can no longer be trusted, what steps 
should be taken to reflect that across Mozilla products, in a way that, 
ideally, avoids conditioning users, particularly in the emerging markets 
seemingly most served by WoSign, that TLS errors are OK to ignore?

This is where understanding options is important for the discussion.
___
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]

Richard,

Can you also please check the following two certificates?  It looks
like they were missed when logging all the 2015 certs.

https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720

Additionally, it looks like there may be a gap in logging for 2016.
For example, 
https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
does not show up in any log.

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang  wrote:
> We will check this tomorrow.
> Now our time is 23:32 at night.
>
>
> Regards,
>
> Richard
>
>> On 2 Sep 2016, at 23:20, Peter Bowen  wrote:
>>
>>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
>>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>>>
 On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
 Based on CT logs, I have seen certificates from the CAs below, all of
 which have "WoSign" in the name.  Have you logged all certificates
 which are signed by these CAs and have a notBefore date of
 2015010100Z or later to the WoSign CT log?
>>
>> Richard,
>>
>> It seems then there is a newly exposed bug.
>> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
>> shows a certificate issued by your CA that has a notBefore in March
>> 2015.  It does not appear in the CT log.  However another certificate
>> with identical serial number and subject, but different Validity, does
>> appear in the log.
>>
>> Are you aware of a bug where you were issuing certificates identical
>> except for validity period?
>>
>> 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]

Sorry, I am busy with incident report that up to 20 pages.
It will be released soon today.

Two reports: one for the incident 0-2, another one is for incident X including 
you point out one.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Sunday, September 4, 2016 5:19 AM
To: Richard Wang 
Cc: Ryan Sleevi ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

Can you also please check the following two certificates?  It looks like they 
were missed when logging all the 2015 certs.

https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720

Additionally, it looks like there may be a gap in logging for 2016.
For example, 
https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
does not show up in any log.

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang  wrote:
> We will check this tomorrow.
> Now our time is 23:32 at night.
>
>
> Regards,
>
> Richard
>
>> On 2 Sep 2016, at 23:20, Peter Bowen  wrote:
>>
>>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
>>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>>>
>>>> On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
>>>> Based on CT logs, I have seen certificates from the CAs below, all 
>>>> of which have "WoSign" in the name.  Have you logged all 
>>>> certificates which are signed by these CAs and have a notBefore 
>>>> date of 2015010100Z or later to the WoSign CT log?
>>
>> Richard,
>>
>> It seems then there is a newly exposed bug.
>> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf578
>> 1edbe9d78f9cada8f1d702d5e340ad shows a certificate issued by your CA 
>> that has a notBefore in March 2015.  It does not appear in the CT 
>> log.  However another certificate with identical serial number and 
>> subject, but different Validity, does appear in the log.
>>
>> Are you aware of a bug where you were issuing certificates identical 
>> except for validity period?
>>
>> 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

[Matt Palmer]

On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote:
> Can you also please check the following two certificates?  It looks
> like they were missed when logging all the 2015 certs.
> 
> https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
> https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720
> 
> Additionally, it looks like there may be a gap in logging for 2016.
> For example, 
> https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
> does not show up in any log.

Our of curiosity, is anyone keeping a tally of the number of times WoSign
has said, "yep, they're all logged now", only to have more unlogged
certificates turn up?  This is starting to feel like a bit of a repeat of
DigiNotar, insofar as a CA doesn't appear to have a clear record of all
issuance.

- Matt

___
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 Thu, Sep 1, 2016 at 9:00 AM, Ryan Sleevi  wrote:
> On Wed, August 31, 2016 10:09 pm, Richard Wang wrote:
>>  Thanks for your so detail instruction.
>>  Yes, we are improved. The two case is happened in 2015 and the mis-issued
>>  certificate period is only 5 months that we fixed 3 big bugs during the 5
>>  months.
>>  For CT, we will improve the posting system.
>
> I had a little trouble parsing this, but let's make sure we're on the same
> page. I've continued Gerv's original numbering:
>
> Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1
> certificates ( https://cert.webtrust.org/SealFile?seal=2019&file=pdf )
> Incident -1: April 4, 2015 - WoSign is informed it's routinely violating
> its CPS for issued certificates (
> https://www.wosign.com/policy/wosign-policy-1-2-10.pdf )
> Incident X: April 9 - April 14, 2015 - 392 duplicate serial numbers
> Incident 0: April 23, 2015 - 72 potentially dangerous port-validated
> certificates
> Incident 1: June, 2015 - 33 unvalidated base-domain from sub-domain
> certificates
> Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
> the only one? I wasn't clear from
> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
> )

It was brought to my attention that there is another incident.  WoSign
issued at least two certificates that have subject public keys which
are for the SM2 algorithm.  SM2 is an elliptic curve based algorithm
but it does not use the US NIST P-256, P-384, or P-512 curves.  The
CA/Browser Forum Baseline Requirements and Mozilla CA Certificate
Maintenance Policy both require that only these three curves be used
for elliptic curve keys.

In addition to including subjects keys using unapproved parameters, it
seems these each share their serial number with another certificate
for the same subject.  So these are two more cases of duplicate serial
numbers for different content.

The log entries for the SM2 certificates are
https://ctlog.wosign.com/ct/v1/get-entries?start=109239&end=109240;
crt.sh doesn't have them.  The matching serial numbers are
https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200.

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]

This is another case that we will include it in our report.
We issued two test cert using SM2 algorithm that used the same serial number as 
the RSA cert (same subject) to test if we can setup a gateway that install this 
two type cert, it can shake hand automatically using different cert based on 
the browser algorithm support.

Regards,

Richard

> On 4 Sep 2016, at 12:49, Peter Bowen  wrote:
> 
>> On Thu, Sep 1, 2016 at 9:00 AM, Ryan Sleevi  wrote:
>>> On Wed, August 31, 2016 10:09 pm, Richard Wang wrote:
>>> Thanks for your so detail instruction.
>>> Yes, we are improved. The two case is happened in 2015 and the mis-issued
>>> certificate period is only 5 months that we fixed 3 big bugs during the 5
>>> months.
>>> For CT, we will improve the posting system.
>> 
>> I had a little trouble parsing this, but let's make sure we're on the same
>> page. I've continued Gerv's original numbering:
>> 
>> Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1
>> certificates ( https://cert.webtrust.org/SealFile?seal=2019&file=pdf )
>> Incident -1: April 4, 2015 - WoSign is informed it's routinely violating
>> its CPS for issued certificates (
>> https://www.wosign.com/policy/wosign-policy-1-2-10.pdf )
>> Incident X: April 9 - April 14, 2015 - 392 duplicate serial numbers
>> Incident 0: April 23, 2015 - 72 potentially dangerous port-validated
>> certificates
>> Incident 1: June, 2015 - 33 unvalidated base-domain from sub-domain
>> certificates
>> Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
>> the only one? I wasn't clear from
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
>> )
> 
> It was brought to my attention that there is another incident.  WoSign
> issued at least two certificates that have subject public keys which
> are for the SM2 algorithm.  SM2 is an elliptic curve based algorithm
> but it does not use the US NIST P-256, P-384, or P-512 curves.  The
> CA/Browser Forum Baseline Requirements and Mozilla CA Certificate
> Maintenance Policy both require that only these three curves be used
> for elliptic curve keys.
> 
> In addition to including subjects keys using unapproved parameters, it
> seems these each share their serial number with another certificate
> for the same subject.  So these are two more cases of duplicate serial
> numbers for different content.
> 
> The log entries for the SM2 certificates are
> https://ctlog.wosign.com/ct/v1/get-entries?start=109239&end=109240;
> crt.sh doesn't have them.  The matching serial numbers are
> https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200.
> 
> Thanks,
> Peter


smime.p7s
Description: S/MIME cryptographic signature
___
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]

It is posted, just Peter not find it that I told him the   Log id.

We are also checking system again to double check if we missed some.

Please be patient for our full 20 pages report, thanks,

Regards,

Richard

> On 4 Sep 2016, at 12:12, Matt Palmer  wrote:
> 
>> On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote:
>> Can you also please check the following two certificates?  It looks
>> like they were missed when logging all the 2015 certs.
>> 
>> https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
>> https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720
>> 
>> Additionally, it looks like there may be a gap in logging for 2016.
>> For example, 
>> https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
>> does not show up in any log.
> 
> Our of curiosity, is anyone keeping a tally of the number of times WoSign
> has said, "yep, they're all logged now", only to have more unlogged
> certificates turn up?  This is starting to feel like a bit of a repeat of
> DigiNotar, insofar as a CA doesn't appear to have a clear record of all
> issuance.
> 
> - Matt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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]

https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f

This certificate is issued at July 1st 2016, that our promised SCT data is July 
5th, 2016.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Sunday, September 4, 2016 5:19 AM
To: Richard Wang 
Cc: Ryan Sleevi ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

Can you also please check the following two certificates?  It looks like they 
were missed when logging all the 2015 certs.

https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720

Additionally, it looks like there may be a gap in logging for 2016.
For example, 
https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
does not show up in any log.

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang  wrote:
> We will check this tomorrow.
> Now our time is 23:32 at night.
>
>
> Regards,
>
> Richard
>
>> On 2 Sep 2016, at 23:20, Peter Bowen  wrote:
>>
>>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
>>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>>>
>>>> On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
>>>> Based on CT logs, I have seen certificates from the CAs below, all 
>>>> of which have "WoSign" in the name.  Have you logged all 
>>>> certificates which are signed by these CAs and have a notBefore 
>>>> date of 2015010100Z or later to the WoSign CT log?
>>
>> Richard,
>>
>> It seems then there is a newly exposed bug.
>> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf578
>> 1edbe9d78f9cada8f1d702d5e340ad shows a certificate issued by your CA 
>> that has a notBefore in March 2015.  It does not appear in the CT 
>> log.  However another certificate with identical serial number and 
>> subject, but different Validity, does appear in the log.
>>
>> Are you aware of a bug where you were issuing certificates identical 
>> except for validity period?
>>
>> 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

[Eddy Nigg]

On 09/03/2016 11:02 PM, Percy wrote:

I agree completely that we shouldn't imply fundamental guilt by
association. However, WoSign threatened legal actions against Itzhak
Daniel's disclosure compiled purely from public sources. I just want to
make sure the disclosure was not buried after the content was taken down.


I don't want to extend this discussion unnecessarily, but as a side note 
you don't know which agreements this employee has signed with StartCom 
and/or WoSign and hence you can't make a judgement on it either. Lets 
leave this to the professionals dealing with it.


(Of course your copying and distributing of the content originally 
published by him can be also used against him, just some food for thought)


As such, there can be many more things you don't really know regarding 
this or other business transactions. And probably this is the wrong 
forum for such matters in any case.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. 
XMPP:   start...@startcom.org 

___
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

[Gijs Kruitbosch]

So if I understand correctly, you've published all certificates issued 
in 2015 to CT, and any cert with a notBefore of/after July 5th 2016. Is 
that correct?



As noted in 
https://groups.google.com/d/msg/mozilla.dev.security.policy/Q3zjv95VhXI/p40n2Zv6DAAJ 
, this thread has turned up https://crt.sh/?id=29884704 which was 
mississued and had a notBefore of June 23, 2016.


In addition to that, there was discussion about backdated SHA1 certs ( 
https://groups.google.com/d/msg/mozilla.dev.security.policy/KNuiSDVl7qc/z8rPfqX7DAAJ 
, https://bugzilla.mozilla.org/show_bug.cgi?id=1293366 ) that were 
issued in 2016 but backdated to 2015.


When explicitly asked if you were publishing all the certs with a 
notBefore after 2015010100Z in 
https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/FNYETUsnDQAJ 
you responded with:


On 02/09/2016 16:11, Richard Wang wrote:
> Yes, we posted all 2015 issued SSL from WoSign trusted root.


It has already been established that you issued certificates in 2016 
that were backdated to 2015, and so we have no reason to even assume 
that when you say "all 2015 issued SSL [certs]", that this will include 
any other such hypothetical backdated certs. It has also been 
established that certs were mississued in 2016 outside of the July 5th 
and later period. So it seems that it would be in your own interest to 
be as transparent as possible for the 2016 certs as well, and to simply 
log any and every cert with a notBefore after 2015010100Z.


Why have you not done so?

~ Gijs


On 04/09/2016 09:05, Richard Wang wrote:

https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f

This certificate is issued at July 1st 2016, that our promised SCT data is July 
5th, 2016.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Sunday, September 4, 2016 5:19 AM
To: Richard Wang 
Cc: Ryan Sleevi ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

Can you also please check the following two certificates?  It looks like they 
were missed when logging all the 2015 certs.

https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720

Additionally, it looks like there may be a gap in logging for 2016.
For example, 
https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
does not show up in any log.

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang  wrote:

We will check this tomorrow.
Now our time is 23:32 at night.


Regards,

Richard


On 2 Sep 2016, at 23:20, Peter Bowen  wrote:


On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
Yes, we posted all 2015 issued SSL from WoSign trusted root.


On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
Based on CT logs, I have seen certificates from the CAs below, all
of which have "WoSign" in the name.  Have you logged all
certificates which are signed by these CAs and have a notBefore
date of 2015010100Z or later to the WoSign CT log?


Richard,

It seems then there is a newly exposed bug.
https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf578
1edbe9d78f9cada8f1d702d5e340ad shows a certificate issued by your CA
that has a notBefore in March 2015.  It does not appear in the CT
log.  However another certificate with identical serial number and
subject, but different Validity, does appear in the log.

Are you aware of a bug where you were issuing certificates identical
except for validity period?

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]

Hi all,

We finished the investigation and released the incidents report today: 
https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 

This report has 20 pages, please let me if you still have any questions, thanks.

This report is just for Incident 0-2, we will release a separate report for 
another incident X soon.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Wednesday, August 24, 2016 9:08 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Cc: Richard Wang 
Subject: Incidents involving the CA WoSign

Dear m.d.s.policy,

Several incidents have come to our attention involving the CA "WoSign".
Mozilla is considering what action it should take in response to these 
incidents. This email sets out our understanding of the situation.

Before we begin, we note that Section 1 of the Mozilla CA Certificate 
Enforcement Policy[0] says: "When a serious security concern is noticed, such 
as a major root compromise, it should be treated as a security-sensitive bug, 
and the Mozilla Policy for Handling Security Bugs should be followed." It is 
clear to us, and appears to be clear to other CAs based on their actions, that 
misissuances where domain control checks have failed fall into the category of 
"serious security concern".

Incident 0
--

On or around April 23rd, 2015, WoSign's certificate issuance system for their 
free certificates allowed the applicant to choose any port for validation. Once 
validation had been completed, WoSign would issue certificates for that domain. 
A researcher was able to obtain a certificate for a university by opening a 
high-numbered port (>50,000) and getting WoSign to use that port for validation 
of control.

This problem was reported to Google, and thence to WoSign and resolved.
Mozilla only became aware of it recently.

* Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
ports and paths which can be used, the Baseline Requirements said that one 
acceptable method of domain validation was "Having the Applicant demonstrate 
practical control over the FQDN by making an agreed‐upon change to information 
found on an online Web page identified by a uniform resource identifier 
containing the FQDN". This method therefore did not violate the letter of the 
BRs. However, Mozilla considers the basic security knowledge that ports over 
1024 are unprivileged should have led all CAs not to accept validations of 
domain control on such ports, even when not documented in the BRs.

* The misissuance incident was not reported to Mozilla by WoSign as it should 
have been (see above).

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

Incident 1
--

In June 2015, an applicant found a problem with WoSign's free certificate 
service, which allowed them to get a certificate for the base domain if they 
were able to prove control of a subdomain.

The reporter proved the problem in two ways. They accidentally discovered it 
when trying to get a certificate for med.ucf.edu and mistakenly also applied 
for www.ucf.edu, which was approved. They then confirmed the problem by using 
their control of theiraccount.github.com/theiraccount.github.io to get a cert 
for github.com, github.io, and www.github.io.

They reported this to WoSign, giving only the Github certificate as an example. 
That cert was revoked and the vulnerability was fixed. However recently, they 
got in touch with Google to note that the ucf.edu cert still had not been 
revoked almost a year later.

* The lack of revocation of the ucf.edu certificate (still unrevoked at time of 
writing, although it may have been by time of posting) strongly suggests that 
WoSign either did not or could not search their issuance databases for other 
occurrences of the same problem. Mozilla considers such a search a basic part 
of the response to disclosure of a vulnerability which causes misissuance, and 
expects CAs to keep records detailed enough to make it possible.

* This misissuance incident was not reported to Mozilla by WoSign as it should 
have been (see above).

* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].

Incident 2
--

In July 2016, it became clear that there was some problems with the 
StartEncrypt automatic issuance service recently deployed by the CA StartCom. 
As well as other problems it had, which are outside the scope of this 
discussion, changing a simple API parameter in the POST request on the 
submission page changed the root certificate to which the resulting certificate 
chained up. The value "2" made a certificate signed by "StartCom Class 1 DV 
Server CA", "1" selected "WoSign CA Free SSL Certificate G2" and "0" selected 
"CA 沃通根证书", another root certificate owned by WoSign and trusted by Firefox.

Using the value "1" led to a certificate which had a notBefore date (usage 
start date) of 20th December 2015, 

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote:
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.

Hi Richard,

About incident 0 in the report, it says:

  We investigated each certificates to think it is no necessary to
  revoke these certificates.

Can you please explain how you investigated those and why you
think it's not needed to revoke them?


I also don't understand what you're trying to explain in 2.2.  I
think what it says is that the procedure used to be:
- Someone requests a certificates
- You do validation tests on an initial list of hostnames
- Before he actually submits his request he can modify the list of
  hostnames
- You don't do any validation tests anymore
- You issue the certificate
- Someone manually checks it because github is on the list
  of domains that needs manual review
- The manual review notices that only part of it is validated
- The manual review then asks for revocation
- The revocation process needs an other person to review it
- It informs that subscriber that it's been revoked
- The real revocation happens later by a 3rd person

Is that an accurate description of the problem?

I see 2 problems with this:
- There was a bug that the list of hostnames could be
  modified without revalidating them, and this was fixed on
  August 10, 2015.
- The manual review only happens after the certificate is already
  issued, instead of before issuing it.


In 2.3 you describe that if you sign up for "wosogn.com" (I guess
you mean wosign.com) you get "www.wosign.com" for free and don't
validate it.  But the screenshot of the misissued domains are all
without the "www" prefix.  That is, "www.wosign.com" would be
validated but "wosign.com" wasn't validated.  My understanding is
that if you sign up for "foo.example.com" you get "example.com" too
without validating it, and it's not related to "www".

You indicate that this was also fixed on August 10, 2015, but then
still changed something on August 27, 2016, and it's not clear to
me what you changed.


In 3.2 you describe something about StartCom and WoSign using the
same script but use a different ID.  You describe that there was a
bug you that you deleted. I assume that this is that the POST
doesn't allow to set the caID anymore.  But the document does not
describe why that results in backdated SHA-1 certificates at all.
I see several issues with this:
- It allowed to use a different CA than it should
- Software that was supposed to be stopped using was still
  able to issue certificates
- The software for some reason uses the date it was supposed to be
  stopped from using, instead of the current date.  Was this
  software modified for some reason?

And from what I understand, only the first of those is fixed.

You also describe that it's going to be replaced by ACME, but I
don't see how this relevant or would prevent any of this.

(There is also a SAH1 instead of SHA1 typo.)

PS: I'm unsure why you cross out all those Mozilla, Google and
WoSign address.  I can perfectly recoginize the person in all
those cases.  If you really want to cross them out, please do it
properly.


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

[Kurt Roeckx]

On Sun, Sep 04, 2016 at 10:05:11AM +0100, Gijs Kruitbosch wrote:
> So if I understand correctly, you've published all certificates issued in
> 2015 to CT, and any cert with a notBefore of/after July 5th 2016. Is that
> correct?
> 
> 
> As noted in 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/Q3zjv95VhXI/p40n2Zv6DAAJ
> , this thread has turned up https://crt.sh/?id=29884704 which was mississued
> and had a notBefore of June 23, 2016.
> 
> In addition to that, there was discussion about backdated SHA1 certs ( 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/KNuiSDVl7qc/z8rPfqX7DAAJ
> , https://bugzilla.mozilla.org/show_bug.cgi?id=1293366 ) that were issued in
> 2016 but backdated to 2015.
> 
> When explicitly asked if you were publishing all the certs with a notBefore
> after 2015010100Z in 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/FNYETUsnDQAJ
> you responded with:
> 
> On 02/09/2016 16:11, Richard Wang wrote:
> > Yes, we posted all 2015 issued SSL from WoSign trusted root.
> 
> 
> It has already been established that you issued certificates in 2016 that
> were backdated to 2015, and so we have no reason to even assume that when
> you say "all 2015 issued SSL [certs]", that this will include any other such
> hypothetical backdated certs. It has also been established that certs were
> mississued in 2016 outside of the July 5th and later period. So it seems
> that it would be in your own interest to be as transparent as possible for
> the 2016 certs as well, and to simply log any and every cert with a
> notBefore after 2015010100Z.

>From the document they send, they plan to submit all those from
2016 too, but it will take some time.


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

[Peter Bowen]

On Sat, Sep 3, 2016 at 10:11 PM, Richard Wang  wrote:
> It is posted, just Peter not find it that I told him the   Log id.

Richard,

Thank you for providing the log ids.  I am glad to see these are now
logged, but I will point out the log timestamps for these two
certificates are both later than the time of the email saying all were
logged.  I did not find them because they were not logged when I was
looking.

Thanks,
Peter

> We are also checking system again to double check if we missed some.
>
> Please be patient for our full 20 pages report, thanks,
>
> Regards,
>
> Richard
>
>> On 4 Sep 2016, at 12:12, Matt Palmer  wrote:
>>
>>> On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote:
>>> Can you also please check the following two certificates?  It looks
>>> like they were missed when logging all the 2015 certs.
>>>
>>> https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
>>> https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720
>>>
>>> Additionally, it looks like there may be a gap in logging for 2016.
>>> For example, 
>>> https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
>>> does not show up in any log.
>>
>> Our of curiosity, is anyone keeping a tally of the number of times WoSign
>> has said, "yep, they're all logged now", only to have more unlogged
>> certificates turn up?  This is starting to feel like a bit of a repeat of
>> DigiNotar, insofar as a CA doesn't appear to have a clear record of all
>> issuance.
>>
>> - Matt
>>
>> ___
>> 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
>
___
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

[Andrew Ayer]

On Sat, 3 Sep 2016 21:50:51 -0700
Peter Bowen  wrote:

> The log entries for the SM2 certificates are
> https://ctlog.wosign.com/ct/v1/get-entries?start=109239&end=109240;
> crt.sh doesn't have them.  The matching serial numbers are
> https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200.

The two SM2 certificates can be downloaded here:

https://certspotter.com/api/v0/certs/ab95ba70f1591c56850255f11393dbb63540871b797f6e55665e1a0e67fd977b.pem
https://certspotter.com/api/v0/certs/bb9afdaee1f4a21a4898f18e34a7801908d3c7d911a98463b6be92c40e791f8d.pem

Regards,
Andrew
___
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 Sun, Sep 04, 2016 at 02:53:01PM +0200, Kurt Roeckx wrote:
> On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote:
> > Hi all,
> > 
> > We finished the investigation and released the incidents report today: 
> > https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> > 
> > This report has 20 pages, please let me if you still have any questions, 
> > thanks.
> 
> Hi Richard,
> 
> About incident 0 in the report, it says:
> 
>   We investigated each certificates to think it is no necessary to
>   revoke these certificates.
> 
> Can you please explain how you investigated those and why you
> think it's not needed to revoke them?
> 
> 
> I also don't understand what you're trying to explain in 2.2.  I
> think what it says is that the procedure used to be:

So I'm going to try to understand everything in the document, with
time stamps I can find in the document.
For order 84997, https://crt.sh/?id=29647048
On June 10, 2015, UTC+8:
- ??: Order 84997 is started (11:17:03??)
- 11:43:45: schrauger.github.io validation started?
- 11:43:48: schrauger.github.io validation passed?
- 11:44:15: schrauger.github.com validation started?
- 11:44:17: schrauger.github.com validation passed?
- ??: Subscriber added github.com, github.io, www.github.io?
- 11:47:05: Subscriber clicked the "submit request" button
- 11:49:46: It went to some PKI system?
- 13:42:44: The notBefore date of the certificate
- 14:03:35: The certificate was generated?
- 20:43:00: Subscriber downloaded the certificate

On June 11, 2015, UTC+8:
- 09:38: A Mail was send to Validation Team A and B,
  about order 85295 and 85295.  (At least that's what I
  understand, it's a mail 3 people.)
- 09:49:21: Validation Team A said to revoke
- 09:51:24: Validation Team B approved the revokation request.
- 10:30:53: A mail is send to the subscriber that it's been
  revoked?
- 10:33:08: The PKI admin approved the revocation
- 10:47:55: The PKI system said the revocation was succesful

Order 85295, https://crt.sh/?id=29805567,
On June 10, 2015, UTC+8:
- 22:39:54: Subscriber clicked the "submit request" button
- 23:03:13: The notBefore date of the certificate
- 23:34:55: The certificate was generated?

On June 11, the same as for the previous one.

For order 85391, on June 11, 2015, UTC+8:
- 06:34:58: schrauger.github.io validation started
- 06:35:02: schrauger.github.io was validated.
- 06:35:25: schrauger.github.com validation started
- 06:35:28: schrauger.github.com was validated.
- ??: Subscriber added github.com, www.github.com, github.io,
  www.github.io?
- 06:36:47: Subscriber clicked the "submit request" button
- 06:39:31: It went to the PKI system?
- 09:01: Someone sends a mail to 2 people, making a reference to
  2 orders from the same account, and that they might not have
  been properly validated.

So my understanding is that each time it went to the manual
validation, but that the first 2 times people said ok and that
only the 3rd time someone noticed that the other hostnames weren't
validated.  Is that correct?


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

[Kurt Roeckx]

On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote:
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 

In section 2.2 you explain that there is a mail at 9:01 and 9:38,
where I think the one from 9:38 asks for the revocation of the
certificates by e-mail. Is there a procedure in place that those
e-mails get acted upon? Why is this done via e-mail and not some
some other system that can make sure it's being followed up?


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 Eddy,
On 04/09/16 09:51, Eddy Nigg wrote:
> On 09/03/2016 11:02 PM, Percy wrote:
>> I agree completely that we shouldn't imply fundamental guilt by
>> association. However, WoSign threatened legal actions against Itzhak
>> Daniel's disclosure compiled purely from public sources. I just want to
>> make sure the disclosure was not buried after the content was taken down.
> 
> I don't want to extend this discussion unnecessarily, but as a side note
> you don't know which agreements this employee has signed with StartCom
> and/or WoSign and hence you can't make a judgement on it either. Lets
> leave this to the professionals dealing with it.

If he has signed an agreement with StartCom and/or WoSign which prevents
him from pointing out, after leaving employment, facts which are in the
public domain, then I suggest that those clauses in the agreement are an
unconscionable[0] restriction on his freedoms and you should not be
enforcing them.

> (Of course your copying and distributing of the content originally
> published by him can be also used against him, just some food for
> thought)

If something in what he has said is confidential, please point it out to
me (by private email if you prefer) and I will adjust my attitude to
that particular piece of information.

Gerv

[0] https://en.wikipedia.org/wiki/Unconscionability

___
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

[Rob Stradling]

On 04/09/16 17:40, Andrew Ayer wrote:
> On Sat, 3 Sep 2016 21:50:51 -0700
> Peter Bowen  wrote:
> 
>> The log entries for the SM2 certificates are
>> https://ctlog.wosign.com/ct/v1/get-entries?start=109239&end=109240;
>> crt.sh doesn't have them.

x509lint was segfaulting when crt.sh tried to add the SM2 certs to its
database.  crt.sh has them now:
  https://crt.sh/?id=30773511
  https://crt.sh/?id=30773585

Kurt, please take a look at this PR:
  https://github.com/kroeckx/x509lint/pull/13

>>  The matching serial numbers are
>> https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200.
> 
> The two SM2 certificates can be downloaded here:
> 
> https://certspotter.com/api/v0/certs/ab95ba70f1591c56850255f11393dbb63540871b797f6e55665e1a0e67fd977b.pem
> https://certspotter.com/api/v0/certs/bb9afdaee1f4a21a4898f18e34a7801908d3c7d911a98463b6be92c40e791f8d.pem


-- 
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: Incidents involving the CA WoSign

[Percy]

In page 11, you mentioned that "System blocked many illegal request every day, 
the following screen shot is the reject order log", in which you attached a log 
with Google, Microsoft, QQ domains. Those domains are rejected because of the 
top domain whitelist. Does that mean those attempts passed your automatic 
validation and were only rejected because of the whitelist? 

And as Kurt pointed out, for the flag, why does it happen only AFTER the 
certificate is already issued? Since you specifically have the whitelist for 
topdomains, you would know mis-used of such certs have particularly high 
impacts. 

On Sunday, September 4, 2016 at 2:51:26 AM UTC-7, Richard Wang wrote:
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose any port for validation. 
> Once validation had been completed, WoSign would issue certificates for that 
> domain. A researcher was able to obtain a certificate for a university by 
> opening a high-numbered port (>50,000) and getting WoSign to use that port 
> for validation of control.
> 
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> 
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
> ports and paths which can be used, the Baseline Requirements said that one 
> acceptable method of domain validation was "Having the Applicant demonstrate 
> practical control over the FQDN by making an agreed‐upon change to 
> information found on an online Web page identified by a uniform resource 
> identifier containing the FQDN". This method therefore did not violate the 
> letter of the BRs. However, Mozilla considers the basic security knowledge 
> that ports over 1024 are unprivileged should have led all CAs not to accept 
> validations of domain control on such ports, even when not documented in the 
> BRs.
> 
> * The misissuance incident was not reported to Mozilla by WoSign as it should 
> have been (see above).
> 
> * This misissuance incident did not turn up on WoSign's subsequent BR 
> audit[1].
> 
> Incident 1
> --
> 
> In June 2015, an applicant found a problem with WoSign's free certificate 
> service, which allowed them to get a certificate for the base domain if they 
> were able to prove control of a subdomain.
> 
> The reporter proved the problem in two ways. They accidentally discovered it 
> when trying to get a certificate for med.ucf.edu and mistakenly also applied 
> for www.ucf.edu, which was approved. They then confirmed the problem by using 
> their control of theiraccount.github.com/theiraccount.github.io to get a cert 
> for github.com, github.io, and www.github.io.
> 
> They reported this to WoSign, giving only the Github certificate as an 
> example. That cert was revoked and the vulnerability was fixed. However 
> recently, they got in touch with Google to note that the ucf.edu cert still 
> had not been revoked almost a year later.
> 
> * The lack of revocation of the ucf.edu certificate (still unrevoked at time 
> of writing, although it may have been by time of posting) strongly suggests 
> that WoSign either did not or could not search their issuance databases for 
> other occurrences of the same problem. Mozilla considers such a search a 
> basic part of the response to disclosure of a vulnerability which causes 
> misissuance, and expects CAs to keep records detailed enough to make it 
> possible.
> 
> * This misissuance incident was not reporte

Re: Incidents involving the CA WoSign

[Percy]

On Friday, August 26, 2016 at 12:57:56 PM UTC-7, 233sec Team wrote:
> Wosign's Issue mechanism is high risking for large enterprise.
> This is one prove:
> 
> https://gist.github.com/xiaohuilam/8589f2dfaac435bae4bf8dfe0984f69e
> 
> Alicdn.com is the cdn asset domain name of Taobao/tmall who belong to 
> alibaba, which are Chinese biggest online shopping websites.
> With the fake cert's middle man attack, password stealing, information 
> leaking...

Richard, please also include the incident report for alicdn.com. The whitehat 
(Did you confirm with him, Gerg? ) mentioned "Wosign's Issue mechanism is high 
risking for large enterprise." It might not be an isolated incident, but rather 
a procedural weakness.
___
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, Aug 24, 2016 at 6:08 AM, 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. This email sets out our understanding of the situation.
>
> Before we begin, we note that Section 1 of the Mozilla CA Certificate
> Enforcement Policy[0] says: "When a serious security concern is noticed,
> such as a major root compromise, it should be treated as a
> security-sensitive bug, and the Mozilla Policy for Handling Security
> Bugs should be followed." It is clear to us, and appears to be clear to
> other CAs based on their actions, that misissuances where domain control
> checks have failed fall into the category of "serious security concern".

Gerv and team,

In addition to the direct impact, I note that WoSign is the subject of
cross-signatures from a number of other CAs that chain back to roots
in the Mozilla program (or were in the program).  For example:

Cross issued to /C=CN/O=WoSign CA Limited/CN=CA
\xE6\xB2\x83\xE9\x80\x9A\xE6\xA0\xB9\xE8\xAF\x81\xE4\xB9\xA6 by
/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Certification Authority expiring
2019-12-31T23:59:59Z
Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
of WoSign by /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
Signing/CN=StartCom Certification Authority expiring
2019-12-31T23:59:59Z

Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
of WoSign G2 by /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA expiring
2020-11-02T01:01:59Z
Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
of WoSign G2 by /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA expiring
2020-11-02T01:59:59Z

Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC expiring
2019-06-24T19:06:30Z
Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Object expiring
2019-07-09T18:40:36Z

I have two questions:

1) Should any action be taken against the operators of these CAs due
to the incidents listed?

My view is that the correct answer is "no, unless it is demonstrated
that the CA operator had knowledge of undisclosed incidents", as I
believe that the issuer should be able to rely upon the audit reports
and continued inclusion in the Mozilla trust store as prima facie
evidence of compliance with Mozilla policy.

2) If Mozilla decides to take action that results in WoSign no longer
being directly trusted, do those CAs with unrevoked unexpired
cross-signs bear responsibility for any future mis-issuance by WoSign?

My view is the answer is yes, as WoSign would be a subordinate CA
rather than a peer being cross-signed.  The Mozilla policy makes it
clear that "All certificates that are capable of being used to issue
new certificates, and which directly or transitively chain to a
certificate included in Mozilla’s CA Certificate Program, MUST be
operated in accordance with Mozilla’s CA Certificate Policy".

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

[Percy]

On Monday, September 5, 2016 at 3:58:34 PM UTC-7, Peter Bowen wrote:
> On Wed, Aug 24, 2016 at 6:08 AM, 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. This email sets out our understanding of the situation.
> >
> > Before we begin, we note that Section 1 of the Mozilla CA Certificate
> > Enforcement Policy[0] says: "When a serious security concern is noticed,
> > such as a major root compromise, it should be treated as a
> > security-sensitive bug, and the Mozilla Policy for Handling Security
> > Bugs should be followed." It is clear to us, and appears to be clear to
> > other CAs based on their actions, that misissuances where domain control
> > checks have failed fall into the category of "serious security concern".
> 
> Gerv and team,
> 
> In addition to the direct impact, I note that WoSign is the subject of
> cross-signatures from a number of other CAs that chain back to roots
> in the Mozilla program (or were in the program).  For example:
> 
> Cross issued to /C=CN/O=WoSign CA Limited/CN=CA
> \xE6\xB2\x83\xE9\x80\x9A\xE6\xA0\xB9\xE8\xAF\x81\xE4\xB9\xA6 by
> /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
> Signing/CN=StartCom Certification Authority expiring
> 2019-12-31T23:59:59Z
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate
> Signing/CN=StartCom Certification Authority expiring
> 2019-12-31T23:59:59Z
> 
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign G2 by /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA expiring
> 2020-11-02T01:01:59Z
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign G2 by /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA expiring
> 2020-11-02T01:59:59Z
> 
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC expiring
> 2019-06-24T19:06:30Z
> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Object expiring
> 2019-07-09T18:40:36Z
> 
> I have two questions:
> 
> 1) Should any action be taken against the operators of these CAs due
> to the incidents listed?
> 
> My view is that the correct answer is "no, unless it is demonstrated
> that the CA operator had knowledge of undisclosed incidents", as I
> believe that the issuer should be able to rely upon the audit reports
> and continued inclusion in the Mozilla trust store as prima facie
> evidence of compliance with Mozilla policy.
> 
> 2) If Mozilla decides to take action that results in WoSign no longer
> being directly trusted, do those CAs with unrevoked unexpired
> cross-signs bear responsibility for any future mis-issuance by WoSign?
> 
> My view is the answer is yes, as WoSign would be a subordinate CA
> rather than a peer being cross-signed.  The Mozilla policy makes it
> clear that "All certificates that are capable of being used to issue
> new certificates, and which directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program, MUST be
> operated in accordance with Mozilla’s CA Certificate Policy".
> 
> Thanks,
> Peter

Peter,
I totally agree with your answers. However, relating to question 2, if WoSign 
is restricted to a set of white-listed certs or revoked, I think the 
restriction should apply regardless whether the cert is crossed signed or not. 
This will render question 2 moot, as other CAs are effectively only 
cross-signing the the set of white-listed certs. No certs will be trusted 
anyway, if WoSign is outright revoked either. 
I guess the only situation is that some future (misused) certs will be trusted 
by products that hasn't implemented the whitelist approach, e.g by iOS. Then I 
agree the other root certs should be treated as a subordinate CA.
___
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]

The first email is the guy found the problem, the second email is asking for 
revocation to related person that he/she can't do it.

Sure, we have CMS (Certificate Management System), every order is processed in 
the system by the proper duty person.  See Figure 8, the top menu is
Order Info, personal info, proof documents, processing log, order remark, 
domain validation log
That we just display the menu "processing log" in the screenshot to show all 
process event like shipping tracking system.

I am sorry that we are busy with the second report that maybe can't reply all 
inquiry email. Some question will be replied in the second report.


Best Regards,

Richard

-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be] 
Sent: Monday, September 5, 2016 1:34 AM
To: Richard Wang 
Cc: Gervase Markham ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Sun, Sep 04, 2016 at 09:49:25AM +, Richard Wang wrote:
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf

In section 2.2 you explain that there is a mail at 9:01 and 9:38, where I think 
the one from 9:38 asks for the revocation of the certificates by e-mail. Is 
there a procedure in place that those e-mails get acted upon? Why is this done 
via e-mail and not some some other system that can make sure it's being 
followed up?


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

[Henri Sivonen]

On Sun, Sep 4, 2016 at 12:49 PM, Richard Wang  wrote:
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf
>
> This report has 20 pages, please let me if you still have any questions, 
> thanks.

In the table on page 13, line 6 looks different from the others.
Should that line be in the table on page 14 instead?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
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 06/09/16 07:20, Henri Sivonen wrote:
> In the table on page 13, line 6 looks different from the others.
> Should that line be in the table on page 14 instead?

Also line 2?

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-05 22:37, Percy wrote:

In page 11, you mentioned that "System blocked many illegal request every day, the 
following screen shot is the reject order log", in which you attached a log with 
Google, Microsoft, QQ domains. Those domains are rejected because of the top domain 
whitelist. Does that mean those attempts passed your automatic validation and were only 
rejected because of the whitelist?

And as Kurt pointed out, for the flag, why does it happen only AFTER the 
certificate is already issued? Since you specifically have the whitelist for 
topdomains, you would know mis-used of such certs have particularly high 
impacts.


I think that was a misunderstanding on my part. In the other e-mail I 
send I came to the conclusion that what probably happened was that they 
were flagged for manual review and approved. And so that there really is 
something wrong with the manual review process. Their solution to that 
was to move "github.com" from manual review to reject.


The document really is hard to follow and seems to more concentrate on 
defending themselves, how fast they are and show that they do prevent 
some certificates from being issued. What I'm looking for is just the 
facts of what happened, why this happened, what is being done to prevent 
this in the future.


My current understanding of what happened with the github.com case is:
- It's possible that the list of hostnames is changed between the point 
of validation and the user pressed the "submit request" button.  This 
change can be caused by both the software adding other hostnames itself, 
or the user adding new hostnames.  I understand that when the user 
pressed the button a CSR is generated.
- Once the CSR is generated, it's trusted that the list of hostnames in 
it have been validated, which might not be the case.
- Because gibhub.com is in the list of hostnames that needs to be 
checked, it's flagged for review.

- The manual review just approved it.

What I think is wrong:
- There is no check that the hostnames have been validated after the CSR 
has been generated.
- Too many github.com certificates get flagged for manual review causing 
the reviewers to not look careful and just approve it.  The fix they 
used is to reject "github.com" itself instead of flagging it for review. 
 They should probably also flag less things for review (probably after 
talking to github.)



Looking at Figure 13, the first entry says it has 4 SANs in it, but 
claims only 1 was validated and 1 was not validated, what happened to 
the other 2?



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]

Thanks for your comment.

For Github case:
1. what happened:  issued the certificate that included un-validated domain, 
and found out this mistake in the next day review, and revoked this 
certificate. 
2. why this happened: this is bug as you described, and due to many orders need 
to review manually, so the first day missed and issued; the next day second 
same order come and found out, then rejected.
3. what is being done to prevent this in the future: We fixed this bug, and we 
changed the github setting from "flag" to "reject" for class 1 and class 2 
order to reduce the manual check mistake.

For Figure 13, this subscriber finished the domain control validation for 
domain: netwi.ru, this means the domain: mail. netwi.ru and mx.netwi.ru are 
validated; and it finished the website control validation for domain: 
mail.idisk.su, so only 1 domain mx.idisk.su not validated. 
We can past the process log screenshot for this order in the next report that 
still preparing.

Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Kurt Roeckx
Sent: Tuesday, September 6, 2016 4:56 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On 2016-09-05 22:37, Percy wrote:
> In page 11, you mentioned that "System blocked many illegal request every 
> day, the following screen shot is the reject order log", in which you 
> attached a log with Google, Microsoft, QQ domains. Those domains are rejected 
> because of the top domain whitelist. Does that mean those attempts passed 
> your automatic validation and were only rejected because of the whitelist?
>
> And as Kurt pointed out, for the flag, why does it happen only AFTER the 
> certificate is already issued? Since you specifically have the whitelist for 
> topdomains, you would know mis-used of such certs have particularly high 
> impacts.

I think that was a misunderstanding on my part. In the other e-mail I send I 
came to the conclusion that what probably happened was that they were flagged 
for manual review and approved. And so that there really is something wrong 
with the manual review process. Their solution to that was to move "github.com" 
from manual review to reject.

The document really is hard to follow and seems to more concentrate on 
defending themselves, how fast they are and show that they do prevent some 
certificates from being issued. What I'm looking for is just the facts of what 
happened, why this happened, what is being done to prevent this in the future.

My current understanding of what happened with the github.com case is:
- It's possible that the list of hostnames is changed between the point of 
validation and the user pressed the "submit request" button.  This change can 
be caused by both the software adding other hostnames itself, or the user 
adding new hostnames.  I understand that when the user pressed the button a CSR 
is generated.
- Once the CSR is generated, it's trusted that the list of hostnames in it have 
been validated, which might not be the case.
- Because gibhub.com is in the list of hostnames that needs to be checked, it's 
flagged for review.
- The manual review just approved it.

What I think is wrong:
- There is no check that the hostnames have been validated after the CSR has 
been generated.
- Too many github.com certificates get flagged for manual review causing the 
reviewers to not look careful and just approve it.  The fix they used is to 
reject "github.com" itself instead of flagging it for review. 
  They should probably also flag less things for review (probably after talking 
to github.)


Looking at Figure 13, the first entry says it has 4 SANs in it, but claims only 
1 was validated and 1 was not validated, what happened to the other 2?


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

[Rob Stradling]

Hi Peter.  Since you mentioned Comodo's cross-certification of the
"Certification Authority of WoSign" root, we thought we should respond...

On 05/09/16 23:58, Peter Bowen wrote:

> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> Network/OU=http://www.usertrust.com/CN=UTN - DATACorp SGC expiring
> 2019-06-24T19:06:30Z

This cross-certificate [1] is currently unexpired and unrevoked.  However...

The "UTN - DATACorp SGC" root was removed from NSS last year [2].

"UTN - DATACorp SGC" was also cross-certified by the "AddTrust External
CA Root" root [3], but we revoked the cross-certificates in December
2015, invited Mozilla to add them to OneCRL [4] and disclosed them as
revoked to Salesforce [5].  (I don't know why Mozilla haven't yet added
these to OneCRL.  A few weeks ago I marked Bug 1233408 as blocking Bug
1155095 in the hope that it would get noticed!)

> Cross issued to /C=CN/O=WoSign CA Limited/CN=Certification Authority
> of WoSign by /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
> Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Object expiring
> 2019-07-09T18:40:36Z

These two cross-certificates [6] are currently unexpired and unrevoked.
However...

The "UTN-USERFirst-Object" root is only enabled for the Code Signing
trust bit in NSS, which AIUI has been effectively dead for about a year [7].

There are 2 cross-certs (currently unconstrained and unrevoked) issued
by "AddTrust External CA Root" to "UTN-USERFirst-Object" [8].  However,
the cross-certs issued to WoSign [6] are EKU-constrained to Code Signing
/ Time Stamping.


> 1) Should any action be taken against the operators of these CAs due
> to the incidents listed?
> 
> My view is that the correct answer is "no, unless it is demonstrated
> that the CA operator had knowledge of undisclosed incidents",

Comodo only learned of these incidents after they had been publicly
disclosed.


> 2) If Mozilla decides to take action that results in WoSign no longer
> being directly trusted, do those CAs with unrevoked unexpired
> cross-signs bear responsibility for any future mis-issuance by WoSign?

Comodo will continue to work to ensure that Mozilla's trust decisions
are respected.


[1] https://crt.sh/?id=3223853

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1208461

[3] https://crt.sh/?q=UTN+-+DATACorp+SGC&iCAID=1

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1233408

[5] https://crt.sh/mozilla-disclosures#revoked

[6] https://crt.sh/?q=Certification+Authority+of+WoSign&iCAID=1395

[7]
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg02409.html

[8] https://crt.sh/?q=UTN-USERFirst-Object&iCAID=1

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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 Gutmann]

Matt Palmer  writes:

>Our of curiosity, is anyone keeping a tally of the number of times WoSign has
>said, "yep, they're all logged now", only to have more unlogged certificates
>turn up?  This is starting to feel like a bit of a repeat of DigiNotar,

We apologise for the fault in the CA. Those responsible have been sacked. Mynd
you, møøse bites Kan be pretti nasti... We apologise again for the fault in
the CA. Those responsible for sacking the people who have just been sacked
have been sacked. Møøse trained by YUTTE HERMSGERVØRDENBRØTBØRDA Special Møøse
Effects OLAF PROT Møøse Costumes SIGGI CHURCHILLMøøse Choreographed by HORST
PROT III. The directors of the CA hired to continue the credits after the
other people had been sacked, wish it to be known that they have just been
sacked. The credits have been completed in an entirely different CA,
definitely not StartCom or StartSSL, no really, just WoSign, pay no attention
to the shell company in the UK, it's only WoSign not StartCom, at great
expense and with legal threats. Executive Producer Eddy Nigg and
Gaohua^H^H^H^H^HRichard Wang.

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

[Jakob Bohm]

On 06/09/2016 15:58, Peter Gutmann wrote:

Matt Palmer  writes:


Our of curiosity, is anyone keeping a tally of the number of times WoSign has
said, "yep, they're all logged now", only to have more unlogged certificates
turn up?  This is starting to feel like a bit of a repeat of DigiNotar,


We apologise for the fault in the CA. Those responsible have been sacked. Mynd
you, møøse bites Kan be pretti nasti... We apologise again for the fault in
the CA. Those responsible for sacking the people who have just been sacked
have been sacked. Møøse trained by YUTTE HERMSGERVØRDENBRØTBØRDA Special Møøse
Effects OLAF PROT Møøse Costumes SIGGI CHURCHILLMøøse Choreographed by HORST
PROT III. The directors of the CA hired to continue the credits after the
other people had been sacked, wish it to be known that they have just been
sacked. The credits have been completed in an entirely different CA,
definitely not StartCom or StartSSL, no really, just WoSign, pay no attention
to the shell company in the UK, it's only WoSign not StartCom, at great
expense and with legal threats. Executive Producer Eddy Nigg and
Gaohua^H^H^H^H^HRichard Wang.

Peter.



HØHØHØ *

*=The standard way of writing a derisive laughter in response to a bad
unfunny joke.

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

Re: Incidents involving the CA WoSign

[Eddy Nigg]

On 09/05/2016 10:54 AM, Gervase Markham wrote:

Hi Eddy,

On 04/09/16 09:51, Eddy Nigg wrote:

I don't want to extend this discussion unnecessarily, but as a side note
you don't know which agreements this employee has signed with StartCom
and/or WoSign and hence you can't make a judgement on it either. Lets
leave this to the professionals dealing with it.

If he has signed an agreement with StartCom and/or WoSign which prevents
him from pointing out, after leaving employment, facts which are in the
public domain, then I suggest that those clauses in the agreement are an
unconscionable[0] restriction on his freedoms and you should not be
enforcing them.


Again, I don't think we can and will solve this in public, however I 
believe it's the complete right of a company (and employer) to decide 
how and when it wants to make an official public announcement about its 
business (and being just in order to complete a currently ongoing 
transaction first).


Not every employee is authorized to represent the company and inform 
third parties (at his/her convenient timing and consideration) even if 
he/she knows about it and/or some information has been placed into 
(partly) public domain as part of a business process.


I hope my explanation makes it clear that this ex-employee was not 
authorized to provide any information about StartCom or WoSign.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. 
XMPP:   start...@startcom.org 

___
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

[hanyuwei70]

I thought Wosign's report is not very convincible. The bug of subdomain have 
existed for a long time and it made me feel it is a feature not a bug. It's not 
a secret among the admin of personal or small sites. I am not very similar to 
CA stuff that time,just a subscriber of Wosign's free certificates.I have also 
signed subdomain certificate without validating root domain control. But I 
controlled both of them so I didn't think it is very serve problem.

So I think it is very important to audit how many certificates mis-issued by 
Wosign. Because this bug is used widely when I am running websites for Wosign 
provide FREE 3 year multi-domain certificates that time. ( We dont have Let's 
encrypt that time and Startcom just issue single domain.)
___
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

[Julian Brost]

Hi,

section 1.4. Impact Analytics in the report contains a list of 72
certificates, for which the domain validation was done on a high port.

On 2015-04-20 I have obtained a certificate for a domain name that I
validated using port 8080 but that certificate is not listed in the
report. This is the certificate: https://crt.sh/?id=30335331

It seems like the certificate was posted to the CT logs by WoSign (at
least I never used the certificate anywhere) but not on August 26th like
the other certs and as stated in the report.

So I have doubts about the report and it really should be investigated
why this certificate is missing in the report.

Regards,
Julian Brost

On 04.09.2016 11:49, Richard Wang wrote:
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:ge...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose any port for validation. 
> Once validation had been completed, WoSign would issue certificates for that 
> domain. A researcher was able to obtain a certificate for a university by 
> opening a high-numbered port (>50,000) and getting WoSign to use that port 
> for validation of control.
> 
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> 
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
> ports and paths which can be used, the Baseline Requirements said that one 
> acceptable method of domain validation was "Having the Applicant demonstrate 
> practical control over the FQDN by making an agreed‐upon change to 
> information found on an online Web page identified by a uniform resource 
> identifier containing the FQDN". This method therefore did not violate the 
> letter of the BRs. However, Mozilla considers the basic security knowledge 
> that ports over 1024 are unprivileged should have led all CAs not to accept 
> validations of domain control on such ports, even when not documented in the 
> BRs.
> 
> * The misissuance incident was not reported to Mozilla by WoSign as it should 
> have been (see above).
> 
> * This misissuance incident did not turn up on WoSign's subsequent BR 
> audit[1].
> 
> Incident 1
> --
> 
> In June 2015, an applicant found a problem with WoSign's free certificate 
> service, which allowed them to get a certificate for the base domain if they 
> were able to prove control of a subdomain.
> 
> The reporter proved the problem in two ways. They accidentally discovered it 
> when trying to get a certificate for med.ucf.edu and mistakenly also applied 
> for www.ucf.edu, which was approved. They then confirmed the problem by using 
> their control of theiraccount.github.com/theiraccount.github.io to get a cert 
> for github.com, github.io, and www.github.io.
> 
> They reported this to WoSign, giving only the Github certificate as an 
> example. That cert was revoked and the vulnerability was fixed. However 
> recently, they got in touch with Google to note that the ucf.edu cert still 
> had not been revoked almost a year later.
> 
> * The lack of revocation of the ucf.edu certificate (still unrevoked at time 
> of writing, although it may have been by time of posting) strongly suggests 
> that WoSign either did not or could not search their issuance databases for 
> other occurrences of the same problem. Mozilla considers such a search a 
> basic part of the response to disclosure of a vulnerability which causes 
> misissuance, and expects CAs to keep records detailed enough to make it 
> possible.
> 
> * This misissuance inci

Re: Incidents involving the CA WoSign

[moonbingbing]

For page 19 of the report, I have one question: If the subscriber MUST transfer 
the payment from his company bank account, why subscriber fake the company seal 
as figure 20?
And from figure 21's information, one fraud company transfered the payment from 
alipay, NOT his company bank!

在 2016年9月4日星期日 UTC+8下午5:51:26，Richard Wang写道：
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose any port for validation. 
> Once validation had been completed, WoSign would issue certificates for that 
> domain. A researcher was able to obtain a certificate for a university by 
> opening a high-numbered port (>50,000) and getting WoSign to use that port 
> for validation of control.
> 
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> 
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
> ports and paths which can be used, the Baseline Requirements said that one 
> acceptable method of domain validation was "Having the Applicant demonstrate 
> practical control over the FQDN by making an agreed‐upon change to 
> information found on an online Web page identified by a uniform resource 
> identifier containing the FQDN". This method therefore did not violate the 
> letter of the BRs. However, Mozilla considers the basic security knowledge 
> that ports over 1024 are unprivileged should have led all CAs not to accept 
> validations of domain control on such ports, even when not documented in the 
> BRs.
> 
> * The misissuance incident was not reported to Mozilla by WoSign as it should 
> have been (see above).
> 
> * This misissuance incident did not turn up on WoSign's subsequent BR 
> audit[1].
> 
> Incident 1
> --
> 
> In June 2015, an applicant found a problem with WoSign's free certificate 
> service, which allowed them to get a certificate for the base domain if they 
> were able to prove control of a subdomain.
> 
> The reporter proved the problem in two ways. They accidentally discovered it 
> when trying to get a certificate for med.ucf.edu and mistakenly also applied 
> for www.ucf.edu, which was approved. They then confirmed the problem by using 
> their control of theiraccount.github.com/theiraccount.github.io to get a cert 
> for github.com, github.io, and www.github.io.
> 
> They reported this to WoSign, giving only the Github certificate as an 
> example. That cert was revoked and the vulnerability was fixed. However 
> recently, they got in touch with Google to note that the ucf.edu cert still 
> had not been revoked almost a year later.
> 
> * The lack of revocation of the ucf.edu certificate (still unrevoked at time 
> of writing, although it may have been by time of posting) strongly suggests 
> that WoSign either did not or could not search their issuance databases for 
> other occurrences of the same problem. Mozilla considers such a search a 
> basic part of the response to disclosure of a vulnerability which causes 
> misissuance, and expects CAs to keep records detailed enough to make it 
> possible.
> 
> * This misissuance incident was not reported to Mozilla by WoSign as it 
> should have been (see above).
> 
> * This misissuance incident did not turn up on WoSign's subsequent BR 
> audit[1].
> 
> Incident 2
> --
> 
> In July 2016, it became clear that there was some problems with the 
> StartEncrypt automatic issuance service recently deployed by the CA StartCom. 
> As well as oth

Re: Incidents involving the CA WoSign

[Will Hughes]

Hello,

First of all let me state that I am in no way involved in the operation of
a certificate authority, nor am I involved in setting CA policy for any
organisation; I am merely an interested observer. I am a user of Mozillas'
trust store, both directly through Firefox and Thunderbird, and indirectly
by using pieces of software that rely on NSS. I have previously been a
customer of WoSign[0], but am not currently.

Addressing Mozillas' response to WoSigns' breach:

* Surely there is precedent from previous violations by other CAs that can be
  used to inform this decision? How did Mozilla handle the October 2015
  incident[1] in which Symantec mis-issued over 2500 certificates? While the
  scale appears to be different, the facts of that incident are not too
  dissimilar to this one; a CA mis-issued a number of certificates, and
  failed to adequately notify trust store operators of this.

* While there doesn't seem to be a great deal of dispute over the facts of
  this incident, it seems to me that in the very short term (ie, the next
  fortnight) it would be useful if WoSign were required to produce an incident
  report detailing:
- The precise extent of the incident, detailing every certificate that was
  mis-issued and to whom, to reassure the community that these bugs are not
  being used maliciously
- The current status (revocation, CT presence) of all mis-issued
  certificates.
- An assessment as to the cause of the incident[2]
- Details as to the measures already undertaken to rectify the defects
- Details of future measures that will be undertaken to prevent further
  problems
  The purpose of this is to re-establish some small amount of trust that WoSign
  can be permitted to continue operating while a longer-term plan is discussed

* I do not know what should be done in the longer term, but I suggest that the
  focus of this discussion be on finding ways to permit WoSign to prove that
  they are fit to participate in the Root Trust programme, so long as WoSign
  are willing to engage and proactively work to restore trust. If WoSign do
  not wish to work to restore trust, then removal from the programme would
  have to be considered. Care must be taken to not unduly punish WoSigns'
  customers, while at the same to the safety of the wider internet community
  must be assured.

Addressing this issue in general; WoSign have claimed that their failure to
report this incident came about from a misunderstanding of the English
language documents by their staff who do not all speak English. While this
is clearly not a valid excuse, is this something Mozilla needs to consider
to prevent similar incidents in the future? Surely a significant
proportion of CA operators face a similar language barrier?

Thank you all for your time,
Will Hughes

[0] I issued two certificate via WoSign in May 2016 for hosts that were
not internet facing, because it was impractical for me to issue LetsEncrypt
certs for those hosts. I have since updated my tooling, issued LetsEncrypt
certs and revoked the WoSign certs. I note that neither of the WoSign certs
appear on crt.sh

[1] 
https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html

[2] I understand that in the short timeframe, a full post-mortem may not
be practical, but an initial assesment of the causes of the incident
should have already been completed

On Thursday, 25 August 2016 01:09:02 UTC+12, Gervase Markham  wrote:
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate
> Enforcement Policy[0] says: "When a serious security concern is noticed,
> such as a major root compromise, it should be treated as a
> security-sensitive bug, and the Mozilla Policy for Handling Security
> Bugs should be followed." It is clear to us, and appears to be clear to
> other CAs based on their actions, that misissuances where domain control
> checks have failed fall into the category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for
> their free certificates allowed the applicant to choose any port for
> validation. Once validation had been completed, WoSign would
> issue certificates for that domain. A researcher was able to obtain a
> certificate for a university by opening a high-numbered port (>50,000)
> and getting WoSign to use that port for validation of control.
> 
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> 
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits
> the ports and paths which can be used, the Baseline Requirements said
> that one acceptable method of domain valida

Re: Incidents involving the CA WoSign

[xcrailfans]

On Saturday, September 3, 2016 at 1:31:17 PM UTC-4, Andy Ligg wrote:
> You are completely wrong!
> 
> StartCom not only have office in Israel and in China, but also have 
> office in UK, welcome to visit our UK office: T05, Castlemead, Lower 
> Castle Street, Bristol, BS1 3AG, UK.

Thanks for pointing me to MR. GUOHUA WANG's name[1], and beware of your NDA 
too. Meh.

[1]: 
http://wayback.archive.org/web/20160903185601/https://companycheck.co.uk/company/09744347/STARTCOM-CA-LIMITED/companies-house-data#
___
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

[Jonathan Rudenberg]

> On Sep 5, 2016, at 16:25, hanyuwe...@gmail.com wrote:
> 
> I thought Wosign's report is not very convincible. The bug of subdomain have 
> existed for a long time and it made me feel it is a feature not a bug. It's 
> not a secret among the admin of personal or small sites. I am not very 
> similar to CA stuff that time,just a subscriber of Wosign's free 
> certificates.I have also signed subdomain certificate without validating root 
> domain control. But I controlled both of them so I didn't think it is very 
> serve problem.
> 
> So I think it is very important to audit how many certificates mis-issued by 
> Wosign. Because this bug is used widely when I am running websites for Wosign 
> provide FREE 3 year multi-domain certificates that time. ( We dont have Let's 
> encrypt that time and Startcom just issue single domain.)

Do you believe that you have certificates issued by WoSign that include 
unvalidated domains that are not on the list in Figure 14 of the report[0]?

To clarify: validating a subdomain and issuing a certificate for it is fine, 
however it is incorrect to issue a certificate for a domain below the level 
that was validated. For example, if control of subdomain.example.com is the 
only thing validated, it would be incorrect to issue a certificate that 
included example.com or any other domains that did not end in 
.subdomain.example.com.

[0] https://www.wosign.com/report/wosign_incidents_report_09042016.pdf
___
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 05/09/16 23:58, Peter Bowen wrote:
> 1) Should any action be taken against the operators of these CAs due
> to the incidents listed?
> 
> My view is that the correct answer is "no, unless it is demonstrated
> that the CA operator had knowledge of undisclosed incidents", as I
> believe that the issuer should be able to rely upon the audit reports
> and continued inclusion in the Mozilla trust store as prima facie
> evidence of compliance with Mozilla policy.
> 
> 2) If Mozilla decides to take action that results in WoSign no longer
> being directly trusted, do those CAs with unrevoked unexpired
> cross-signs bear responsibility for any future mis-issuance by WoSign?
> 
> My view is the answer is yes, as WoSign would be a subordinate CA
> rather than a peer being cross-signed.  The Mozilla policy makes it
> clear that "All certificates that are capable of being used to issue
> new certificates, and which directly or transitively chain to a
> certificate included in Mozilla’s CA Certificate Program, MUST be
> operated in accordance with Mozilla’s CA Certificate Policy".

After consultation, Mozilla's CA team agrees with your views.

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

[Thijs Alkemade]

On 01 Sep 2016, at 18:00, Ryan Sleevi  wrote:
> 
> Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
> the only one? I wasn't clear from
> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
>  
> 
> )

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.

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.) 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.

Then I checked crt.sh to look for the SANs used for these certificates, and 
found even more signs. For the domain “mail.gd.gov.cn”, two certificates have 
been logged recently:

https://crt.sh/?id=12356371 SHA-1 signature and notBefore December 20, 2015.
https://crt.sh/?id=12362293 SHA-256 signature and notBefore January 26, 2016.

Both were first logged to Certificate Transparency by Google on January 28, 
2016.

For “ebank.pcnkbank.com”, similar:

https://crt.sh/?id=30773634 SHA-1 signature and notBefore December 20, 2015.
https://crt.sh/?id=15425430 SHA-256 signature and notBefore January 28, 2016.

For “congfubao.com”:

https://crt.sh/?id=30773528 SHA-1 signature, notBefore December 20, 2015 and 3 
embedded SCTs for January 5, 2016.
https://crt.sh/?id=11900532 SHA-256 signature, notBefore January 5, 2016 and 3 
embedded SCTs for January 5, 2016. These SCTs were issued approximately 17 
seconds later than those on the other cert.

And many other examples exist within these 62 certs for which a SHA-256 
certificate was issued in January/February and a SHA-1 certificate was “issued” 
on December 20, but not logged to Certificate Transparency (until last week) or 
just after the SHA-256 certificate was issued.

All of this together strongly suggests WoSign was generating SHA-1 and SHA-256 
certificates at the same time (not uncommon in 2015 to maximise compatibility, 
I think), but continued doing this on December 31, 2015 for at least a month by 
intentionally backdating the SHA-1 certificate.



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



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Jakob Bohm]

On 06/09/2016 19:49, Jonathan Rudenberg wrote:



On Sep 5, 2016, at 16:25, hanyuwe...@gmail.com wrote:

I thought Wosign's report is not very convincible. The bug of subdomain have 
existed for a long time and it made me feel it is a feature not a bug. It's not 
a secret among the admin of personal or small sites. I am not very similar to 
CA stuff that time,just a subscriber of Wosign's free certificates.I have also 
signed subdomain certificate without validating root domain control. But I 
controlled both of them so I didn't think it is very serve problem.

So I think it is very important to audit how many certificates mis-issued by 
Wosign. Because this bug is used widely when I am running websites for Wosign 
provide FREE 3 year multi-domain certificates that time. ( We dont have Let's 
encrypt that time and Startcom just issue single domain.)


Do you believe that you have certificates issued by WoSign that include 
unvalidated domains that are not on the list in Figure 14 of the report[0]?

To clarify: validating a subdomain and issuing a certificate for it is fine, 
however it is incorrect to issue a certificate for a domain below the level 
that was validated. For example, if control of subdomain.example.com is the 
only thing validated, it would be incorrect to issue a certificate that 
included example.com or any other domains that did not end in 
.subdomain.example.com.

[0] https://www.wosign.com/report/wosign_incidents_report_09042016.pdf



Because of what hanyuwei70 wrote, I think it would be prudent to treat
two cases different *for this case only*:

1. The validated domain was www.foo.bar and the certificate was for
www.foo.bar and foo.bar.  This case should be treated more leniently.

2. The validated domain was baz.foo.bar and the certificate was for
baz.foo.bar and foo.bar.  In this case there is no reason to believe
that the certificate customer has any right to get a certificate for
foo.bar and the certificates must be revoked instantly with no delay.

If a customer paid money for a baz.foo.bar certificate and can now
prove that they do in fact control foo.bar in addition to baz.foo.bar,
the certificate should be reissued at no extra cost, since only the
WoSign validation work was wrong, not the result.

If a customer paid money for a baz.foo.bar certificate and did not
request or use the included foo.bar certification, that customer should
be offered a baz.foo.bar-only certificate at no extra charge, provided
they can still prove control of baz.foo.bar.

If a customer actually asked for a combined baz.foo.bar + foo.bar
certificate or used the foo.bar portion of such a certificate despite
having no rights to the foo.bar domain itself, then that customer
should not be able to get a new certificate at all, since they
deliberately acted fraudulently and took advantage of WoSign's
incompetence.  This includes the security researcher(s) who requested
such certificates only to prove that WoSign's systems don't work.



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

RE: Incidents involving the CA WoSign

[Richard Wang]

We checked our system that this order is finished the website control 
validation correctly. No any mistake.

Why this is not listed in the report list? This order is year 2015 order, this 
is the event of 17 months ago, we can't find the info what port is used, our 
CMS system just record this order is validated by website control validation 
method, not record the used port at that time.

Why we can find out other 72 certificate? We try to search every validation 
process evidence in many systems to analyze the related log to catch the info. 
I can't guarantee all high port validation order are listed in the report, but 
as we said in the report, each certificate is properly validated using high 
port.


Best Regards,

Richard

-Original Message-
From: Julian Brost [mailto:jul...@0x4a42.net] 
Sent: Wednesday, September 7, 2016 12:06 AM
To: Richard Wang ; Gervase Markham ; 
dev-security-policy@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Hi,

section 1.4. Impact Analytics in the report contains a list of 72 certificates, 
for which the domain validation was done on a high port.

On 2015-04-20 I have obtained a certificate for a domain name that I validated 
using port 8080 but that certificate is not listed in the report. This is the 
certificate: https://crt.sh/?id=30335331

It seems like the certificate was posted to the CT logs by WoSign (at least I 
never used the certificate anywhere) but not on August 26th like the other 
certs and as stated in the report.

So I have doubts about the report and it really should be investigated why this 
certificate is missing in the report.

Regards,
Julian Brost

On 04.09.2016 11:49, Richard Wang wrote:
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:ge...@mozilla.org]
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose any port for validation. 
> Once validation had been completed, WoSign would issue certificates for that 
> domain. A researcher was able to obtain a certificate for a university by 
> opening a high-numbered port (>50,000) and getting WoSign to use that port 
> for validation of control.
> 
> This problem was reported to Google, and thence to WoSign and resolved.
> Mozilla only became aware of it recently.
> 
> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
> ports and paths which can be used, the Baseline Requirements said that one 
> acceptable method of domain validation was "Having the Applicant demonstrate 
> practical control over the FQDN by making an agreed‐upon change to 
> information found on an online Web page identified by a uniform resource 
> identifier containing the FQDN". This method therefore did not violate the 
> letter of the BRs. However, Mozilla considers the basic security knowledge 
> that ports over 1024 are unprivileged should have led all CAs not to accept 
> validations of domain control on such ports, even when not documented in the 
> BRs.
> 
> * The misissuance incident was not reported to Mozilla by WoSign as it should 
> have been (see above).
> 
> * This misissuance incident did not turn up on WoSign's subsequent BR 
> audit[1].
> 
> Incident 1
> --
> 
> In June 2015, an applicant found a problem with WoSign's free certificate 
>

Re: Incidents involving the CA WoSign

[Eric Mill]

On Tue, Sep 6, 2016 at 11:43 AM, Eddy Nigg  wrote:

> On 09/05/2016 10:54 AM, Gervase Markham wrote:
>
>> Hi Eddy,
>>
>> On 04/09/16 09:51, Eddy Nigg wrote:
>>
>>> I don't want to extend this discussion unnecessarily, but as a side note
>>> you don't know which agreements this employee has signed with StartCom
>>> and/or WoSign and hence you can't make a judgement on it either. Lets
>>> leave this to the professionals dealing with it.
>>>
>> If he has signed an agreement with StartCom and/or WoSign which prevents
>> him from pointing out, after leaving employment, facts which are in the
>> public domain, then I suggest that those clauses in the agreement are an
>> unconscionable[0] restriction on his freedoms and you should not be
>> enforcing them.
>>
>
> Again, I don't think we can and will solve this in public, however I
> believe it's the complete right of a company (and employer) to decide how
> and when it wants to make an official public announcement about its
> business (and being just in order to complete a currently ongoing
> transaction first).
>

That right doesn't exist. Not for governments, corporations, or any other
organization.

Every organization wants to control information flow about themselves, and
they certainly have the right to try to do so as long as they don't harm
other people. But legally restraining and punishing individuals in pursuit
of that control is rightfully subject to intense scrutiny.

At the very least, you and your company come off as a complete bully, and I
don't think that benefits you right now.

-- Eric


>
> Not every employee is authorized to represent the company and inform third
> parties (at his/her convenient timing and consideration) even if he/she
> knows about it and/or some information has been placed into (partly) public
> domain as part of a business process.
>
> I hope my explanation makes it clear that this ex-employee was not
> authorized to provide any information about StartCom or WoSign.



>
>
> --
> Regards
> Signer: Eddy Nigg, Founder
> StartCom Ltd. 
> XMPP:   start...@startcom.org 
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
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

[Rob Stradling]

On 06/09/16 11:11, Rob Stradling wrote:

> "UTN - DATACorp SGC" was also cross-certified by the "AddTrust External
> CA Root" root [3], but we revoked the cross-certificates in December
> 2015, invited Mozilla to add them to OneCRL [4] and disclosed them as
> revoked to Salesforce [5].  (I don't know why Mozilla haven't yet added
> these to OneCRL.  A few weeks ago I marked Bug 1233408 as blocking Bug
> 1155095 in the hope that it would get noticed!)

These cross-certs (https://crt.sh/?q=UTN+-+DATACorp+SGC&iCAID=1) are now
in OneCRL.  Thanks Gerv.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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, Kathleen and Richard,

This discuss has been lasting two weeks, I think it is time to end it, it 
doesn’t worth to waste everybody’s precious time.
I make my confession that our system and management do have some problems which 
lead to the misissuance of some certificates. And I am very sorry that WoSign 
don’t notify all browsers after the incident happened and even after the 
problem fixed.

I’d like to give my suggestion action for Mozilla as below:
1. Mozilla will trust those SSL certificates only:
(1) The certificate notBefore date is before Jan. 1st 2015;
(2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
that listed in the Google CT log server;
(3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
that embedded SCT data in the certificate;
(4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
data in the certificate and must have the “C=CN” in the certificate subject.

2. Mozilla can assign a WebTrust auditor to WoSign office to check and inspect 
every incident, check every relevant issued certificate, and record a report 
with:  what happened, why this happened and what is being done to prevent this 
in the future etc., WoSign will pay the audit cost.

I’d like to make some supplements about 1. (4) above, this term means WoSign 
will only issue SSL certificates to China subscribers. 
WoSign issued about 120K SSL certificates for websites in China including many 
central government websites like MIIT and many other local province government 
websites, many university websites, many online banking websites, 6 of the Top 
10 ecommerce websites, big supermarket online store like Walmart, 4 of the Top 
5 cloud service in China, and many big companies that listed in NYSE and 
Nasdaq, and many subsidiaries of foreign countries big companies. 
Those customers like to use WoSign certificate especially our support of 
Chinese, local support and customer service. And some of them paid up to 
10-year certificate fee in advance, we need to renew their certificate for free 
once it is about to expire at every three years for OV SSL.

I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
better after getting this so big lesson. 
Thank you.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Richard Wang
Sent: Sunday, September 4, 2016 5:49 PM
To: Gervase Markham ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

Hi all,

We finished the investigation and released the incidents report today: 
https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 

This report has 20 pages, please let me if you still have any questions, thanks.

This report is just for Incident 0-2, we will release a separate report for 
another incident X soon.


Best Regards,

Richard Wang
CEO
WoSign CA Limited


-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Wednesday, August 24, 2016 9:08 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Cc: Richard Wang 
Subject: Incidents involving the CA WoSign

Dear m.d.s.policy,

Several incidents have come to our attention involving the CA "WoSign".
Mozilla is considering what action it should take in response to these 
incidents. This email sets out our understanding of the situation.

Before we begin, we note that Section 1 of the Mozilla CA Certificate 
Enforcement Policy[0] says: "When a serious security concern is noticed, such 
as a major root compromise, it should be treated as a security-sensitive bug, 
and the Mozilla Policy for Handling Security Bugs should be followed." It is 
clear to us, and appears to be clear to other CAs based on their actions, that 
misissuances where domain control checks have failed fall into the category of 
"serious security concern".

Incident 0
--

On or around April 23rd, 2015, WoSign's certificate issuance system for their 
free certificates allowed the applicant to choose any port for validation. Once 
validation had been completed, WoSign would issue certificates for that domain. 
A researcher was able to obtain a certificate for a university by opening a 
high-numbered port (>50,000) and getting WoSign to use that port for validation 
of control.

This problem was reported to Google, and thence to WoSign and resolved.
Mozilla only became aware of it recently.

* Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
ports and paths which can be used, the Baseline Requirements said that one 
acceptable method of domain validation was "Having the Applicant demonstrate 
practical control over the FQDN by making an agreed‐upon change to information 
found on an online Web page identified by a uniform resource identifier 
containing the FQDN&

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Richard,

On 07/09/16 11:06, Richard Wang wrote:
> This discuss has been lasting two weeks, I think it is time to end
> it, it doesn’t worth to waste everybody’s precious time.

Unfortunately, I think we may be only beginning.

I have prepared a list of the issues we are tracking with WoSign's
certificate issuance process and business:

https://wiki.mozilla.org/CA:WoSign_Issues

Please can you provide a response to issues F, P, S and T at your
earliest convenience?

In addition, if you have further things to say about issues D, H, J, L,
N or V we would be happy to hear them.

Thank you for your suggestions, but once Mozilla has a full
understanding of what has gone on we will be in a better position to
decide what next actions are appropriate.

With best wishes,

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]

Got it, thanks.
We will reply to you soon.
By the way, the link you used in the page to our report is not correct.

Regards,

Richard

> On 7 Sep 2016, at 18:58, Gervase Markham  wrote:
> 
> Hi Richard,
> 
>> On 07/09/16 11:06, Richard Wang wrote:
>> This discuss has been lasting two weeks, I think it is time to end
>> it, it doesn’t worth to waste everybody’s precious time.
> 
> Unfortunately, I think we may be only beginning.
> 
> I have prepared a list of the issues we are tracking with WoSign's
> certificate issuance process and business:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Please can you provide a response to issues F, P, S and T at your
> earliest convenience?
> 
> In addition, if you have further things to say about issues D, H, J, L,
> N or V we would be happy to hear them.
> 
> Thank you for your suggestions, but once Mozilla has a full
> understanding of what has gone on we will be in a better position to
> decide what next actions are appropriate.
> 
> With best wishes,
> 
> Gerv


smime.p7s
Description: S/MIME cryptographic signature
___
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 07/09/16 12:14, Richard Wang wrote:
> By the way, the link you used in the page to our report is not correct.

Fixed; thank you.

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-07 13:00, Gervase Markham wrote:

Hi Richard,

On 07/09/16 11:06, Richard Wang wrote:

This discuss has been lasting two weeks, I think it is time to end
it, it doesn’t worth to waste everybody’s precious time.


Unfortunately, I think we may be only beginning.

I have prepared a list of the issues we are tracking with WoSign's
certificate issuance process and business:

https://wiki.mozilla.org/CA:WoSign_Issues


Thanks for putting this all in a page because I already lost track of 
most of the issues.


This URL was posted, and at least seems to match the date range:
https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662

It currently only has 314 of the mentioned 392 duplicates.  I don't know 
if there are other duplicate serials we need to look for, or if they 
failed to publish all 392.  It's at least my understanding that all 
certificates for 2015 should already have been submitted to CT.


Related to issue F, we've been told that all 2015 certificates should 
have been published to CT.  We got a mail saying that with "Date: Fri, 2 
Sep 2016 07:37:52 +".  I added the https://crt.sh/?id=30736090 to 
aviator later, and it's now in their log too.


I guess it could be useful for everybody to go over this page and see if 
all the issues that were raised are on that page.



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]

We posted all 2015 certificates, total 109,405

We almost finished 2016 certificates, till now, 129,426, not finished.

All 392 cert is not from one serial number, it is from several serial numbers.


Regards,

Richard

> On 7 Sep 2016, at 20:07, Kurt Roeckx  wrote:
> 
>> On 2016-09-07 13:00, Gervase Markham wrote:
>> Hi Richard,
>> 
>>> On 07/09/16 11:06, Richard Wang wrote:
>>> This discuss has been lasting two weeks, I think it is time to end
>>> it, it doesn’t worth to waste everybody’s precious time.
>> 
>> Unfortunately, I think we may be only beginning.
>> 
>> I have prepared a list of the issues we are tracking with WoSign's
>> certificate issuance process and business:
>> 
>> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Thanks for putting this all in a page because I already lost track of most of 
> the issues.
> 
> This URL was posted, and at least seems to match the date range:
> https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662
> 
> It currently only has 314 of the mentioned 392 duplicates.  I don't know if 
> there are other duplicate serials we need to look for, or if they failed to 
> publish all 392.  It's at least my understanding that all certificates for 
> 2015 should already have been submitted to CT.
> 
> Related to issue F, we've been told that all 2015 certificates should have 
> been published to CT.  We got a mail saying that with "Date: Fri, 2 Sep 2016 
> 07:37:52 +".  I added the https://crt.sh/?id=30736090 to aviator later, 
> and it's now in their log too.
> 
> I guess it could be useful for everybody to go over this page and see if all 
> the issues that were raised are on that page.
> 
> 
> Kurt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Rob Stradling]

On 06/09/16 19:12, Thijs Alkemade wrote:

> 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.

> 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.



-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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

[Thijs Alkemade]

On 07 Sep 2016, at 14:52, Rob Stradling  wrote:
> 
> On 06/09/16 19:12, Thijs Alkemade wrote:
> 
>> 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.
- S

Re: Incidents involving the CA WoSign

[Rob Stradling]

On 07/09/16 15:01, Thijs Alkemade wrote:

> 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.)

There could be an entirely innocent explanation for this.  Lots of
people were stockpiling SHA-1 certs during December 2015.  Daily
certificate issuance rates do vary.

> - 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.

Indeed.

-- 
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: Incidents involving the CA WoSign

[Gervase Markham]

On 07/09/16 13:52, Rob Stradling wrote:
> 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.

Hi Rob,

My digest of Thijs's work (and that of others investigating the same
issues) is here:
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_S:_Backdated_SHA-1_Certs_.28January_2016.29

Is every conclusion I draw justified from the data?

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

[dymutaos]

On Tuesday, September 6, 2016 at 10:10:44 PM UTC-4, Richard Wang wrote:
> ... we can't find the info what port is used, our CMS system just record this 
> order is validated by website control validation method, not record the used 
> port at that time.
> 
> Why we can find out other 72 certificate? We try to search every validation 
> process evidence in many systems to analyze the related log to catch the 
> info. I can't guarantee all high port validation order are listed in the 
> report, but as we said in the report, each certificate is properly validated 
> using high port.
> 
> 
> Best Regards,
> 
> Richard
> 

My trust in this CA has dropped even more. Even if all non-standard port 
validations were otherwise issued correctly, it does not bode well that 
WoSign's system failed to record enough information in its logs. If people are 
manually looking through logs for suspicious certificates, we can never be sure 
that they caught them all, and there may be false positives as well.

If the logs didn't store even the simple port information, what else isn't it 
storing? You say you'll do better in the future, but you have to be able to 
account for current and future bugs. In order to do that, you need accurate and 
verbose logs, or else a future vulnerability may be unable to be contained.
___
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

[Jozef Izso]

Richard, why the report does not mention that the list of certs issued using 
high port validation is not complete and that you cannot properly find all the 
relevant information in your system?

> On 7. 9. 2016, at 4:08, Richard Wang  wrote:
> 
> We checked our system that this order is finished the website control 
> validation correctly. No any mistake.
> 
> Why this is not listed in the report list? This order is year 2015 order, 
> this is the event of 17 months ago, we can't find the info what port is used, 
> our CMS system just record this order is validated by website control 
> validation method, not record the used port at that time.
> 
> Why we can find out other 72 certificate? We try to search every validation 
> process evidence in many systems to analyze the related log to catch the 
> info. I can't guarantee all high port validation order are listed in the 
> report, but as we said in the report, each certificate is properly validated 
> using high port.
> 
> 
> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: Julian Brost [mailto:jul...@0x4a42.net] 
> Sent: Wednesday, September 7, 2016 12:06 AM
> To: Richard Wang ; Gervase Markham ; 
> dev-security-policy@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
> 
> Hi,
> 
> section 1.4. Impact Analytics in the report contains a list of 72 
> certificates, for which the domain validation was done on a high port.
> 
> On 2015-04-20 I have obtained a certificate for a domain name that I 
> validated using port 8080 but that certificate is not listed in the report. 
> This is the certificate: https://crt.sh/?id=30335331
> 
> It seems like the certificate was posted to the CT logs by WoSign (at least I 
> never used the certificate anywhere) but not on August 26th like the other 
> certs and as stated in the report.
> 
> So I have doubts about the report and it really should be investigated why 
> this certificate is missing in the report.
> 
> Regards,
> Julian Brost
> 
>> On 04.09.2016 11:49, Richard Wang wrote:
>> Hi all,
>> 
>> We finished the investigation and released the incidents report today: 
>> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf
>> 
>> This report has 20 pages, please let me if you still have any questions, 
>> thanks.
>> 
>> This report is just for Incident 0-2, we will release a separate report for 
>> another incident X soon.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
>> 
>> -Original Message-
>> From: Gervase Markham [mailto:ge...@mozilla.org]
>> Sent: Wednesday, August 24, 2016 9:08 PM
>> To: mozilla-dev-s...@lists.mozilla.org
>> Cc: Richard Wang 
>> Subject: Incidents involving the CA WoSign
>> 
>> Dear m.d.s.policy,
>> 
>> Several incidents have come to our attention involving the CA "WoSign".
>> Mozilla is considering what action it should take in response to these 
>> incidents. This email sets out our understanding of the situation.
>> 
>> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
>> Enforcement Policy[0] says: "When a serious security concern is noticed, 
>> such as a major root compromise, it should be treated as a 
>> security-sensitive bug, and the Mozilla Policy for Handling Security Bugs 
>> should be followed." It is clear to us, and appears to be clear to other CAs 
>> based on their actions, that misissuances where domain control checks have 
>> failed fall into the category of "serious security concern".
>> 
>> Incident 0
>> --
>> 
>> On or around April 23rd, 2015, WoSign's certificate issuance system for 
>> their free certificates allowed the applicant to choose any port for 
>> validation. Once validation had been completed, WoSign would issue 
>> certificates for that domain. A researcher was able to obtain a certificate 
>> for a university by opening a high-numbered port (>50,000) and getting 
>> WoSign to use that port for validation of control.
>> 
>> This problem was reported to Google, and thence to WoSign and resolved.
>> Mozilla only became aware of it recently.
>> 
>> * Before the recent passage of Ballot 169 in the CAB Forum, which limits the 
>> ports and paths which can be used, the Baseline Requirements said that one 
>> acceptable method of domain validation was "Having the Applicant demonstrate 
>> practical control over the FQDN by making an agreed‐upon change to 
>> information found on an online Web page identified 

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On Wed, Sep 07, 2016 at 02:08:24PM +0200, Kurt Roeckx wrote:
> On 2016-09-07 13:00, Gervase Markham wrote:
> > Hi Richard,
> > 
> > On 07/09/16 11:06, Richard Wang wrote:
> > > This discuss has been lasting two weeks, I think it is time to end
> > > it, it doesn’t worth to waste everybody’s precious time.
> > 
> > Unfortunately, I think we may be only beginning.
> > 
> > I have prepared a list of the issues we are tracking with WoSign's
> > certificate issuance process and business:
> > 
> > https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Thanks for putting this all in a page because I already lost track of most
> of the issues.
> 
> This URL was posted, and at least seems to match the date range:
> https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662

So here are 27 others:
https://crt.sh/?serial=0d3bbdc3a0175e38f9d0070cd050986a&iCAID=1672

There is this weird combination:
https://crt.sh/?id=12729072
https://crt.sh/?id=12728869

We also have:
https://crt.sh/?id=9318242
https://crt.sh/?id=7841622


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

[Percy]

On Wednesday, September 7, 2016 at 3:08:33 AM UTC-7, Richard Wang wrote:
> Hi Gerv, Kathleen and Richard,
> 
> This discuss has been lasting two weeks, I think it is time to end it, it 
> doesn’t worth to waste everybody’s precious time.
> I make my confession that our system and management do have some problems 
> which lead to the misissuance of some certificates. And I am very sorry that 
> WoSign don’t notify all browsers after the incident happened and even after 
> the problem fixed.
> 
> I’d like to give my suggestion action for Mozilla as below:
> 1. Mozilla will trust those SSL certificates only:
> (1) The certificate notBefore date is before Jan. 1st 2015;
> (2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
> that listed in the Google CT log server;
> (3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
> that embedded SCT data in the certificate;
> (4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
> data in the certificate and must have the “C=CN” in the certificate subject.
> 

Since we already see backdated certificates AND certificates issued without any 
validation, the "C=CN" restriction might be easily defeated if further bugs are 
discovered in the automatic issuance system. 

> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
> inspect every incident, check every relevant issued certificate, and record a 
> report with:  what happened, why this happened and what is being done to 
> prevent this in the future etc., WoSign will pay the audit cost.
> 
> I’d like to make some supplements about 1. (4) above, this term means WoSign 
> will only issue SSL certificates to China subscribers. 
> WoSign issued about 120K SSL certificates for websites in China including 
> many central government websites like MIIT and many other local province 
> government websites, many university websites, many online banking websites, 
> 6 of the Top 10 ecommerce websites, big supermarket online store like 
> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
> companies. 
> Those customers like to use WoSign certificate especially our support of 
> Chinese, local support and customer service. And some of them paid up to 
> 10-year certificate fee in advance, we need to renew their certificate for 
> free once it is about to expire at every three years for OV SSL.
> 
> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
> better after getting this so big lesson. 
> Thank you.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Richard Wang
> Sent: Sunday, September 4, 2016 5:49 PM
> To: Gervase Markham ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
> 
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have failed fall into the 
> category of "serious security concern".
> 
> Incident 0
> --
> 
> On or around April 23rd, 2015, WoSign's certificate issuance system for their 
> free certificates allowed the applicant to choose

Re: Incidents involving the CA WoSign

[Rob Stradling]

On 07/09/16 17:02, Gervase Markham wrote:
> On 07/09/16 13:52, Rob Stradling wrote:
>> 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.
> 
> Hi Rob,
> 
> My digest of Thijs's work (and that of others investigating the same
> issues) is here:
> https://wiki.mozilla.org/CA:WoSign_Issues#Issue_S:_Backdated_SHA-1_Certs_.28January_2016.29
> 
> Is every conclusion I draw justified from the data?

Hi Gerv.  I'd like to discuss this particular conclusion:

  "...up to ID 109149...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."

ID 109153 (https://crt.sh/?id=30629275) is the first such certificate,
not 109150.  Also, these 64 certificates were not logged consecutively.
I've just posted details of the relevant range of log entries here:
https://gist.github.com/robstradling/129729531779dab448ca88049c49307c

These log entries were only created 5 or 6 days ago, and the majority
don't have corresponding precertificates.
Consider https://crt.sh/?id=30629293, for example.  Are you really
suggesting that this was issued on 2nd September 2016 but backdated to
20th December 2015?

The entry timestamps up to ID 109221 are all very close together
(several entries per second).  We know that WoSign were at that time
submitting all of the certs they issued in 2015, so this is not surprising.

I think it's unreasonable to assume that WoSign attempted to log the
certs they issued in 2015 in the order in which they were issued.

I look forward to reading WoSign's response to Issue S.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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 08/09/16 11:39, Rob Stradling wrote:
> Consider https://crt.sh/?id=30629293, for example.  Are you really
> suggesting that this was issued on 2nd September 2016 but backdated to
> 20th December 2015?

For simplicity, I've removed this section from Issue S. I think the
evidence related there stands alone without any log-number-related
inferences.

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

[Vincent Lynch]

On Wednesday, September 7, 2016 at 7:00:54 AM UTC-4, Gervase Markham wrote:
> Hi Richard,
> 
> On 07/09/16 11:06, Richard Wang wrote:
> > This discuss has been lasting two weeks, I think it is time to end
> > it, it doesn’t worth to waste everybody’s precious time.
> 
> Unfortunately, I think we may be only beginning.
> 
> I have prepared a list of the issues we are tracking with WoSign's
> certificate issuance process and business:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Please can you provide a response to issues F, P, S and T at your
> earliest convenience?
> 
> In addition, if you have further things to say about issues D, H, J, L,
> N or V we would be happy to hear them.
> 
> Thank you for your suggestions, but once Mozilla has a full
> understanding of what has gone on we will be in a better position to
> decide what next actions are appropriate.
> 
> With best wishes,
> 
> Gerv

Richard,

When you provide additional details about Issue P, can you specifically comment 
on why two of the certificates were issued for 4 years (48 months)?

Section 6.3.2 of the BRs states "Subscriber Certificates issued after 1 April 
2015 MUST have a Validity Period no greater than 39 months."

That section DID allow for an exception to that 39 month maximum if the CA 
documents that the certificate is being used in a case that satisfies a set of 
5 requirements (too lengthy to provide here). If this was the case, this would 
have been allowable until 30 June 2016 and these certificates' validity period 
would not be a violation. 

Can you comment on if these certificates satisfied the exception? And if so, 
can you provide WoSign's documentation of this?

In my opinion, this is one of the more concerning violations because it may 
show that it is trivially easy for WoSign's issuance software to issue 
certificates that violate the BRs.

(My understanding is that these certificates qualify as a Subscriber 
Certificate, the fact that the subject CN = wosign.net is irrelevant.)

Citation:
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_P:_Use_of_SM2_Algorithm_.28Nov_2015.29
___
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

[Ming]

在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道：
> Hi Gerv, Kathleen and Richard,
> 
> This discuss has been lasting two weeks, I think it is time to end it, it 
> doesn’t worth to waste everybody’s precious time.
> I make my confession that our system and management do have some problems 
> which lead to the misissuance of some certificates. And I am very sorry that 
> WoSign don’t notify all browsers after the incident happened and even after 
> the problem fixed.
> 
> I’d like to give my suggestion action for Mozilla as below:
> 1. Mozilla will trust those SSL certificates only:
> (1) The certificate notBefore date is before Jan. 1st 2015;
> (2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
> that listed in the Google CT log server;
> (3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
> that embedded SCT data in the certificate;
> (4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
> data in the certificate and must have the “C=CN” in the certificate subject.
> 
> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
> inspect every incident, check every relevant issued certificate, and record a 
> report with:  what happened, why this happened and what is being done to 
> prevent this in the future etc., WoSign will pay the audit cost.
> 
> I’d like to make some supplements about 1. (4) above, this term means WoSign 
> will only issue SSL certificates to China subscribers. 
> WoSign issued about 120K SSL certificates for websites in China including 
> many central government websites like MIIT and many other local province 
> government websites, many university websites, many online banking websites, 
> 6 of the Top 10 ecommerce websites, big supermarket online store like 
> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
> companies. 

Richard,I check the  top 10 e-commerce websites in China, ONLY suning.com and 
yhd.com are your subscribers; and ZERO of the top 5 cloud service companies in 
China use WoSign.

I have reason to doubt the authenticity of the data you provided. 

there is the top 10 e-commerce websites in China:
taobao.com
jd.com
tmall.com
amazon.cn
vip.com
meituan.com
suning.com
dangdang.com
jumei.com
yhd.com

the top 5 cloud service companies in China:
aliyun.com
qcloud.com
qingcloud.com
ucloud.cn
hwclouds.com


> Those customers like to use WoSign certificate especially our support of 
> Chinese, local support and customer service. And some of them paid up to 
> 10-year certificate fee in advance, we need to renew their certificate for 
> free once it is about to expire at every three years for OV SSL.
> 
> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
> better after getting this so big lesson. 
> Thank you.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Richard Wang
> Sent: Sunday, September 4, 2016 5:49 PM
> To: Gervase Markham ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
> 
> Hi all,
> 
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
> 
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
> 
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
> 
> 
> Best Regards,
> 
> Richard Wang
> CEO
> WoSign CA Limited
> 
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
> 
> Dear m.d.s.policy,
> 
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
> 
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> clear to us, and appears to be clear to other CAs based on their actions, 
> that misissuances where domain control checks have 

Re: Incidents involving the CA WoSign

[Richard Wang]

Your top 10 or top 5 is not same as my top 10 or top 5.
BTW, 
Dangdang.com is using our certificate: 
https://www.ssllabs.com/ssltest/analyze.html?d=login.dangdang.com&latest

Some is also using our certificate that you don't know.


Regards,

Richard

> On 8 Sep 2016, at 23:59, Ming  wrote:
> 
> 在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道：
>> Hi Gerv, Kathleen and Richard,
>> 
>> This discuss has been lasting two weeks, I think it is time to end it, it 
>> doesn’t worth to waste everybody’s precious time.
>> I make my confession that our system and management do have some problems 
>> which lead to the misissuance of some certificates. And I am very sorry that 
>> WoSign don’t notify all browsers after the incident happened and even after 
>> the problem fixed.
>> 
>> I’d like to give my suggestion action for Mozilla as below:
>> 1. Mozilla will trust those SSL certificates only:
>>(1) The certificate notBefore date is before Jan. 1st 2015;
>>(2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
>> that listed in the Google CT log server;
>>(3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
>> that embedded SCT data in the certificate;
>>(4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
>> data in the certificate and must have the “C=CN” in the certificate subject.
>> 
>> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
>> inspect every incident, check every relevant issued certificate, and record 
>> a report with:  what happened, why this happened and what is being done to 
>> prevent this in the future etc., WoSign will pay the audit cost.
>> 
>> I’d like to make some supplements about 1. (4) above, this term means WoSign 
>> will only issue SSL certificates to China subscribers. 
>> WoSign issued about 120K SSL certificates for websites in China including 
>> many central government websites like MIIT and many other local province 
>> government websites, many university websites, many online banking websites, 
>> 6 of the Top 10 ecommerce websites, big supermarket online store like 
>> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
>> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
>> companies.
> 
> Richard,I check the  top 10 e-commerce websites in China, ONLY suning.com and 
> yhd.com are your subscribers; and ZERO of the top 5 cloud service companies 
> in China use WoSign.
> 
> I have reason to doubt the authenticity of the data you provided. 
> 
> there is the top 10 e-commerce websites in China:
> taobao.com
> jd.com
> tmall.com
> amazon.cn
> vip.com
> meituan.com
> suning.com
> dangdang.com
> jumei.com
> yhd.com
> 
> the top 5 cloud service companies in China:
> aliyun.com
> qcloud.com
> qingcloud.com
> ucloud.cn
> hwclouds.com
> 
> 
>> Those customers like to use WoSign certificate especially our support of 
>> Chinese, local support and customer service. And some of them paid up to 
>> 10-year certificate fee in advance, we need to renew their certificate for 
>> free once it is about to expire at every three years for OV SSL.
>> 
>> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
>> better after getting this so big lesson. 
>> Thank you.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
>> 
>> -Original Message-
>> From: dev-security-policy 
>> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
>> Behalf Of Richard Wang
>> Sent: Sunday, September 4, 2016 5:49 PM
>> To: Gervase Markham ; 
>> mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: RE: Incidents involving the CA WoSign
>> 
>> Hi all,
>> 
>> We finished the investigation and released the incidents report today: 
>> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
>> 
>> This report has 20 pages, please let me if you still have any questions, 
>> thanks.
>> 
>> This report is just for Incident 0-2, we will release a separate report for 
>> another incident X soon.
>> 
>> 
>> Best Regards,
>> 
>> Richard Wang
>> CEO
>> WoSign CA Limited
>> 
>> 
>> -Original Message-
>> From: Gervase Markham [mailto:g...@mozilla.org] 
>> Sent: Wednesday, August 24, 2016 9:08 PM
>> To: mozilla-dev-security-pol...@lists.mozilla.org
>> Cc: Richard Wang 
>> Subject: Incidents in

Re: Incidents involving the CA WoSign

[Jakob Bohm]

On 07/09/2016 16:01, Thijs Alkemade wrote:

On 07 Sep 2016, at 14:52, Rob Stradling  wrote:


On 06/09/16 19:12, Thijs Alkemade wrote:


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 embe

Re: Incidents involving the CA WoSign

[Kyle Hamilton]

I do have to ask this, though:  WoSign has at least one EV issuer.  I do
not know if there is an issuer with EV permissions in NSS, but WoSign
does have an EV code signing issuer in the Microsoft root program.  Has
this issuer been checked to ensure that it could not have misissued
certificates?  (Yes, it's probably out of scope for mozilla's process. 
However, it's still something I'm curious about.)

Also, on #2: Will this audit apply to all WoSign issuers included in
NSS, or just a single one?  I count at least 4.

And finally, where does this leave StartCom?  Is there a need for
inquiries regarding StartCom's operations?

-Kyle H

On 9/7/2016 03:06, Richard Wang wrote:
> Hi Gerv, Kathleen and Richard,
>
> This discuss has been lasting two weeks, I think it is time to end it, it 
> doesn’t worth to waste everybody’s precious time.
> I make my confession that our system and management do have some problems 
> which lead to the misissuance of some certificates. And I am very sorry that 
> WoSign don’t notify all browsers after the incident happened and even after 
> the problem fixed.
>
> I’d like to give my suggestion action for Mozilla as below:
> 1. Mozilla will trust those SSL certificates only:
> (1) The certificate notBefore date is before Jan. 1st 2015;
> (2) The certificate notBefore date is from Jan. 1st 2015 to July 4th 2016 
> that listed in the Google CT log server;
> (3) The certificate notBefore date is from July 5th 2016 to Sept xx 2016 
> that embedded SCT data in the certificate;
> (4) The certificate notBefore date is from Sept xx 2016 that embedded SCT 
> data in the certificate and must have the “C=CN” in the certificate subject.
>
> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and 
> inspect every incident, check every relevant issued certificate, and record a 
> report with:  what happened, why this happened and what is being done to 
> prevent this in the future etc., WoSign will pay the audit cost.
>
> I’d like to make some supplements about 1. (4) above, this term means WoSign 
> will only issue SSL certificates to China subscribers. 
> WoSign issued about 120K SSL certificates for websites in China including 
> many central government websites like MIIT and many other local province 
> government websites, many university websites, many online banking websites, 
> 6 of the Top 10 ecommerce websites, big supermarket online store like 
> Walmart, 4 of the Top 5 cloud service in China, and many big companies that 
> listed in NYSE and Nasdaq, and many subsidiaries of foreign countries big 
> companies. 
> Those customers like to use WoSign certificate especially our support of 
> Chinese, local support and customer service. And some of them paid up to 
> 10-year certificate fee in advance, we need to renew their certificate for 
> free once it is about to expire at every three years for OV SSL.
>
> I wish Mozilla could accept my suggestion, and I am sure WoSign will do it 
> better after getting this so big lesson. 
> Thank you.
>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA Limited
>
>
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Richard Wang
> Sent: Sunday, September 4, 2016 5:49 PM
> To: Gervase Markham ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
>
> Hi all,
>
> We finished the investigation and released the incidents report today: 
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf 
>
> This report has 20 pages, please let me if you still have any questions, 
> thanks.
>
> This report is just for Incident 0-2, we will release a separate report for 
> another incident X soon.
>
>
> Best Regards,
>
> Richard Wang
> CEO
> WoSign CA Limited
>
>
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Wednesday, August 24, 2016 9:08 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Cc: Richard Wang 
> Subject: Incidents involving the CA WoSign
>
> Dear m.d.s.policy,
>
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
>
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is noticed, such 
> as a major root compromise, it should be treated as a security-sensitive bug, 
> and the Mozilla Policy for Handling Security Bugs should be followed." It is 
> c

Re: Incidents involving the CA WoSign

[Ming]

Can you list the China top 10 e-commerce websites and the China top 5 cloud
service companies in WoSign's opinion？
In this web page: https://www.wosign.com/english/Who_uses_wosign.htm, I
only find yhd.com dangdang.com and suning.com are famous e-commerce
websites in China.


2016-09-09 0:14 GMT+08:00 Richard Wang :

> Your top 10 or top 5 is not same as my top 10 or top 5.
> BTW,
> Dangdang.com is using our certificate: https://www.ssllabs.com/
> ssltest/analyze.html?d=login.dangdang.com&latest
>
> Some is also using our certificate that you don't know.
>
>
> Regards,
>
> Richard
>
> > On 8 Sep 2016, at 23:59, Ming  wrote:
> >
> > 在 2016年9月7日星期三 UTC+8下午6:08:33，Richard Wang写道：
> >> Hi Gerv, Kathleen and Richard,
> >>
> >> This discuss has been lasting two weeks, I think it is time to end it,
> it doesn’t worth to waste everybody’s precious time.
> >> I make my confession that our system and management do have some
> problems which lead to the misissuance of some certificates. And I am very
> sorry that WoSign don’t notify all browsers after the incident happened and
> even after the problem fixed.
> >>
> >> I’d like to give my suggestion action for Mozilla as below:
> >> 1. Mozilla will trust those SSL certificates only:
> >>(1) The certificate notBefore date is before Jan. 1st 2015;
> >>(2) The certificate notBefore date is from Jan. 1st 2015 to July 4th
> 2016 that listed in the Google CT log server;
> >>(3) The certificate notBefore date is from July 5th 2016 to Sept xx
> 2016 that embedded SCT data in the certificate;
> >>(4) The certificate notBefore date is from Sept xx 2016 that
> embedded SCT data in the certificate and must have the “C=CN” in the
> certificate subject.
> >>
> >> 2. Mozilla can assign a WebTrust auditor to WoSign office to check and
> inspect every incident, check every relevant issued certificate, and record
> a report with:  what happened, why this happened and what is being done to
> prevent this in the future etc., WoSign will pay the audit cost.
> >>
> >> I’d like to make some supplements about 1. (4) above, this term means
> WoSign will only issue SSL certificates to China subscribers.
> >> WoSign issued about 120K SSL certificates for websites in China
> including many central government websites like MIIT and many other local
> province government websites, many university websites, many online banking
> websites, 6 of the Top 10 ecommerce websites, big supermarket online store
> like Walmart, 4 of the Top 5 cloud service in China, and many big companies
> that listed in NYSE and Nasdaq, and many subsidiaries of foreign countries
> big companies.
> >
> > Richard,I check the  top 10 e-commerce websites in China, ONLY
> suning.com and yhd.com are your subscribers; and ZERO of the top 5 cloud
> service companies in China use WoSign.
> >
> > I have reason to doubt the authenticity of the data you provided.
> >
> > there is the top 10 e-commerce websites in China:
> > taobao.com
> > jd.com
> > tmall.com
> > amazon.cn
> > vip.com
> > meituan.com
> > suning.com
> > dangdang.com
> > jumei.com
> > yhd.com
> >
> > the top 5 cloud service companies in China:
> > aliyun.com
> > qcloud.com
> > qingcloud.com
> > ucloud.cn
> > hwclouds.com
> >
> >
> >> Those customers like to use WoSign certificate especially our support
> of Chinese, local support and customer service. And some of them paid up to
> 10-year certificate fee in advance, we need to renew their certificate for
> free once it is about to expire at every three years for OV SSL.
> >>
> >> I wish Mozilla could accept my suggestion, and I am sure WoSign will do
> it better after getting this so big lesson.
> >> Thank you.
> >>
> >>
> >> Best Regards,
> >>
> >> Richard Wang
> >> CEO
> >> WoSign CA Limited
> >>
> >>
> >> -Original Message-
> >> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> wosign@lists.mozilla.org] On Behalf Of Richard Wang
> >> Sent: Sunday, September 4, 2016 5:49 PM
> >> To: Gervase Markham ; mozilla-dev-security-policy@
> lists.mozilla.org
> >> Subject: RE: Incidents involving the CA WoSign
> >>
> >> Hi all,
> >>
> >> We finished the investigation and released the incidents report today:
> https://www.wosign.com/report/wosign_incidents_report_09042016.pdf
> >>
> >> This report has 20 pages, please let me if you s

Re: Incidents involving the CA WoSign

[Richard Wang]

Hi all,

We will publish a more comprehensive report in the next several days that will 
attempt to cover most / all issues.
Thanks for your patience.

Regards,

Richard

> On 7 Sep 2016, at 18:58, Gervase Markham  wrote:
> 
> Hi Richard,
> 
>> On 07/09/16 11:06, Richard Wang wrote:
>> This discuss has been lasting two weeks, I think it is time to end
>> it, it doesn’t worth to waste everybody’s precious time.
> 
> Unfortunately, I think we may be only beginning.
> 
> I have prepared a list of the issues we are tracking with WoSign's
> certificate issuance process and business:
> 
> https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Please can you provide a response to issues F, P, S and T at your
> earliest convenience?
> 
> In addition, if you have further things to say about issues D, H, J, L,
> N or V we would be happy to hear them.
> 
> Thank you for your suggestions, but once Mozilla has a full
> understanding of what has gone on we will be in a better position to
> decide what next actions are appropriate.
> 
> With best wishes,
> 
> Gerv


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy