Re: Incidents involving the CA WoSign

[Percy]

"Some certificates are revoked after getting report from subscriber, but some 
still valid, if any subscriber think it must be revoked and replaced new one, 
please contact us in the system, thanks"

WoSign seems to lack the basic understanding of how a certificate is used in 
authentication, consequently unfit to be a CA, I call for revocation of WoSign 
from all root programs immediately.   
http://www.percya.com/2016/08/chinese-ca-wosign-faces-revocation.html
___
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, August 29, 2016 at 10:26:20 AM UTC-7, Gervase Markham wrote:
> On 29/08/16 09:48, 蓝小灰 wrote:
> > Of course I have private key of this certificate
> 
> I have asked 蓝小灰 for cryptographic proof of this.
> 
> Gerv

Gerv, I've notified the security team in Alibaba about this possible fake cert 
and ask them to confirm that they have not applied a cert. 
It's unlikely that Alibaba will use a free cert from WoSign. As a commercial 
site, they usually use Verisign or globalSign
___
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 26/08/16 06:12, 233sec Team wrote:
> 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...

Can you prove you have control of the private key associated with this
certificate?

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]

As I explained, we use same script using API, different parameter point to 
different API post URL for different CA, no any PKI hosting related.

Regards,

Richard

> On 29 Aug 2016, at 16:25, Gervase Markham  wrote:
> 
>> On 24/08/16 17:44, Peter Bowen wrote:
>> I think you are missing the most likely option: CA hosting.  My
>> understanding is that it is not uncommon that one CA operator
>> contracts with another CA operator to run a CA on behalf of the first
>> operator.  I don't think it has been clear what disclosure of this
>> practice is required.  Given that I believe this is widespread, I
>> assumed that all of the issuing CAs in this case were operated by the
>> same entity.
> 
> If StartCom are hosting WoSign's infra (seems less likely), then it's
> still a pretty severe mistake to accidentally issue a certificate from
> one of your customer's roots rather than your own, although one might
> say the mistake in this case would be StartCom's.
> 
> If WoSign are hosting StartCom's infra, it still leaves open the
> question of why StartCom are deploying code that WoSign are no longer
> using, and haven't for six months, and why WoSign permitted the StartCom
> UI to issue WoSign certificates at all.
> 
> 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 26/08/16 04:33, Richard Wang wrote:
> As I admitted that this discussion gives us a big lesson that we know
> when we need to report incident to all browsers. We guarantee we will
> do it better.

Richard,

You have been involved in this (Mozilla) discussion group and in the CAB
Forum for several years. In that time, you will have seen multiple CAs
disclose instances where certificates were misissued, and you will have
seen root programs take such disclosures seriously and consider them
important. Did it not occur to you that the same standard of disclosure
that everyone else was using should also apply to WoSign?

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]

Yes, we plan to revoke all after getting confirmation from subscriber. We are 
doing this.

Regards,

Richard

> On 29 Aug 2016, at 16:38, Gervase Markham  wrote:
> 
>> On 29/08/16 05:46, Richard Wang wrote:
>> For incident 1 - mis-issued certificate with un-validated subdomain,
>> total 33 certificates. We have posted to CT log server and listed in
>> crt.sh, here is the URL. Some certificates are revoked after getting
>> report from subscriber, but some still valid, if any subscriber think
>> it must be revoked and replaced new one, please contact us in the
>> system, thanks.
> 
> Er, no. If these certificates were issued with unvalidated parent
> domains (e.g. with github.com when the person validation foo.github.com)
> then they need to all be revoked. You should actively contact your
> customers and issue them new certificates containing only validated
> information, and then revoke these ones.
> 
> 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

[Richard Wang]

Sure, all issued cert is passed the domain control validations. 

Regards,

Richard

> On 29 Aug 2016, at 16:30, Gervase Markham  wrote:
> 
>> On 25/08/16 04:38, Richard Wang wrote:
>> R: NOT this case you think. Due to root inclusion problem, WoSign
>> root is cross signed by StartCom since 2011. And we shared some
>> facility with StartCom like CRL and OCSP distribution etc. But not
>> this case, as I declared in the previous email, this is a API
>> parameter option that can post data to any server located in any
>> place.
> 
> At what point in this process is the domain control validation done?
> 
> 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

[233sec Team]

Not vulnerabilities mentioned in this thread, but a Human-Audit weak process.
Detail you can see the reply content i send to Mr.Wang

在 2016年8月27日星期六 UTC+8上午4:24:44，Jonathan Rudenberg：
> Here’s the crt.sh link for this certificate: https://crt.sh/?id=29884704
> 
> Can you provide more details about where this certificate came from? Did you 
> issue it using one of the vulnerabilities discussed in this thread?
> 
> > On Aug 26, 2016, at 01:12, 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...
> > ___
> > 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

