date:20160902

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.

Best Regards,

Richard

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

On Wed, Aug 31, 2016 at 8:04 PM, Richard Wang  wrote:
> (1) WoSign totally issued 100K SSL certificates in 2015 that we are 
> posting to CT log server (not 115K, Sorry, I used the wrong search condition);
> (2) WoSign totally issued 230K SSL certificates till now for worldwide 
> websites about 208 countries and regions.

As of yesterday, I found 131924 unique certificates (either in final or 
precertificate form) in CT logs where the issuer contained the string "wosign". 
 Of these, 62412 have notBefore with the year 2015.
Of the total set, 20723 have already expired (15.7%).  Of the 2015 certs, 9380 
are already expired (15.0%).

Based on the 230K total number, it seems save to assume about 196K certs are 
probably unexpired at this point.  Does that seem accurate?
___
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

Just wrote a blog post on this. WoSign's secret purchase of StartCom; WoSign 
threatened legal actions over the disclosure 
http://www.percya.com/2016/09/wosigns-secret-purchase-of-startcom.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Reuse of serial numbers by StartCom

2016-09-02 Thread Eddy Nigg


On 09/01/2016 11:52 AM, Nick Lamb wrote:

On Thursday, 1 September 2016 08:54:16 UTC+1, Eddy Nigg  wrote:

Not so, rather according to my assessment, the cost and everything it
entailed (including other risks) to fix that particular issue outweighed
the benefits for having it fixed within a time-frame shorter than that.

It seems to me that was not your decision to make. The relying parties trust StartCom on 
the basis that it will do what it said it would do, not just whatever "in your 
assessment" offers most benefits to you. The only option that was permissible 
without seeking some exception was to cease issuance until the problem was repaired.


First of all the issue can have been considered fixed due to machine 
test - evidence for some occurrences took month to resurface and at such 
low numbers that couldn't be reproduced (something almost required to 
fix a bug). I'm not sure if you or others here are programers, but 
knowing how things work and once we had evidence that there was still a 
very low occurrence, a plan was set up which included a different 
hardware and infrastructure.



To StartCom, ceasing issuance feels like a really big risk, that is understood. 
But for the relying parties it's not.


Lets speak about relying parties - how does this bug affect you?

--
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: Reuse of serial numbers

2016-09-02 Thread Eddy Nigg


On 09/01/2016 01:29 PM, Peter Gutmann wrote:

I also get the feeling that a lot of PKI software won't handle the revocation
properly, because they're expecting to revoke *the* certificate, not the
certificate, and the other certificate, and that other one there too, and that
one in the corner, and ... .  In other words I'm assuming most code will treat
serial numbers as unique and assume the revocation acted on when the first
cert has been marked as invalid.



From my experience, once one of the certificates has been revoked, it's 
basically for all of them with the same serial and issuer. At the PKI 
all certificates with the same serial must be revoked however to get a 
unique serial order.


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


On 2016-09-02 05:59, Peter Gutmann wrote:

Vincent Lynch  writes:


I think Eddy Nigg (founder of StartCom) and/or Richard Wang (of WoSign)
should make a statement about this.


+1.  I'd already asked for something like this earlier and got silence as a
response, which isn't inspiring confidence.


The whole interaction isn't inspiring confidence.


Kurt

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

Re: Reuse of serial numbers by StartCom

2016-09-02 Thread Eddy Nigg


On 09/02/2016 09:38 AM, Jakob Bohm wrote:

4. Violations that are purely technical but cannot actually endanger
relying parties (such as issuing non-unique certificates to the correct
entities, or issuing certificates with too early expiry dates). This
would be the case with the StartCom serial number assignment bug.

The way Eddy Nigg describes the issue, it appears there is some kind of
low level race condition in the code or hardware that increments and
uses the serial number counter deep inside the CA, perhaps in a heavily
locked down HSM that prevents fixing the issue without generating a new
CA key.


You are pretty close



If this is the case, and they correctly store the actually issued
certificates with the wrong serial numbers, the main problem would be
the inability to revoke one certificate without revoking the others,
while a secondary problem could be relying parties rejecting the
certificates if they actually see more than one of a set of conflicting
ones within their local cache lifetime.  Since both of those problems
would be limited to the certificates not being trusted when the facts
that should get them trusted are in place, there is no real danger.