[xcrailfans]

On Friday, August 26, 2016 at 4:26:26 PM UTC+8, Richard Wang wrote:
> This is the standard way in China Internet, if a west company say something 
> to China company, all will support the west company.

-- especially when local CAs are losing credibility to end-users. Microsoft 
Azure's Chinese website[1] has migrated from CNNIC CA, to WoSign, and recently 
to DigiCert. CNNIC itself, ironically, also moved to DigiCert.

[1]: azure.cn

It is almost axiomatic that without a proper statement & fix (no more 233sec 
team exploits) made, WoSign will continue losing trust from end-users as well 
as webmasters.

> PLEASE don’t move this technical problem to political issue, thanks.

Very unfortunately WoSign's advertisements are seemingly doing the opposite. On 
this comparison between WoSign and foreign CAs[2], you made the following 
statements:

[2]: 
http://wayback.archive.org/web/20160828045112/https://www.wosign.com/about/WoSign_ForeignCA_compare.htm

* Security: handled by Chinese company itself, fully secure. (Foreign CA: 
System Security should not be a problem, but risks of random revokes and/or 
access failures exist.)
* Compliance with Chinese Law: Yes (Foreign CA: No, legal risks exist.)


> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of percyal...@gmail.com
> Sent: Friday, August 26, 2016 4:05 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Incidents involving the CA WoSign
> 
> The news about possible sanction against WoSign was reported by Solidot 
> http://www.solidot.org/story?sid=49448
> (the Chinese version of Slashdot). Out of 12 comments in total (at the time 
> of writing), 8 of them call for revocation of WoSign, the rest talks about 
> the general bad security practices in China.
> 
> A quick intro of myself. 
> I'm Percy Alpha and I broke the news on GFW's MITM attack on iCloud, Outlook 
> and Yahoo in 2014 and was later the victim of Great Cannon attack in 2015. 
> ___
> 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: Next CA Communication -- September?

[Nick Lamb]

On Tuesday, 23 August 2016 20:03:13 UTC+1, Kathleen Wilson  wrote:
> Are there any other topics that I should include in this upcoming CA 
> Communication?

It can be worth following-up on date-in-time commitments from those CAs in 
replies to the previous communication this year. Each CA should be able to 
confirm either that the committed action has now happened as planned, or is 
delayed and give a new hoped-for date.


China Internet Network Information Center (CNNIC) wrote "We plan to upgrade 
device and software and also deploy new SHA 256 intermediate Root (operated by 
CNNIC ) to issue SHA256 DV and EV cert by the end of May, 2016."

RSA the Security Division of EMC wrote of their SHA-1 signing "There is a plan 
in place to change this to SHA-2 by June 15, 2016"

SwissSign AG wrote also of a system that still uses SHA-1 "We will Change this 
to SHA2 until August 2016."

Swisscom (Switzerland) Ltd wrote "SHA-1 S/MIME certificates are still being 
issued since one our customers did not fully migrate to SHA-256 yet. Deadline 
for this migration is 06/30/2016, from this date on, no more SHA-1 based S/MIME 
certificates will be issued"


Telia Company (formerly TeliaSonera) wrote that they need "more time up to 
06/30/2016 to find the details" of certificates which lack a matching SAN for 
the CN.

Trustis wrote "KeyUsage will be added to all Certificates with effect from 
05/30/2016"

T-Systems International GmbH (Deutsche Telekom) wrote that dubious OCSP 
responses "will be fixed by June 02, 2016."  and also that "We plan to switch 
to SHA-2 until Q3/2016" for CRL signing.

Autoridad de Certificacion Firmaprofesional wrote that certificates with no 
corresponding SAN for their CN "will be revoked by July, the 1st, 2016"

Camerfirma use BMPString in the certificate DN, but "We plan to have a solution 
in a couple of months"

DocuSign (OpenTrust/Keynectis)  likewise use unsupported encodings in the DN. 
They wrote "Last issuance date will be 06/30/2016"

Entrust again with unsupported DN encodings, wrote "last issuance date could be 
as late as 30 June 2016"

Government of Hong Kong (SAR), Hongkong Post, Certizen, wrote that they "Will 
stop issuing SSL certificates without the DNSName entry in the subjectAltName 
extension on 1 Sep 2016."

Government of The Netherlands, PKIoverheid (Logius) wrote "We are in the 
process of altering our CP with regard to this issue. Our new CP will be 
effective coming July."

WISeKey wrote of continued non-SSL SHA-1 issuance "We expect this situation to 
be solved during the first half of 2016 "

I am sure we all recognise that it is easy to make commitments about the future 
but not always so easy to keep them. For this reason I think reminders are 
useful. Because the earlier replies with these dates in were public, updates 
should be made public too. However it may be more appropriate to handle these 
as individual messages rather than a mass communication.
___
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