You nailed it - I just asked the question about how it affects relying 
parties in an other reply to the list, you answered already.




StartCom is of cause one of those high speed DV CAs, that promise cheap
DV issuance within minutes of the request being submitted.  So
preventing occasional non-dangerous (but obviously non-compliant)
serial number collisions would require more than average skill by
hardware, firmware and software engineers.


True - and this was planned AND implemented.



That said, they really, really should have set up an automated test
script that scans issued certificates for the problem and raises an
alarm so such certificates would be reissued (with distinct serial
numbers) and revoked within a few days of each failure.



True that we could have done what you suggested. I don't really recall 
why we didn't, though I think things got easier with CT today for 
similar issues.
The fact is that it didn't had really an effect on the certificate 
holder or relying parties (except in case of a revocation in which case 
both certificates would have been revoked and probably issued again 
depending on the circumstances of the revocation).


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

On Fri, Sep 02, 2016 at 06:53:23AM +, Richard Wang wrote:
> I think we are out of topic.

On the contrary, the trustworthiness of CAs is *entirely* on topic.

- Matt

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

Re: Sanctions short of distrust

2016-09-02 Thread Henri Sivonen

(I'm replying to the topic as posed in the abstract and as a user with
Mozilla hat off. No suggestion of applicability to cases currently
under discussion should be inferred.)

On Wed, Aug 31, 2016 at 10:43 PM, Nick Lamb  wrote:
> 1. Implement "Require SCTs" for problematic CAs. Notify the CA they are 
> obliged to CT log all certificates, inform subscribers etc. or their 
> subscriber's certificates will suddenly be invalid in Firefox from some 
> future date.
...
> 2. Create "at risk" category for problematic CAs which lasts some finite 
> period of time (or a period to be set in each case). Notify the CA they are 
> obliged to warn their subscribers of this status or leave the Mozilla 
> programme immediately. Publicly announce "at risk" status and drive as PR.
...
> 3. Split NSS trust store into two or more categories based on degree of 
> trustworthiness. Maybe present a Firefox pref to pick "secure" vs "compatible"

Maybe these are too obvious, but let's mention these for completeness anyway:

4. Stop giving EV treatment to certs designated as EV by problematic CAs.

5. Show the "sites with mixed content allowed" icon (see
https://blog.mozilla.org/tanvi/2016/01/26/updated-firefox-security-indicators/
) when some connection contributing to the current browsing context
tree uses a cert from a problematic CA with doorhanger text customized
to talk about problematic status of CA.

6. Distrust certificates whole notBefore is before a designated point
in time or whose notAfter minus legitimate validity period is after a
designated point in time. Since the CA, technically, could backdate
certs, for this option to make sense there'd need to be some credible
incentive not to backdate certs. (It's not logically necessary for
incentive to arise from Mozilla's root program or Firefox's behavior
as long as an incentive exists.)

On Thu, Sep 1, 2016 at 10:30 AM, Ryan Sleevi  wrote:
> What was discussed in the Forum is the lack of defined policies for what it 
> means to "implement CAA". For example, if Trustwave were to see a CAA record 
> for "symantec.com", could it issue the cert?

Couldn't the CAA contents that allow the problematic CA to issue certs
be enumerated as part of the "problematic" designation?

> To what forms does the CAA record apply with regards to issuance - for 
> example, if a CA were to go in person, sit down in front of the CTO/COO, 
> verify their passport, verify with their lawyers that the CTO was duly 
> authorized, then even if the CAA record said otherwise, could they issue then?