[Patrick Figel]

Richard,

the problem with this approach is that the *subscriber* might not be
authorized to make this decision for the parent domain. To go back to
the GitHub case, the "owner" of a github.io subdomain telling you that
they are authorized to own a certificate that covers github.io is
irrelevant, as they have never demonstrated ownership of that domain.

The right approach would be to revoke the affected certificates
immediately and inform your subscribers that they will need to re-issue
their certificates (while also verifying ownership of the root domain).

Here's another similar case - cloudapp.net, which belongs to Microsoft
Azure. I'm fairly certain this certificate was not authorized by Microsoft:

https://crt.sh/?id=2980

Thanks,

Patrick

On 29/08/16 11:30, Richard Wang wrote:
> Yes, we plan to revoke all after getting confirmation from
> subscriber. We are doing this.
> 
> Regards,
> 
> Richard
> 
>> On 29 Aug 2016, at 16:38, Gervase Markham 
>> wrote:
>> 
>>> On 29/08/16 05:46, Richard Wang wrote: For incident 1 -
>>> mis-issued certificate with un-validated subdomain, total 33
>>> certificates. We have posted to CT log server and listed in 
>>> crt.sh, here is the URL. Some certificates are revoked after
>>> getting report from subscriber, but some still valid, if any
>>> subscriber think it must be revoked and replaced new one, please
>>> contact us in the system, thanks.
>> 
>> Er, no. If these certificates were issued with unvalidated parent 
>> domains (e.g. with github.com when the person validation
>> foo.github.com) then they need to all be revoked. You should
>> actively contact your customers and issue them new certificates
>> containing only validated information, and then revoke these ones.
>> 
>> Gerv
>> 
>> 
>> ___ 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: Next CA Communication -- September?

[Nick Lamb]

On Tuesday, 23 August 2016 20:03:13 UTC+1, Kathleen Wilson  wrote:
> Are there any other topics that I should include in this upcoming CA 
> Communication?

Also, I think that the SHA-1 topic should be brought up again. Some CA folks 
will be tired of reading about this, having managed the issue with their 
customers and performed an orderly migration years ago. But for others every 
communication from Mozilla is a renewed impetus to actually get on with the 
job. An ounce of prevention now is worth a pound of cure in January.

It doesn't need to be as elaborate as the previous communication, for example  
it could ask CAs to confirm that they've taken reasonable steps to contact any 
affected subscribers and make sure those subscribers understand what action 
they should take, what the deadlines are, and what will happen if they do 
nothing.
___
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]

OK, revoke all at tomorrow morning since our time is 22:22 now.
The cloudapp.net is revoked at the issuance time.

Thanks.

Regards,

Richard

> On 29 Aug 2016, at 21:53, Patrick Figel  wrote:
> 
> Richard,
> 
> the problem with this approach is that the *subscriber* might not be
> authorized to make this decision for the parent domain. To go back to
> the GitHub case, the "owner" of a github.io subdomain telling you that
> they are authorized to own a certificate that covers github.io is
> irrelevant, as they have never demonstrated ownership of that domain.
> 
> The right approach would be to revoke the affected certificates
> immediately and inform your subscribers that they will need to re-issue
> their certificates (while also verifying ownership of the root domain).
> 
> Here's another similar case - cloudapp.net, which belongs to Microsoft
> Azure. I'm fairly certain this certificate was not authorized by Microsoft:
> 
> https://crt.sh/?id=2980
> 
> Thanks,
> 
> Patrick
> 
>> On 29/08/16 11:30, Richard Wang wrote:
>> Yes, we plan to revoke all after getting confirmation from
>> subscriber. We are doing this.
>> 
>> Regards,
>> 
>> Richard
>> 
>>> On 29 Aug 2016, at 16:38, Gervase Markham 
>>> wrote:
>>> 
 On 29/08/16 05:46, Richard Wang wrote: For incident 1 -
 mis-issued certificate with un-validated subdomain, total 33
 certificates. We have posted to CT log server and listed in 
 crt.sh, here is the URL. Some certificates are revoked after
 getting report from subscriber, but some still valid, if any
 subscriber think it must be revoked and replaced new one, please
 contact us in the system, thanks.
>>> 
>>> Er, no. If these certificates were issued with unvalidated parent 
>>> domains (e.g. with github.com when the person validation
>>> foo.github.com) then they need to all be revoked. You should
>>> actively contact your customers and issue them new certificates
>>> containing only validated information, and then revoke these ones.
>>> 
>>> Gerv
>>> 
>>> 
>>> ___ 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

[Gervase Markham]

On 29/08/16 09:48, 蓝小灰 wrote:
> Of course I have private key of this certificate

I have asked 蓝小灰 for cryptographic proof of this.

Gerv


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