I'd expect issuance not to be allowed in that case (at least if the
CAA record is still there after clearing DNS caches). Surely a
legitimate CTO should have the means to have the CAA record adjusted
(even if a CTO couldn't change a mistakenly long previously-set TTL).

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

You mean if a Chinese, a Chinese company own a USA CA, then the USA CA become 
un-trustworthiness?

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


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Matt Palmer
Sent: Friday, September 2, 2016 4:51 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Fri, Sep 02, 2016 at 06:53:23AM +, Richard Wang wrote:
> I think we are out of topic.

On the contrary, the trustworthiness of CAs is *entirely* on topic.

- 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

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

Hi Richard,

On 02/09/16 06:59, Richard Wang wrote:
> 1. Eddy told me that this guy is the former employee of StartCom, he
> violates the signed NDA that he must shutdown the site within the
> limit time. Every re-distribution the wrong information will heavy
> his penalty (including site cache or mirror site).  I am sure every
> company don't like its former employee to expose company's
> confidential information.

What information on that site is company-confidential? It all seems to
point to public sources.

Also, it would help if you pointed out what information is incorrect, so
we can make sure we don't accidentally accept any information which is
incorrect.

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

Re: Sanctions short of distrust

On 31/08/16 20:43, Nick Lamb wrote:
> This suggests the need for some options short of distrust which can
> be deployed instead, but Mozilla does not seem to have any. If in
> fact it already does, this would be a great place to say what they
> are and discuss why they haven't been able to be used in recent
> cases.

Have you considered what was done for CNNIC? In that case, we distrusted
all certificates issued after a certain time. We used a whitelist for
determining this, but it would be possible to use the notBefore date in
the certificate. A CA could dodge this by backdating, but if the CA were
also committed to putting all its certs in to CT, then the backdating
would be noticeable.

> 1. Implement "Require SCTs" for problematic CAs. Notify the CA they
> are obliged to CT log all certificates, inform subscribers etc. or
> their subscriber's certificates will suddenly be invalid in Firefox
> from some future date.

This is not currently possible in Firefox, as Firefox does not have the
ability to check SCTs. We hope to have that ability soon.

> 2. Create "at risk" category for problematic CAs which lasts some
> finite period of time (or a period to be set in each case). Notify
> the CA they are obliged to warn their subscribers of this status or
> leave the Mozilla programme immediately. Publicly announce "at risk"
> status and drive as PR.

One issue to consider with this option would be that reputational damage
is harder to quantify and control than a technical measure, which might
be said to increase the risk that the action would be disproportionate.

> 3. Split NSS trust store into two or more categories based on degree
> of trustworthiness. Maybe present a Firefox pref to pick "secure" vs
> "compatible"

Non-starter, I'm afraid. We are not loading this problem on to users.

> Finally, I would like to mention, though I expect it to be shot down,
> a much more radical way forward. RP audits. Relying Party audits.

Some issues to consider with this approach would be:

* How does the money to pay for such audits flow from the CA to the
auditor, and through whom?

* Who chooses the auditors?

* How do you make sure they remain independent when their funding is
(even indirectly) from the CAs?

* How do you deal with confidentiality issues? CAs have some things they
legitimately wish to keep confidential. And yet such an auditor would
need full access to all their infra and business processes.

* Is it a problem that adding additional costs to becoming a CA
discourages new and possibly innovative companies from entering the market?

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

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.

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

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: website control validation problem


On 2016-09-02 04:22, Richard Wang wrote:

For https://crt.sh/?id=29884704 , he finished the website control validation.

We and Alibaba are investigating why he can do the website control validation.

The is the log, but we can't expose more now since it is related to Alibaba.

2016-06-23 01:34:39:  WoSign validation system received domain "alicdn.com" website 
control request，the url is "http://alicdn.com/alicdn.com.html";, v_random is 
2e3baabe989fad9f143517796ed4941c13e7177b, Validation system used Get method, 400 error, then change 
to use POST method, success.


I'm wondering why you try to use POST, and what you could be posting there.


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

-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

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

(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

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

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

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

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: Reuse of serial numbers by StartCom

2016-09-02 Thread Nick Lamb

On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg  wrote:
> Lets speak about relying parties - how does this bug affect you?

As a relying party I am entitled to assume that there is no more than one 
certificate signed by a particular issuer with a certain serial number. If I 
have seen this certificate and verified by whatever means I choose that it's 
OK, then I can safely assume that any time I see a certificate in the future 
signed by that issuer with that same serial number it's the same one, and skip 
the verification process.

Except, with StartCom apparently this very basic rule is broken, and in fact at 
any time I may be presented with a certificate I haven't previously verified, 
but which has the exact same serial number as an earlier one.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sanctions short of distrust

2016-09-02 Thread Jakob Bohm


On 02/09/2016 12:19, Gervase Markham wrote:

On 31/08/16 20:43, Nick Lamb wrote:

This suggests the need for some options short of distrust which can
be deployed instead, but Mozilla does not seem to have any. If in
fact it already does, this would be a great place to say what they
are and discuss why they haven't been able to be used in recent
cases.


Have you considered what was done for CNNIC? In that case, we distrusted
all certificates issued after a certain time. We used a whitelist for
determining this, but it would be possible to use the notBefore date in
the certificate. A CA could dodge this by backdating, but if the CA were
also committed to putting all its certs in to CT, then the backdating
would be noticeable.



If the fraudulently backdated certificates are done (technically)
right, they would have serial numbers consistent with their old date
and would have non-CT logging also consistent with that old date.

Thus the only way to detect that those certificates were not in fact
issued before the cut off date would be to check against an independent
white list of actual pre-cut-off certificates.  (Longer recipe at end
of this post).


1. Implement "Require SCTs" for problematic CAs. Notify the CA they
are obliged to CT log all certificates, inform subscribers etc. or
their subscriber's certificates will suddenly be invalid in Firefox
from some future date.


This is not currently possible in Firefox, as Firefox does not have the
ability to check SCTs. We hope to have that ability soon.


2. Create "at risk" category for problematic CAs which lasts some
finite period of time (or a period to be set in each case). Notify
the CA they are obliged to warn their subscribers of this status or
leave the Mozilla programme immediately. Publicly announce "at risk"
status and drive as PR.


One issue to consider with this option would be that reputational damage
is harder to quantify and control than a technical measure, which might
be said to increase the risk that the action would be disproportionate.


3. Split NSS trust store into two or more categories based on degree
of trustworthiness. Maybe present a Firefox pref to pick "secure" vs
"compatible"


Non-starter, I'm afraid. We are not loading this problem on to users.


Finally, I would like to mention, though I expect it to be shot down,
a much more radical way forward. RP audits. Relying Party audits.


Some issues to consider with this approach would be:

* How does the money to pay for such audits flow from the CA to the
auditor, and through whom?


CA must deposit the standard audit fee (non-negotiable, no race to the
bottom) in a standard bank escrow account releasable by the body that
chooses the auditors.



* Who chooses the auditors?


Obviously not the CA, and since there is no appropriate neutral
democratic body to do this (the UN GA would be overdoing it, ITU and
ICANN are having their own trust issues) maybe an ad hoc body
consisting of the CA/B forum plus extra representatives from relevant
groups such as the EFF, Transparency International, whatever
international organization acts as a union of Auditors.



* How do you make sure they remain independent when their funding is
(even indirectly) from the CAs?


Their fee structure and election is done by someone other than the CA,
who also hires and fires them on an annual basis, so they would be
fiscally beholden to that other body, not the CA.  For example the
fixed price for a 2017 audit could be $xx per site per CA
organisation + $y per root cert + $z per intermediary cert +
$c per million end certs.  Amount to be deposited in an independent
bank at least 2 weeks before the audit is due to begin and releasable
only by signatures from the appointing body.



* How do you deal with confidentiality issues? CAs have some things they
legitimately wish to keep confidential. And yet such an auditor would
need full access to all their infra and business processes.


This is standard for properly certified auditors to handle, as long as
they are not completely chosen by a competitor or spy agency.  This is
standard auditing practice with appropriate confidentiality obligations
often codified by law.



* Is it a problem that adding additional costs to becoming a CA
discourages new and possibly innovative companies from entering the market?



This cost (though maybe higher than the fee for a rubber stamp auditor)
would replace, not add to, the cost of a CA hired compliance auditor.

+

If a list of grandfathered WoSign (or some other big failed CA) issued
certs is too big to download to every client (in the browser
installer or in any other way), one practical solution could be this:
(Sorry, this is going to be a long recipe):

1. Copy all the grandfathered certificates in DER form to a secure
  database at Mozilla HQ, a Beijing government agency or some other
  strong location.

2. Generate a Merkle hash tree (using SHA-512 or better) of the
  certificates in this orig

Re: Sanctions short of distrust

2016-09-02 Thread Nick Lamb

Thanks for your feedback Gerv,

On Friday, 2 September 2016 11:19:49 UTC+1, Gervase Markham  wrote:
> Have you considered what was done for CNNIC? In that case, we distrusted
> all certificates issued after a certain time. We used a whitelist for
> determining this, but it would be possible to use the notBefore date in
> the certificate. A CA could dodge this by backdating, but if the CA were
> also committed to putting all its certs in to CT, then the backdating
> would be noticeable.

That's a good point, I knew of the CNNIC outcome but didn't add it to my list. 
It has the obvious GOOD factor that we know Mozilla can successfully do it.

I suspect that a whitelist will almost always prove necessary. Even the 
suspicion of backdating happening undermines the value of this sanction.

> > 2. Create "at risk" category for problematic CAs

> One issue to consider with this option would be that reputational damage
> is harder to quantify and control than a technical measure, which might
> be said to increase the risk that the action would be disproportionate.

The intention of my "leave the programme" option was to mitigate this risk. If 
the CA thinks it would be worse to have reputational damage from the "at risk" 
declaration than be distrusted, they're free to leave Mozilla's trust store 
programme entirely instead.

> > Finally, I would like to mention, though I expect it to be shot down,
> > a much more radical way forward. RP audits. Relying Party audits.
> Some issues to consider with this approach would be:
> 
> * How does the money to pay for such audits flow from the CA to the
> auditor, and through whom?

Collected by an arms length contractor on a volume basis, see e.g. how 
Advertising Standards Agency is funded in UK. This gets easier with CT because 
volume stops being speculative. The exact funding structure (e.g. logarithmic 
on certs issued? thresholds for validity months x number of certs?) would be 
chosen by the arms length contractor to meet an overall funding goal.

> * Who chooses the auditors?

Major Trust Stores like Mozilla on behalf of their relying party users. You 
could build a big clumsy bureaucracy around this but I think the big 3-4 could 
just settle it among themselves e.g. cut the list of CAs up and take some each, 
or rotate responsibility.

> * How do you make sure they remain independent when their funding is
> (even indirectly) from the CAs?

Pooling effect of funding this way dilutes corrupting influence of money. 
Reporting to trust stores rather than to CA reminds auditors who they're 
representing. Keep in mind that today the funding is indirectly from 
subscribers, but auditors don't usually meet one, so why think about it?

> * How do you deal with confidentiality issues? CAs have some things they
> legitimately wish to keep confidential. And yet such an auditor would
> need full access to all their infra and business processes.

It may be necessary to carefully draft a standard agreement for this purpose.  
I've never seen an auditor be confused about whether it's appropriate to 
disclose things like passwords, exact locations of secure facilities, 
identities of key employees etc. This is not their first rodeo. In my 
experience too often the "legitimate wishes" of an audit subject involve not 
disclosing the very sort of things the audit is in fact intended to unearth, 
such as unmitigated risks and poorly conceived processes. So "too bad" has to 
be the answer in those cases.

> * Is it a problem that adding additional costs to becoming a CA
> discourages new and possibly innovative companies from entering the market?

Ultimately the goal would be that RP audits would be either cost neutral 
(assuming the eventual elimination of the current less than ideal audit system) 
or only slightly more expensive (reflecting costs from choosing higher quality 
auditors or from more thorough conduct of the audits)

If we want to make it cheaper, my understanding is that the _utterly_ useless 
insurance requirement is still there. If one RP audit finds one bug before it 
bites us in the real world that was already a better investment than all the 
insurance ever purchased by CAs in the history of the web PKI as far as I know.
___
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

2016-09-02 Thread 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

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

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

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

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

2016-09-02 Thread 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: Sanctions short of distrust

2016-09-02 Thread John Nagle

September 2016 11:19:49 UTC+1, Gervase Markham wrote:

Have you considered what was done for CNNIC? In that case, we
distrusted all certificates issued after a certain time. We used
a whitelist for determining this, but it would be possible to use
the notBefore date in the certificate. A CA could dodge this by
backdating, but if the CA were also committed to putting all its
certs in to CT, then the backdating would be noticeable.

Jakob Bohm (?) wrote:

That's a good point, I knew of the CNNIC outcome but didn't add it to
my list. It has the obvious GOOD factor that we know Mozilla can
successfully do it.

I suspect that a whitelist will almost always prove necessary. Even
the suspicion of backdating happening undermines the value of this
sanction.

This is approaching a workable technical solution.

The certificate transparency system is already well defined.

Firefox could have flags associated with root certificates, perhaps
as follows:

1. For certs under this root cert, always check
certificate revocation list. (presumably via OCSP).
Fail if revoked.

2. For certs under this root cert, always check
CA's certificate transparency server. Fail
if not found.

3. For certs under this root cert, always check
Mozilla-run whitelist in addition to other
checks. This would probably be in the form
of a CT server which tracked the CA's CT
server, but from which certificates could
be deleted if necessary.

This provides the requested mechanism short of distrust. Only
#3 is new; Google Chrome already does #1 and #2. #3 would
be turned on in case of problems at a CA.

Google's statements in 2015 indicated that it was their intention
to do something quite similar in Chrome:

https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxjZXJ0aWZpY2F0ZXRyYW5zcGFyZW5jeXxneDoyZGU5Yjg1MmVjNzc5NjQz

Much of that has already been done.

CT support in Firefox was proposed in 2013 and a patch was generated,
but seems to be languishing. Last update was in January 2016.
The problem appears to be policy, not technology. See:

https://bugzilla.mozilla.org/show_bug.cgi?id=944175

John Nagle
SiteTruth

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

Re: Sanctions short of distrust

2016-09-02 Thread Patrick Figel

On 02/09/16 21:14, John Nagle wrote:
> 2. For certs under this root cert, always check
>CA's certificate transparency server.   Fail
>   if not found.

To my knowledge, CT does not have any kind of online check mechanism.
SCTs can be embedded in the certificate (at the time of issuance),
delivered as part of the TLS handshake or via OCSP stapling.

In practice that means certificates will either have to be re-issued, or
website operators need to modify their server software and configuration
(not many sites currently deliver SCTs). In terms of real-world impact,
you probably could just as well pull the root completely.

I believe there are two possible solutions if CT enforcement is what the
community decides on:

 1. Enforce CT only after a certain date, after which WoSign will need
to embed qualified SCTs. This check can be bypassed if the CA
backdates certificates (which is problematic, given the history of
backdating certificates in this particular case.)

 2. Verify that the certificates either have a qualified SCT *or* are
explicitly white-listed as certificates that have been issued prior
to WoSign implementing CT. There are a number of possible
implementations for this (Google's Safe Browsing, etc.), but they'd
all require a non-trivial amount of development work.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

PEM->JSON tool and cert tests down

2016-09-02 Thread Kathleen Wilson


All,

We had to take down https://cert-checker.allizom.org/ due to a security 
issue.


This site hosted cert tests, EV tests, and the PEM->JSON tool used by 
the CA Community in Salesforce for importing intermediate cert data.


We are actively looking for a solution, but do not currently have a date 
when it will be available again. We may need to start over in terms of 
deploying these tools, and move them to a different (non-mozilla) 
domain. We will provide updates as we have information to share.


I apologize for the inconvenience this causes.

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

Re: Sanctions short of distrust

2016-09-02 Thread John Nagle


On 09/02/2016 01:04 PM, Patrick Figel wrote:

On 02/09/16 21:14, John Nagle wrote:

2. For certs under this root cert, always check CA's certificate
transparency server.   Fail if not found.


To my knowledge, CT does not have any kind of online check
mechanism. SCTs can be embedded in the certificate (at the time of
issuance), delivered as part of the TLS handshake or via OCSP
stapling.


You're supposed to be able to check if a cert is known by
querying an OCSP responder.   OCSP stapling is just a faster way
to do that.  Commercial OCSP responders are available.  See

 https://www.ejbca.org/docs/architecture-ocsp.html

 https://technet.microsoft.com/en-us/library/cc770413(v=ws.10).aspx

and there's an open source responder:


https://www.nexusgroup.com/globalassets/media/documents/productsheet_eng/nexus_ps_ocsp-responder_en.pdf

What I'm suggesting is that mandatory external OCSP checking
against a Mozilla-operated server be enabled on a per-root-cert basis.
Mozilla's server would get its data from the CA's CT information, and,
after checking for problems, and removing any questionable certs,
would make it available on an OCSP server.  Firefox would check
that server if the root cert was flagged for it.  For CAs with problems,
this would give Mozilla fine-grained sanction control.

John Nagle
___
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

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: Sanctions short of distrust

On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote:
> On 09/02/2016 01:04 PM, Patrick Figel wrote:
> >On 02/09/16 21:14, John Nagle wrote:
> >>2. For certs under this root cert, always check CA's certificate
> >>transparency server.   Fail if not found.
> >
> >To my knowledge, CT does not have any kind of online check
> >mechanism. SCTs can be embedded in the certificate (at the time of
> >issuance), delivered as part of the TLS handshake or via OCSP
> >stapling.
> 
> You're supposed to be able to check if a cert is known by
> querying an OCSP responder.   OCSP stapling is just a faster way
> to do that.

OCSP stapling is also a *privacy preserving* way to do that (also more
reliable, in addition to faster).  I'm not sure that essentially snooping
(or at least having the ability to snoop) on the browsing habits of users
who happen to connect to a website that uses the certificate of a
poorly-trusted CA better serves the user community than just pulling the
root.  I guess at least we're not training users to ignore security warnings
this way, and since if Mozilla is running the OCSP responder (or similar)
you're already trusting Mozilla not to snoop on your browsing...

- Matt

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

Re: Sanctions short of distrust

On Fri, Sep 02, 2016 at 11:19:11AM +0100, Gervase Markham wrote:
> On 31/08/16 20:43, Nick Lamb wrote:
> > This suggests the need for some options short of distrust which can
> > be deployed instead, but Mozilla does not seem to have any. If in
> > fact it already does, this would be a great place to say what they
> > are and discuss why they haven't been able to be used in recent
> > cases.
> 
> Have you considered what was done for CNNIC? In that case, we distrusted
> all certificates issued after a certain time. We used a whitelist for
> determining this, but it would be possible to use the notBefore date in
> the certificate. A CA could dodge this by backdating, but if the CA were
> also committed to putting all its certs in to CT, then the backdating
> would be noticeable.

Is the idea here that the incentive for the CA to "behave" is potential
future re-inclusion?  If we catch 'em doing the dodgy (which, with Google's
super-spider powers and submitting everything to CT, is at least *fairly*
likely these days) then any hope of their ever being re-included is
completely gone?  Pulling the root at that future juncture of misissuance
might also be more palatable, since presumably the number of valid certs
being used in the wild should be reduced.

> > 1. Implement "Require SCTs" for problematic CAs. Notify the CA they
> > are obliged to CT log all certificates, inform subscribers etc. or
> > their subscriber's certificates will suddenly be invalid in Firefox
> > from some future date.
> 
> This is not currently possible in Firefox, as Firefox does not have the
> ability to check SCTs. We hope to have that ability soon.

Even if Firefox was checking SCTs, as another poster said, if practically
every site needs to reconfigure themselves to deal with this, we may as well
just pull the root.  Heck, getting a cert from somewhere else is almost
certainly *less* hassle than setting up SCT-embedded OCSP stapling or SCTs
in the TLS handshake.  As far embedding SCTs in the certs, I thought the
plan was to have the problematic CA *not* issue more certs...

> > 2. Create "at risk" category for problematic CAs which lasts some
> > finite period of time (or a period to be set in each case). Notify
> > the CA they are obliged to warn their subscribers of this status or
> > leave the Mozilla programme immediately. Publicly announce "at risk"
> > status and drive as PR.
> 
> One issue to consider with this option would be that reputational damage
> is harder to quantify and control than a technical measure, which might
> be said to increase the risk that the action would be disproportionate.

Not to mention, where's the incentive for the CA to do this?  If pulling the
root was a valid sanction, it'd be done.  So, if the CA says "we're not
doing that" (or, as is more likely, "we'll do it... later", or "yes, we've
done it" but we have no way to verify it) what does Mozilla do next?

- Matt

-- 
I don't do veggies if I can help it.-- stevo
If you could see your colon, you'd be horrified.-- Iain Broadfoot
If he could see his colon, he'd be management.  -- David Scheidt

___
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

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

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

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: Sanctions short of distrust

2016-09-02 Thread Patrick Figel

On 03/09/16 01:15, Matt Palmer wrote:
> On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote:
>> On 09/02/2016 01:04 PM, Patrick Figel wrote:
>>> On 02/09/16 21:14, John Nagle wrote:
 2. For certs under this root cert, always check CA's
 certificate transparency server.   Fail if not found.
>>> 
>>> To my knowledge, CT does not have any kind of online check 
>>> mechanism. SCTs can be embedded in the certificate (at the time
>>> of issuance), delivered as part of the TLS handshake or via OCSP 
>>> stapling.
>> 
>> You're supposed to be able to check if a cert is known by querying
>> an OCSP responder.   OCSP stapling is just a faster way to do
>> that.
> 
> OCSP stapling is also a *privacy preserving* way to do that (also
> more reliable, in addition to faster).  I'm not sure that essentially
> snooping (or at least having the ability to snoop) on the browsing
> habits of users who happen to connect to a website that uses the
> certificate of a poorly-trusted CA better serves the user community
> than just pulling the root.  I guess at least we're not training
> users to ignore security warnings this way, and since if Mozilla is
> running the OCSP responder (or similar) you're already trusting
> Mozilla not to snoop on your browsing...

In addition to these concerns, (and assuming Mozilla would even be
willing to go down that route), I'm not sure how reliable a
Mozilla-operated OCSP responder would be given that the majority of
users who visit sites that use WoSign are probably behind the GFW.

If the answer is somewhere between "unreliable" and "extremely slow",
you might just as well pull the root (just for the sake of this
argument), which would mostly inconvenience site operators (as opposed
to every single Firefox user).
___
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

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: Sanctions short of distrust

On Sat, Sep 03, 2016 at 01:45:48AM +0200, Patrick Figel wrote:
> On 03/09/16 01:15, Matt Palmer wrote:
> > On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote:
> >> On 09/02/2016 01:04 PM, Patrick Figel wrote:
> >>> On 02/09/16 21:14, John Nagle wrote:
>  2. For certs under this root cert, always check CA's
>  certificate transparency server.   Fail if not found.
> >>> 
> >>> To my knowledge, CT does not have any kind of online check 
> >>> mechanism. SCTs can be embedded in the certificate (at the time
> >>> of issuance), delivered as part of the TLS handshake or via OCSP 
> >>> stapling.
> >> 
> >> You're supposed to be able to check if a cert is known by querying
> >> an OCSP responder.   OCSP stapling is just a faster way to do
> >> that.
> > 
> > OCSP stapling is also a *privacy preserving* way to do that (also
> > more reliable, in addition to faster).  I'm not sure that essentially
> > snooping (or at least having the ability to snoop) on the browsing
> > habits of users who happen to connect to a website that uses the
> > certificate of a poorly-trusted CA better serves the user community
> > than just pulling the root.  I guess at least we're not training
> > users to ignore security warnings this way, and since if Mozilla is
> > running the OCSP responder (or similar) you're already trusting
> > Mozilla not to snoop on your browsing...
> 
> In addition to these concerns, (and assuming Mozilla would even be
> willing to go down that route), I'm not sure how reliable a
> Mozilla-operated OCSP responder would be given that the majority of
> users who visit sites that use WoSign are probably behind the GFW.
> 
> If the answer is somewhere between "unreliable" and "extremely slow",
> you might just as well pull the root (just for the sake of this
> argument), which would mostly inconvenience site operators (as opposed
> to every single Firefox user).

Ryan's earlier treatise against just pulling the root centred around
training users to ignore security warnings -- which is, let's face it,
exactly what would happen.  At least with an OCSP responder, users might get
a degraded experience, but at least not *every* Firefox user who visits
ones of 100k+ sites gets a lesson in where the "ignore cert error" button
is.

I suppose for a blacklisted root, Firefox could make it an unfixable error,
but that just trains people to go find a different browser -- so unless
there's a concerted agreement between browsers (an ugly thing from a legal
perspective, at least) to do this together, it's unlikely to be palatable.

- 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

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

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

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