Re: [FORGED] Re: Incidents involving the CA WoSign

[Myers, Kenneth (10421)]

There could be multiple reasons for xcerts from internal policies to controlled 
trust stores. It depends on the root and the company. Part of the reason the 
FPKI has xcerts is for both those reasons. Companies may only want to use their 
root. They may not want to rely on the trust bundle approach or have internal 
policies that there must be mutual trust. I think this group has seen some 
examples of questionable audits.

Ken

Message: 4
Date: Tue, 6 Sep 2016 14:10:19 +00
From: Peter Gutmann <pgut...@cs.auckland.ac.nz>
To: Peter Bowen <pzbo...@gmail.com>, Gervase Markham
<g...@mozilla.org>
Cc: Richard Wang <rich...@wosign.com>,
"mozilla-dev-security-pol...@lists.mozilla.org"
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: [FORGED] Re: Incidents involving the CA WoSign
Message-ID: <1473170991071.38...@cs.auckland.ac.nz>
Content-Type: text/plain; charset="iso-8859-1"

Peter Bowen <pzbo...@gmail.com> writes:

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

This is incredible, it's like a hydra.  Do the BRs say anything about this
type of cross-certification, or is it just "find as many other CAs as you can
to cross-certify you so you can't be killed".

Why would a public CA even need cross-certification from other CAs?

Peter.


Ken

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+kenneth.myers=protiviti@lists.mozilla.org]
 On Behalf Of dev-security-policy-requ...@lists.mozilla.org
Sent: Tuesday, September 6, 2016 10:19
To: dev-security-policy@lists.mozilla.org
Subject: dev-security-policy Digest, Vol 93, Issue 34

Send dev-security-policy mailing list submissions to
dev-security-policy@lists.mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.mozilla.org_listinfo_dev-2Dsecurity-2Dpolicy=DQICAg=19TEyCb-E0do3cLmFgm9ItTXlbGQ5gmhRAlAtE256go=v6QfMBgWaMWhsB_PpBwwzxPtUwSffCWXSAR0gp0RFbY=gx-RPkgIBbnv1o7pHc6J2JDA0hiijyCDt6lIsqVJaTk=3DxgIVrE6qM1HU21hDF7kWz-URTpSuAa2CzJ9fhbisw=
or, via email, send a message with subject or body 'help' to
dev-security-policy-requ...@lists.mozilla.org

You can reach the person managing the list at
dev-security-policy-ow...@lists.mozilla.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of dev-security-policy digest..."


Today's Topics:

   1. Re: Sanctions short of distrust (Jakob Bohm)
   2. Re: Sanctions short of distrust (Kurt Roeckx)
   3. Re: Incidents involving the CA WoSign (Peter Gutmann)
   4. Re: [FORGED] Re: Incidents involving the CA WoSign (Peter Gutmann)
   5. Re: Sanctions short of distrust (Jakob Bohm)
   6. Re: Incidents involving the CA WoSign (Jakob Bohm)


--

Message: 1
Date: Tue, 6 Sep 2016 14:16:32 +0200
From: Jakob Bohm <jb-mozi...@wisemo.com>
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Sanctions short of distrust
Message-ID: <rvydna3-rae8llpknz2dnuu7-lxnn...@mozilla.org>
Content-Type: text/plain; charset=utf-8; format=flowed

On 06/09/2016 10:25, Kurt Roeckx wrote:
> On 2016-09-06 10:13, Nick Lamb wrote:
>> Quality of implementation for OCSP stapling seems to remain poor in
>> at least apache and nginx, two of the most popular servers. Apache's
>> in particular gives me that OpenSSL "We read this standards document
>> and implemented everything in it as a series of config options
>> without any understanding" feeling, rather than Apache's maintainers
>> taking it upon themselves to figure out what will actually work best
>> for most servers and implementing that.
>
> If you think there is something we can do in OpenSSL to improve this,
> please let us know.
>
>

Here are a list of software where I have personally observed bad OCSP stapling 
support:

OpenSSL 1.0.x itself: There are hooks to provide stapled leaf OCSP responses in 
sessions, but no meaningful sample code to do this right (e.g. caching, error 
handling etc.)  I am working on my own add-on code for this, but it is not 
complete and not deployed.
   There is no builtin support for multistapling and no clear documentation on 
how to add arbitrary TLS extensions (such as this) to an OpenSSL application.

OpenSSL 1.1.x itself: This is a heavily rewritten library and very new at this 
time, basic reliability procedures suggest waiting a few patch levels before 
deployment.

Stunnel stand alone SSL/TLS filter (used with e.g. Varnish reverse
proxies): OCSP stapling is on their TODO-list, but not yet included.

Pound light-weight reverse proxy with SSL/TLS front end: 

Re: [FORGED] Re: Incidents involving the CA WoSign

[Jakob Bohm]

On 06/09/2016 16:10, Peter Gutmann wrote:

Peter Bowen  writes:


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


This is incredible, it's like a hydra.  Do the BRs say anything about this
type of cross-certification, or is it just "find as many other CAs as you can
to cross-certify you so you can't be killed".



The BRs say that if the cross-certified CA is deemed no longer
compliant, the cross-signing CAs must retract their cross-signature or
be deemed non-compliant themselves.  This was already explained
elsewhere in this discussion.


Why would a public CA even need cross-certification from other CAs?



Because the delay from starting up a new trustworthy CA until all
deployed client software has been upgraded to trust that new CA is
unbearably long (bordering on infinite as the required support
percentage approaches 100.0%).  Hence it is common for new
CAs (other than the now historic RSADSI CA) to acquire cross-signatures
from established (or even defunct) CAs.

This is exacerbated by the fact the at least one Browser vendor
(Microsoft) no longer distributes the full list of trusted CAs with
their clients, but instead checks against an online copy of their root
stores as needed, giving people very little control over what they
trust other than a few historic CAs.

In relation to your well-published PKI criticism, it is noted that some
of the many new CAs found in root stores are governments who (unlike
commercial CAs) are the actual authority on the identity of their
citizens.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Rob Stradling]

On 06/09/16 15:10, Peter Gutmann wrote:

> Why would a public CA even need cross-certification from other CAs?

To inherit trust on legacy platforms that don't have an automatic root
update mechanism.

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

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

Re: Incidents involving the CA WoSign

[Jakob Bohm]

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

Matt Palmer  writes:


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


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

Peter.



HØHØHØ *

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

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Peter Bowen  writes:

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

This is incredible, it's like a hydra.  Do the BRs say anything about this
type of cross-certification, or is it just "find as many other CAs as you can
to cross-certify you so you can't be killed".

Why would a public CA even need cross-certification from other CAs?

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

Re: Incidents involving the CA WoSign

[Peter Gutmann]

Matt Palmer  writes:

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

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

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

RE: Incidents involving the CA WoSign

[Richard Wang]

Thanks for your comment.

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

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

Best Regards,

Richard

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

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

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

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

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

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


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


Kurt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-05 22:37, Percy wrote:

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

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


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


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


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

- The manual review just approved it.

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



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



Kurt

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 06/09/16 07:20, Henri Sivonen wrote:
> In the table on page 13, line 6 looks different from the others.
> Should that line be in the table on page 14 instead?

Also line 2?

Gerv

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

Re: Incidents involving the CA WoSign

[Henri Sivonen]

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

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

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

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

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

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


Best Regards,

Richard

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

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[Percy]

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

Peter,
I totally agree with your answers. However, relating to question 2, if WoSign 
is restricted to a set of white-listed certs or revoked, I think the 
restriction should apply regardless whether the cert is crossed signed or not. 
This will render question 2 moot, as other CAs are effectively only 
cross-signing the the set of white-listed certs. No certs will be trusted 
anyway, if WoSign is outright revoked either. 
I guess the only situation is that some future (misused) certs will be trusted 
by products that hasn't implemented the whitelist approach, e.g by iOS. Then I 
agree the other root certs should be treated as a subordinate CA.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Peter Bowen]

On Wed, Aug 24, 2016 at 6:08 AM, Gervase Markham  wrote:
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these
> incidents. This email sets out our understanding of the situation.
>
> Before we begin, we note that Section 1 of the Mozilla CA Certificate
> Enforcement Policy[0] says: "When a serious security concern is noticed,
> such as a major root compromise, it should be treated as a
> security-sensitive bug, and the Mozilla Policy for Handling Security
> Bugs should be followed." It is clear to us, and appears to be clear to
> other CAs based on their actions, that misissuances where domain control
> checks have failed fall into the category of "serious security concern".

Gerv and team,

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

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

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

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

I have two questions:

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

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

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

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

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

Re: Incidents involving the CA WoSign

[Percy]

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

Richard, please also include the incident report for alicdn.com. The whitehat 
(Did you confirm with him, Gerg? ) mentioned "Wosign's Issue mechanism is high 
risking for large enterprise." It might not be an isolated incident, but rather 
a procedural weakness.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Percy]

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

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

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

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

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

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

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


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

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

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

RE: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Eddy Nigg  writes:
>On 09/04/2016 09:20 AM, Peter Gutmann wrote:
>> This is great stuff, it's like watching a rerun of Diginotar
>
>.says the audience on the backbenches gleefully

Well, it doesn't exactly paint the best picture of a competently-run CA, same
as Diginotar, and the progression does seem remarkably similar ("nothing to
see here, move along, move along", "OK, there was a small thing, we've fixed
it now", "OK, there was a little more than that but now it's definitely
fixed", "oh, we hadn't noticed that one, it's really, really fixed for sure
now", etc).

Hey look, I don't have anything personal against WoStartSignCom, my views on
the value of the whole browser PKI racket as a means of securing web users are
pretty well known, it's just such a wonderful example of the sort of stuff
that people are relying on for their "security", and how utterly toothless the
browser vendors are in terms of dealing with issues like this: it'll be
debated endlessly on here without anything happening, and Chrome, IE/whatever,
and Safari won't even address it, assuming they're even aware of it.  Just
business as usual.

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

[Gervase Markham]

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

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

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

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

Gerv

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

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

Re: [FORGED] Re: Incidents involving the CA WoSign

[Eddy Nigg]

On 09/04/2016 09:20 AM, Peter Gutmann wrote:

Peter Bowen  writes:


It was brought to my attention that there is another incident.

This is great stuff, it's like watching a rerun of Diginotar


.says the audience on the backbenches gleefully

but no, what are you talking about?? Even though some nasty and 
undesired errors happened here, its in no comparison to what happened at 
Diginotar which basically lost control over the CA.



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

[Kurt Roeckx]

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

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

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

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

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

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[Andrew Ayer]

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

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

The two SM2 certificates can be downloaded here:

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

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

Re: Incidents involving the CA WoSign

[Peter Bowen]

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

Richard,

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

Thanks,
Peter

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

Hi Richard,

About incident 0 in the report, it says:

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

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


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

Is that an accurate description of the problem?

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


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

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


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

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

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

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

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


Kurt

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

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi all,

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

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Dear m.d.s.policy,

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

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

Incident 0
--

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

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

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

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

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

Incident 1
--

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

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

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

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

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

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

Incident 2
--

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

Re: Incidents involving the CA WoSign

[Gijs Kruitbosch]

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



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


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


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


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


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


Why have you not done so?

~ Gijs


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

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

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


Best Regards,

Richard

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

Richard,

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

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

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

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang <rich...@wosign.com> wrote:

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


Regards,

Richard


On 2 Sep 2016, at 23:20, Peter Bowen <pzbo...@gmail.com> wrote:


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


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


Richard,

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

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

Thanks,
Peter


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

Re: Incidents involving the CA WoSign

[Eddy Nigg]

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

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


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


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


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


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

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

RE: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Peter Bowen  writes:

>It was brought to my attention that there is another incident. 

This is great stuff, it's like watching a rerun of Diginotar.  Definitely the
best web soap in the last few weeks...

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

Re: Incidents involving the CA WoSign

[Richard Wang]

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

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

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

Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Richard Wang]

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

Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Peter Bowen]

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

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

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

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

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

Re: Incidents involving the CA WoSign

[Matt Palmer]

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

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

- Matt

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

RE: Incidents involving the CA WoSign

[Richard Wang]

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

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


Best Regards,

Richard

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

Richard,

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

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

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

Thanks,
Peter

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

Re: Incidents involving the CA WoSign

[Peter Bowen]

Richard,

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

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

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

Thanks,
Peter

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

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

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

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

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

This is where understanding options is important for the discussion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Percy]

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

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

Percy Alpha(PGP
)


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

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

Re: Incidents involving the CA WoSign

[Percy]

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

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

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


Percy Alpha(PGP
)


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

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

Re: Incidents involving the CA WoSign

[Andy Ligg]

You are completely wrong!

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


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


Regards,

Andy

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

I did an analysis of the new StartCom website and determined that it was designed and 
implemented solely in China.  
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html  I'm further 
concerned with the security of "StartResell - Setup your own website, start to sell 
your brand SSL certificate to your customers". Details here
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

That offset being 37 seconds.

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


Kurt

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

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

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

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

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

Gerv


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

Re: Incidents involving the CA WoSign

[Percy]

I did an analysis of the new StartCom website and determined that it was 
designed and implemented solely in China.  
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html  I'm 
further concerned with the security of "StartResell - Setup your own website, 
start to sell your brand SSL certificate to your customers". Details here
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 02/09/16 18:00, Andrew Ayer wrote:
> I don't think relying on the notBefore date is a viable option.
> WoSign seems to have such a poor handle on their operations that I
> think it would be inevitable that someone would find a certificate in
> the wild with a notBefore date in the past that had not been
> disclosed.  What action would Mozilla take if that happened?

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

Gerv


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

Re: Incidents involving the CA WoSign

[Percy]

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

You also claimed (https://pbs.twimg.com/media/CrZ4GV7WgAESKyn.jpg:large) way 
back in 2014 that "If you deploy foreign certificates, you still will not have 
any security in online commerce".  Is it what you truly believe in or were you 
actively trying to mislead potential customers?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Percy]

Richard, 
You claimed on weibo (https://pbs.twimg.com/media/CrZ1Oc6WIAABtrg.jpg:large 
)that "WoSign has been oppressed by large American companies over the years but 
has been growing steadily over the past 10 years and is now the 8th largest CA 
in the world".  Is EFF one of your so called oppressors?  Do you even know what 
EFF is?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Percy]

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

[Peter Bowen]

On Fri, Sep 2, 2016 at 5:04 PM, Richard Wang  wrote:
> From the screenshot, we know why Percy hate WoSign so deeply, we know he 
> represent which CA, everything is clear now.

Richard,

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

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

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

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

Re: Incidents involving the CA WoSign

[Richard Wang]

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

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

Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Matt Palmer]

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

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

- Matt

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

Re: Incidents involving the CA WoSign

[Matt Palmer]

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

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

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

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

- Matt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[Matt Palmer]

On Fri, Sep 02, 2016 at 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

[Matt Palmer]

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

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

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

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

- Matt

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

Re: Incidents involving the CA WoSign

[Erwann Abalea]

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

That's not WoSign's fault. It's really hard to communicate with Apple and their 
Root Program, it's a concern for other CAs as well.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Percy]

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

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

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

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

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

 (contact info stuff)

Best regards and thanks,

WoSign CA Limited. 

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

Re: Incidents involving the CA WoSign

[Percy]

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

However,  all WoSign leaf certs are trusted on Apple devices because WoSign 
intermediate authority is signed by StartCom. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

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



Kurt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

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

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


Kurt

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

Re: Incidents involving the CA WoSign

[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

[Richard Wang]

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


Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Peter Bowen]

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

Richard,

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

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

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

Re: Incidents involving the CA WoSign

[Richard Wang]

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

Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Peter Bowen]

(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

[Peter Bowen]

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

Richard,

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

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

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

RE: Incidents involving the CA WoSign

[Richard Wang]

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Friday, September 2, 2016 6:07 PM
To: Richard Wang <rich...@wosign.com>; 
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

[Gervase Markham]

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

[Gervase Markham]

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

[Gervase Markham]

Hi Richard,

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

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

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

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

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

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

> Thanks a million.

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

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

RE: Incidents involving the CA WoSign

[Richard Wang]

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

[Matt Palmer]

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

[Kurt Roeckx]

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

[Percy]

On Thursday, September 1, 2016 at 11:36:13 PM UTC-7, Richard Wang wrote:
> Please remember this sentence:
> Every re-distribution the wrong information will heavy his penalty (including 
> site cache or mirror site).  
> 
> You are harming him! 

You stated that he was a former employee of StartCom in 2015. After he left the 
company, what he learnt from public sources in 2016 is not bound by NDA.  I do 
not appreciate you holding him hostage to suppress public and crucial 
information on understanding the trust of CA. Since WoSign is trying so hard to 
suppress such critical information, it's especially important for us to 
understand the consequences of such info. The entire article is reproduced 
below.


Being a Certificate Authority is all about trust.
Start Commercial LTD "is" an Israeli Certificate Authority, Their certificates 
are trusted by billion of devices (computers, mobile phones, routers, etc) and 
they claim to be "the 6th biggest CA in the world". StartCom launched it's 
activities as we know it today around 2006 with the brandname StartSSL.
Their site didn't had much UI changes during those years. Until 2016...
February 16th, 2016, Pierre Kim in his security blog wrote about why he stopped 
using StartSSL. The article was about how some of StartSSL's infrastructure is 
hosted in China/by Chinese companies. But he showed only small part of the 
whole picture, not going into who owns StartCom and the brandname StartSSL.
Reviewing StartCom registry in the Israeli company directory reveal that on 
November 1st, 2015 all the shares of the private held company were transfered 
to a UK based company named "StartCom CA Limited". This company, "StartCom CA" 
is owned by Gaohua Wang, who is of Chinese nationality.
But no news about it. 2016 is a major year for StartCom, new UI, new tools and 
new features, and yet, no news regarding the new ownership. The only news 
related to the matter was a minor post about expending their activities in 
China.

In the previous part we saw that the ownership of the company has switched, 
from Israeli hands to Chinese hands (via a UK based company to operate as a 
front organization). Pierre Kim in his blog post showed that some of StartSSL 
infrastructure is hosted in China/by Chinese companies. In this part I will 
present that currently (June 2016) StartSSL is operating from China (their 
employees are located in China).
During the first half year of 2016 I've contacted StartSSL several times. The 
first time was when I notified them about their SPF TXT records being incorrect 
[1], the reply was originated from 113.104.213.84 (China Telecom, CHINANET 
Guangdong province network) with the "Content-Language" equals to "zh-cn" and 
the localtime of the email was UTC+0800. The email is signed with 
"certmas...@startssl.com" private key.
The second time I've contacted StartSSL was in regard their OCSP replies for 
expired certificates [2], again the reply was originated in China 
183.37.124.147 (China Telecom, CHINANET Guangdong province network) with 
China's localtime (UTC+0800).
The third and last time I've contacted StartSSL was regarding their expired 
certificates on some of their hosts [3], this time the reply seem to be 
generated via some kind of a ticket system, but still from China. The ticket 
system itself (MX server at least) seem to be in China, 124.251.21.41 
(21ViaNet(China),Inc), and the person who replied to my email was also from 
China, 14.153.60.139 (China Telecom, CHINANET Guangdong province network) with 
"Accept-Language:" set to "zh-cn".
And what about StartSSL automated emails, old ones (during January) seem to 
originate in China, they came from 106.39.1.130 (China Telecom, CHINANET-BJ) 
[4]. But later ones, come from 104.192.108.9-10 (China Telecom (Americas) 
Corrporation (CTUC)) [5]. According the the whois, this is a Chinese company 
with an IP infrastructure in the US, but the localtime is still set to China's 
localtime.

In part 1 I showed that all shares from Start Commercial LTD (company based in 
Israel) were transferred to a front organization in the UK, named "StartCom CA 
Limited", which their sole director is Gaohua Wang. In part 2 I showed that 
StartSSL is actually operating from China (last verified, June 2016). In this 
part I will disclose who actually owns StartCom and more specifically the 
"StartSSL" brandname.
The key figure is Gaohua Wang (aka Richard Wang). It may not be so easy to 
connect him to the company in matter (searching for "Gaohua Wang certificate 
authority" will do the trick), but Gaohua Wang is also a director of another CA 
company based in China, named WoSign [1].
StartCom doesn't share this information with their customers, past, present and 
probably near future. I even tried to ask them directly via their Live Chat, 
but they haven't given me a straight answer ("not really", "close relationship" 
and "share infrastructure") [2] [3]. It seem StartCom is trying really hard not 
to 

Re: Incidents involving the CA WoSign

[Matt Palmer]

On Fri, Sep 02, 2016 at 05:59:19AM +, 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.

I don't see anything particularly confidential, and waving around legal
threats really does seem like there's something to hide.  Why not address
the concerns raised by that site, rather than shutting it down, if the
accusations are entirely baseless?

> 2. WoSign invested in 5 companies worldwide including in North America,
> Europe and Asia (China), but my company is a private company that no any
> liability to expose everything that we don't like to expose.  And Mozilla
> also don't have the policy that every CA must expose its shareholder and
> director.

Mozilla also doesn't have every CA under scrutiny at the moment for a series
of fairly egregious breaches of the public trust, either.

> 3. Please don't bind WoSign incident problem with StartCom, it is two
> independent company that one registered in China and one located in
> Israel.

Was the distinction between "registered" and "located" deliberate there?

- Matt

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

RE: Incidents involving the CA WoSign

[Richard Wang]

Please remember this sentence:
Every re-distribution the wrong information will heavy his penalty (including 
site cache or mirror site).  

You are harming him! 


Best Regards,

Richard

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



On Thursday, September 1, 2016 at 11:01:08 PM UTC-7, Richard Wang wrote:
> OK I try to say some that I wish I don't violate my company confidential 
> policy.
> 
> 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.
> 

NDA only applies for information that's privileged. The content here 
https://archive.is/8bSp6 can be obtained all from public sources, hence 
exempted from NDA. 

In case WoSign tries to send take down request to Achieve.is, I mirrored the 
content on pastebin too http://pastebin.com/hiKxmGMH Good luck taking that 
down. 


> 2. WoSign invested in 5 companies worldwide including in North America, 
> Europe and Asia (China), but my company is a private company that no any 
> liability to expose everything that we don't like to expose. And Mozilla also 
> don't have the policy that every CA must expose its shareholder and director.
> 
Sure, your company is a private company. But the public doesn't have an 
obligation to trust you either. 


> 3. Please don't bind WoSign incident problem with StartCom, it is two 
> independent company that one registered in China and one located in Israel. 
> StartCom and WoSign have maintained a business relationship for many years 
> since 2011 when WoSign startup CA business. And WoSign root is cross signed 
> by StartCom root due to the problem that root inclusion took long time.
> 

Two independent companies that share the same infrastructure, director and user 
trust according to https://archive.is/8bSp6 , doesn't look very independent to 
me. 

> 
> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Peter Gutmann
> Sent: Friday, September 2, 2016 11:59 AM
> To: Vincent Lynch <vtly...@gmail.com>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: RE: Incidents involving the CA WoSign
> 
> Vincent Lynch <vtly...@gmail.com> 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.
> 
> Peter.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

RE: Incidents involving the CA WoSign

[Richard Wang]

OK I try to say some that I wish I don't violate my company confidential policy.

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.

2. WoSign invested in 5 companies worldwide including in North America, Europe 
and Asia (China), but my company is a private company that no any liability to 
expose everything that we don't like to expose. And Mozilla also don't have the 
policy that every CA must expose its shareholder and director.

3. Please don't bind WoSign incident problem with StartCom, it is two 
independent company that one registered in China and one located in Israel. 
StartCom and WoSign have maintained a business relationship for many years 
since 2011 when WoSign startup CA business. And WoSign root is cross signed by 
StartCom root due to the problem that root inclusion took long time.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Gutmann
Sent: Friday, September 2, 2016 11:59 AM
To: Vincent Lynch <vtly...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Incidents involving the CA WoSign

Vincent Lynch <vtly...@gmail.com> 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.

Peter.
___
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 Wang]

The posting to log server still not finished.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Thursday, September 1, 2016 11:11 PM
To: Richard Wang <rich...@wosign.com>
Cc: Ryan Sleevi <r...@sleevi.com>; 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 <rich...@wosign.com> 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

[Percy]

They have confirmed that it's a fake cert. Alibaba knew this prior to my
contact and said they already contacted WoSign.

Percy Alpha(PGP
)


On Wed, Aug 31, 2016 at 3:15 AM, Gervase Markham  wrote:

> On 29/08/16 22:53, Percy wrote:
> > 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
>
> That might also help; thank you. Please ask them to contact me directly
> to confirm this cert was not requested by them.
>
> 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

[Andrew Ayer]

On Thu, 1 Sep 2016 09:00:38 -0700
"Ryan Sleevi"  wrote:

> Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1
> certificates ( https://cert.webtrust.org/SealFile?seal=2019=pdf )

This was a violation of a "SHOULD NOT" (not a "MUST NOT") issue SHA-1
certificates that expire after 2016.  Since issuing SHA-1 certificates
was not forbidden in 2015 and the notAfter date is immaterial to the
risk of SHA-1 collisions[1], it would be unfair and counterproductive
to hold this against WoSign.

Regards,
Andrew

[1] In fact, stockpiling long-lived SHA-1 certs in 2015 would have been
vastly better for the ecosystem than using "legacy" roots or
requesting an exception in 2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

On Wed, August 31, 2016 10:09 pm, Richard Wang wrote:
>  Thanks for your so detail instruction.
>  Yes, we are improved. The two case is happened in 2015 and the mis-issued
>  certificate period is only 5 months that we fixed 3 big bugs during the 5
>  months.
>  For CT, we will improve the posting system.

I had a little trouble parsing this, but let's make sure we're on the same
page. I've continued Gerv's original numbering:

Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1
certificates ( https://cert.webtrust.org/SealFile?seal=2019=pdf )
Incident -1: April 4, 2015 - WoSign is informed it's routinely violating
its CPS for issued certificates (
https://www.wosign.com/policy/wosign-policy-1-2-10.pdf )
Incident X: April 9 - April 14, 2015 - 392 duplicate serial numbers
Incident 0: April 23, 2015 - 72 potentially dangerous port-validated
certificates
Incident 1: June, 2015 - 33 unvalidated base-domain from sub-domain
certificates
Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
the only one? I wasn't clear from
https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
)

Just making sure we're in agreement about the facts and timelines
surrounding these, so that it's easier than debating 2 or 3 or 5 or more.


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

Re: Incidents involving the CA WoSign

[Vincent Lynch]

This may be getting a bit ahead of the discussion, but...

The exact relationship between WoSign and StartCom seems relevant to how these 
violations should be handled.

Whether browsers decide to distrust WoSign, require CTs for all/future certs, 
take some other "probationary" decision, or do nothing at all, the relationship 
between these two CAs needs to be fully understood to properly execute that 
decision.

If WoSign's violations are a result of bad policies/systems, and they own 
StartCom, should both CAs not face the same oversight/punitive action? If 
WoSign certs are to be logged in CT, do StartCom certs also need to be logged? 
If tomorrow, StartCom was to violate the BRs, is that viewed as a separate 
incident? Or grouped in with the other violations WoSign has had?

The question of who owns/operates StartCom has been something the CA/Browser 
community has wondered about for the last few months.

Last night, https://www.letsphish.org was shared to this thread. The contents 
of that site are currently unavailable for stated legal reasons, but the site 
can still be accessed through Google's Cache: 
http://webcache.googleusercontent.com/search?q=cache:https://www.letsphish.org/?part=1

This site made the following claim (and provided supporting documentation):

"Reviewing StartCom registry in the Israeli company directory reveal that on 
November 1st, 2015 all the shares of the private held company were transfered 
to a UK based company named "StartCom CA Limited". This company, "StartCom CA" 
is owned by Gaohua Wang, who is of Chinese nationality."

The site further claims that Gaohua Wang and Richard Wang are the same person.

Previously in this thread, Richard wrote:

"[WoSign] shared some facility with StartCom like CRL and OCSP distribution 
etc."

However, the claims raised by LetsPhish.org, the connections between StartCom's 
StartEncrypt system and WoSign's issuance systems, and other assertions 
(https://pierrekim.github.io/blog/2016-02-16-why-i-stopped-using-startssl-because-of-qihoo-360.html)
 have made it obvious that we do not *know* very much.

I think Eddy Nigg (founder of StartCom) and/or Richard Wang (of WoSign) should 
make a statement about this.
___
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

[keycurves]

> It is clear to us, and appears to be clear to
> other CAs based on their actions, that misissuances where domain control
> checks have failed fall into the category of "serious security concern".
> 
...
> * It seems clear from publicly available information that StartCom's
> issuance systems are linked to WoSign's issuance systems in some way.
> Nevertheless, it should not have been possible for an application for a
> cert from StartCom to produce a cert signed by WoSign.
> 
> * This misissuance incident was not reported to Mozilla by WoSign as it
> should have been.
> 
> 
> Taking into account all these incidents and the actions of this CA,
> Mozilla is considering what action to take. Your input is welcomed.
> 
 
I have read the details of this incident made public to date, and in my view, 
this comes down to two fairly simple questions: Did WoSign betray the public 
trust, and when mistakes were made were they proactive and transparent in 
resolving them?

The *only* currency for a public CA is trust, and WoSign broke that trust by 
attesting to control of (critical) TLDs when in fact, such control did not 
exist. There is no difference between issuing fraudulent certificates to a 
security researcher as there is to any bad actor. Worse, after being made aware 
of the issue (and related vulnerabilities in their system), WoSign acted in bad 
faith by failing to proactively revoke all fraudulent certificates, notify 
their auditor, or inform Google and Mozilla. The behavior with StartCom only 
punctuates that continued bad faith and unwillingness to conform with the most 
basic obligations of a CA.

I probably don't need to remind most of you here how already tenuous is the 
confidence in the existing public key system generally, and TLS security 
specifically.

In light of their continued actions, I strongly urge the community to remove 
WoSign from the respective root trust stores.


Kenn White
https://opencryptoaudit.org/people


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

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

On Thursday, September 1, 2016 at 5:30:28 AM UTC-7, Erwann Abalea wrote:
> The whitelist for EV logged before 01/01/15 contained around 180k 
> certificates, each one identified by a 64bits digest, the list was compressed 
> in order to gain 25%, the result was an object slightly larger than 1MB.
> Today, this list contains around 110k certificates, and it's less than 680KB.

Note: The EV whitelist uses a probablistic structure that Google was 
comfortable with when determining EV, since it would also have needed to have 
the EV policy OIDs, and thus unlikely to be "gamed," but when considering 
trust, is unacceptably high in the false-positive case when considering a CA 
that may not be trustworthy.

For example, the CNNIC whitelist, as implemented by both Chrome and Firefox, 
uses the full 32-byte hashes.

If we accept 110K (for your number), that's 3.5 megs (uncompressed). If we 
accept Peter's estimate, that's 6.3 megs (uncompressed). If we accept the full 
230K Richard posted, that's 6.4 megs (uncompressed).

We should probably fork off to the other thread if we're going to consider to 
discuss whitelist technical solutions, if there is community interest, and we 
can discuss the various concerns and tradeoffs between probablistic data 
structures (such as Golomb coded sets like the EV whitelist uses, Bloom filters 
as was proposed elsewhere in the past, and other forms of compression), as well 
as run concrete analysis of various implementations.

As of yet, there doesn't seem to be a good inline solution that adequately 
reflects the facts surrounding it, if a whitelist is determined to be suitable.
- Date based retroactive trust is impaired by known backdating
- Full whitelists are insufficiently large
- Probabablistic whitelists can be gamed with false positives (And I'm actively 
factoring in the CPU cost involved with signing as part of this threat model, 
assuming both "worst case" and "reasonable case")
- Online lookups have privacy flaws (same as OCSP)

I say "SafeBrowsing-like", but for sake of the PKIX familiar, it might 
otherwise be rephrased as "shared certificate *Trust* lists with 
issuerDistributionPoints", which is effectively the same thing :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Erwann Abalea]

Bonjour,

Le jeudi 1 septembre 2016 09:27:11 UTC+2, Ryan Sleevi a écrit :
> On Wednesday, August 31, 2016 at 11:03:11 PM UTC-7, Percy wrote:
[...]
> > Or we can use an offline whitelist. How about include SHA-2 of existing 
> > WoSign certificates in the binary? So the browser would first check whether 
> > it's signed by WoSign, if so, compare the hash of the cert with the offline 
> > list.  224 bit hash * 230K certificate = 6.5 MB. Considering the Chrome 
> > installer file is almost 70MB, this might be acceptable. 
> 
> 1) SHA-2 is 256-bit, not 224-bit
> 2) A 100KB increase is unacceptable, especially for mobile users.

The whitelist for EV logged before 01/01/15 contained around 180k certificates, 
each one identified by a 64bits digest, the list was compressed in order to 
gain 25%, the result was an object slightly larger than 1MB.
Today, this list contains around 110k certificates, and it's less than 680KB.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-08-31 20:13, Ryan Sleevi wrote:

Setting aside for a second whether or not distrusting is the right action, 
let's think about what possible responses.

A) Remove the CA. Users may manually trust it if they re-add it, but it will 
not be trusted by default.
B) Actively distrust the CA. Even if manually added (by user or enterprise 
policy), it will not be trusted.
C) Remove the CA. Develop a whitelist of pre-existing certificates to be 
trusted.
  - What form should this whitelist take?
* Shipping it in the binary is unacceptably large.
* Downloading it in full on demand is unacceptably large/unreliable.
* Checking with a central server for serial number can lead to misleading 
results (WoSign has shown they issue duplicate serials, and nothing would 
prevent them from doing so in the future)
* Checking with a central server for certificate hash may have privacy 
considerations.
* Conclusion: Something SafeBrowsing-like would have to be developed ( 
https://developers.google.com/safe-browsing/v4/ ), which could be months away.
D) Distrust any certificate without appropriate CT information. Whitelist certs 
before 2016.
  - See whitelist problems above
E) Distrust certs without appropriate CT information, wholesale.
  - Note: It appears that WoSign is or has had similar issues to Symantec, 
failing to log to a diverse-enough set of logs to ensure a robust CT 
implementation. A quick and random sampling shows, for example, that 
precertificates are only being logged to Google logs (such as for 8-30-16). 
Thus, unless an implementation is willing to fully trust Google CT logs alone - 
something Google themselves are unwilling to do - then this suggests that this 
may be the same as wholesale distrusting.


An other option is to only trust certificates issued before a certain date.

We seem to have a problem trusting the date in the certificate, so this 
might need to be in combination with an SCT from before that date.  I 
think the easiest way to do this is have the SCT in the OCSP response, 
but it would require the server to do OCSP stapling.  It would then be 
up to the CA to make sure they are submitted to enough logs, that the 
OCSP server returns them, and that they inform their clients to make 
sure OCSP stapling is turned on.



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

[Ryan Sleevi]

On Wednesday, August 31, 2016 at 11:03:11 PM UTC-7, Percy wrote:
> Indeed, WoSign has become too big to fail. I would suggest that the decision 
> whether to remove WoSign should be independent of whether it's practical to 
> implement such removal. Otherwise, larger CA basically gained "natural 
> protection" from mere usage numbers over smaller CA in terms of enforcement 
> actions. 

Note: I intentionally did not phrase it in terms of practicality of removal, 
but practicality of options. Whatever decision is made, it must be 
implementable, otherwise, it's theatre. So you have to consider what is 
possible when considering what is appropriate. If we allow ourselves to 
consider the impossible as options, then it might as well say that any CA that 
screws up needs to travel back in time and unissue the certificates, since 
surely that too would solve the problem.

> On the practical implementation, I suggest the following.
> All existing certs issued by WoSign need to be logged by enough CT logs by 
> say Dec 31, 2016.  
> After Jan 1, 2017, the browser will only trust a cert from WoSign if 
> 1) CT is present 
> 2) The cert is submitted to CT logs before Dec 31, 2016.  

CT is not designed nor intended for online checking, so #2 is a non-starter.

> Or we can use an offline whitelist. How about include SHA-2 of existing 
> WoSign certificates in the binary? So the browser would first check whether 
> it's signed by WoSign, if so, compare the hash of the cert with the offline 
> list.  224 bit hash * 230K certificate = 6.5 MB. Considering the Chrome 
> installer file is almost 70MB, this might be acceptable. 

1) SHA-2 is 256-bit, not 224-bit
2) A 100KB increase is unacceptable, especially for mobile users.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

On Wednesday, August 31, 2016 at 8:05:57 PM UTC-7, 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;

I would have hoped, through all of this, that you would have come to realize 
the seriousness and gravity of the multiple problems that WoSign has had over 
the past 18 months, rather than continue to dismiss it.

You misissued certificates to people who were not authorized. Repeatedly. In 
multiple separate instances.

You have had multiple issues with adhering to the Baseline Requirements, and 
those have not been disclosed, to your auditors or browsers. Consider Incident 
-1, which was not listed here in this thread yet, on April 4, 2015, which 
caused you to update your CPS ( 
http://www.wosign.com/policy/wosign-policy-1-2-10.pdf ) to correct several 
issues that Google reported to you regarding non-compliance to your stated 
policies and to the BRs.

Ultimately, CAs are based on trust:
- Trust that they're performing the necessary validation and vetting procedures
- Trust that they are securing their internal systems from both internal and 
external threats
- Trust that they understand the seriousness of their role as a provider of 
global certificates, any of which might be used to compromise or attack users, 
and take adequate steps to ensure the correctness of those operations.

Your responses, unfortunately, have done little to instill or affirm that the 
trust is well placed. Even more so, you're a CA authorized to issue the most 
rigorous certificates available (Extended Validation), and so the bar is set 
even higher for your operational controls and processes!

- You failed to understand the gravity of the misissuance, and thus failed to 
revoke these certificates. I would argue this constitutes a further BR 
violation itself, per Section 4.9.1.1 of the BRs ( 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.8.pdf ), in 
particular, Items 4 and Items 9 in that list, but would be curious if you 
disagree.
- You have repeatedly suggested this was an honest mistake, suggesting it was a 
singular issue, when the reality is that it is a pattern of mistakes that have 
spanned over a year and have led to multiple misissued certificates.
- These incidents - including the issue with the CPS page - suggest a software 
development methodology that fails to adequately ensure the robustness of the 
systems, and fails to understand the security risks that must be mitigated in 
such systems.

When there are concerns that undermine trust, it's important to engage to 
restore trust, and so I truly appreciate your involvement in these discussions, 
and your efforts to restore that trust. And while it's understandable that, in 
any security incident, there will be disagreements regarding severity or 
impact, it's vitally important for an entity whose product depends on trust 
takes steps to understand the issues, understand the perspectives, and takes a 
careful look to understand why so many people are disagreeing with the risk 
assessment or mitigation strategy.

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

Alternatively, WoSign dismissed the need to revoke the certificates, despite 
knowing that they were not validated according to the BRs, routinely violated 
their CPS, failed to notify either browsers or their auditors of these issues, 
all while violating other provisions of the Baseline Requirements that were 
disclosed - such as duplicate serials and SHA-1 certificates.

This is a vast departure from, say, the thread last month - 
https://groups.google.com/d/msg/mozilla.dev.security.policy/9QKw1C3m4Lo/nkg1rcJyAgAJ
 - and shows how significant the gap in perception and user trust can be, based 
on how a CA handles an incident and the subsequent public discussion.

> 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, we logged all issued certificate to CT log server and 
> embedded SCT data to certificate since July 5th. Thanks for Google invent so 
> good transparency system.

And yet, although you've committed to logging your certificates, your logging 
has failed to abide by the one policy that exists for CT logging - the Chromium 
CT policy ( 
https://www.chromium.org/Home/chromium-security/certificate-transparency ).

While it's laudable that you're logging your certificates at all, there's two 
important pieces being omitted here:
- By only logging to Google logs, you're not necessarily improving trust, 
because now the burden is to trust Google.
- This is an issue I personally informed you about and discussed at length with 
you on May 25, 2016.

For example, as highlighted in the 

RE: Incidents involving the CA WoSign

[Richard Wang]

Fair enough, thank you, Ryan.

This is my last formal statement for this issue that I am tired of this 
argument, I need to go to hospital now :-).

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;

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.
(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. 55% from China, 45% is out of China 
that 14% from Russia, 4.2% from Germany, 3.6% from Ukraine, 2.1% from USA. 
Those worldwide subscribers mostly are using WoSign free SSL certificate that 
shared the benefit of China economy grow.  

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, we logged 
all issued certificate to CT log server and embedded SCT data to certificate 
since July 5th. Thanks for Google invent so good transparency system.

Finally, I am very sorry to all browsers that we don't execute the incident 
report policy properly, WoSign get a deep lesson for how to deal with this kind 
of incident now, I wish everyone give us a chance to be a good boy, at least 
one-time chance.  Thanks a million.


Best Regards,

Richard Wang
CEO
WoSign CA Limited



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Ryan Sleevi
Sent: Thursday, September 1, 2016 2:14 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

On Wednesday, August 31, 2016 at 10:07:19 AM UTC-7, watso...@gmail.com wrote:
> Dear Richard,
> 
> It's clear WoSign has continuing compliance issues with CA/Browser forum 
> rules, and has repeatedly failed to correct them. Furthermore there has been 
> lots of questions about what it would take to improve CA practices given the 
> degree of incompetence some have practiced, and it's clear penalties would go 
> a long way.
> 
> Is there a reason we shouldn't permanently ban WoSign, and all CAs controlled 
> by people involved with it, from the root program? 

For how long?

> It seems clear that WoSign has been misleading its auditors repeatedly and 
> has insufficient tracking of which certificates are issued, has been aware of 
> these problems for years, and has not been forthright in addressing them. 

These are all very compelling arguments.

> Making an example would do a lot to encourage better CA behavior in general.

This is less compelling, because "making an example" seems a subjective 
judgement/punitive response, although you to clarify "to encourage better CA 
behaviour".


At present, it looks like there's around 60K (active, valid) WoSign certs 
presently logged in CT logs, either through WoSign's logging or through 
secondary sources (such as Google's crawling). Richard has indicated that 
WoSign issued around 115K certificates in 2015 alone, but it's unclear how much 
overlap that would have; if we assume the worst case, and that they're all 
unique certs not previously before seen/logged (for example, perhaps due to the 
Great Firewall causing difficulty for Google's crawler), and if we generously 
extrapolate the same amounts for 2014, and take a quarter of that for 2013 
certs that could still be valid within the 39 month window, we end up with an 
"Extreme Worst Case" of 319K certs. While I suspect the number if likely much 
lower, especially when considering when WoSign switched to SHA-2 (as the SHA-1 
certs will be invalid by January 1, 2017), let's operate on two assumptions:
1) "Best Case" of say, ~200K valid certs
2) "Worst Case" of, say, ~319K valid certs

If browser vendors/root stores move to distrust WoSign, all of these certs 
would be invalidated. We know that a number of sites within the Alexa Top 1M 
are (intentionally) using WoSign, so we can expect a large number of users, 
across browser vendors, are accessing these sites, and would thus be seeing a 
significant amount of SSL/TLS error pages if the CA was distrusted. We know 
that major platform providers (such as Microsoft Azure) have partnered with 
WoSign as well, and thus further suggest a larger than desired user impact.


Setting aside for a second whether or not distrusting is the right action, 
le

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

On Wednesday, August 31, 2016 at 10:07:19 AM UTC-7, watso...@gmail.com wrote:
> Dear Richard,
> 
> It's clear WoSign has continuing compliance issues with CA/Browser forum 
> rules, and has repeatedly failed to correct them. Furthermore there has been 
> lots of questions about what it would take to improve CA practices given the 
> degree of incompetence some have practiced, and it's clear penalties would go 
> a long way.
> 
> Is there a reason we shouldn't permanently ban WoSign, and all CAs controlled 
> by people involved with it, from the root program? 

For how long?

> It seems clear that WoSign has been misleading its auditors repeatedly and 
> has insufficient tracking of which certificates are issued, has been aware of 
> these problems for years, and has not been forthright in addressing them. 

These are all very compelling arguments.

> Making an example would do a lot to encourage better CA behavior in general.

This is less compelling, because "making an example" seems a subjective 
judgement/punitive response, although you to clarify "to encourage better CA 
behaviour".


At present, it looks like there's around 60K (active, valid) WoSign certs 
presently logged in CT logs, either through WoSign's logging or through 
secondary sources (such as Google's crawling). Richard has indicated that 
WoSign issued around 115K certificates in 2015 alone, but it's unclear how much 
overlap that would have; if we assume the worst case, and that they're all 
unique certs not previously before seen/logged (for example, perhaps due to the 
Great Firewall causing difficulty for Google's crawler), and if we generously 
extrapolate the same amounts for 2014, and take a quarter of that for 2013 
certs that could still be valid within the 39 month window, we end up with an 
"Extreme Worst Case" of 319K certs. While I suspect the number if likely much 
lower, especially when considering when WoSign switched to SHA-2 (as the SHA-1 
certs will be invalid by January 1, 2017), let's operate on two assumptions:
1) "Best Case" of say, ~200K valid certs
2) "Worst Case" of, say, ~319K valid certs

If browser vendors/root stores move to distrust WoSign, all of these certs 
would be invalidated. We know that a number of sites within the Alexa Top 1M 
are (intentionally) using WoSign, so we can expect a large number of users, 
across browser vendors, are accessing these sites, and would thus be seeing a 
significant amount of SSL/TLS error pages if the CA was distrusted. We know 
that major platform providers (such as Microsoft Azure) have partnered with 
WoSign as well, and thus further suggest a larger than desired user impact.


Setting aside for a second whether or not distrusting is the right action, 
let's think about what possible responses.

A) Remove the CA. Users may manually trust it if they re-add it, but it will 
not be trusted by default.
B) Actively distrust the CA. Even if manually added (by user or enterprise 
policy), it will not be trusted.
C) Remove the CA. Develop a whitelist of pre-existing certificates to be 
trusted.
  - What form should this whitelist take? 
* Shipping it in the binary is unacceptably large.
* Downloading it in full on demand is unacceptably large/unreliable.
* Checking with a central server for serial number can lead to misleading 
results (WoSign has shown they issue duplicate serials, and nothing would 
prevent them from doing so in the future)
* Checking with a central server for certificate hash may have privacy 
considerations.
* Conclusion: Something SafeBrowsing-like would have to be developed ( 
https://developers.google.com/safe-browsing/v4/ ), which could be months away.
D) Distrust any certificate without appropriate CT information. Whitelist certs 
before 2016.
  - See whitelist problems above
E) Distrust certs without appropriate CT information, wholesale.
  - Note: It appears that WoSign is or has had similar issues to Symantec, 
failing to log to a diverse-enough set of logs to ensure a robust CT 
implementation. A quick and random sampling shows, for example, that 
precertificates are only being logged to Google logs (such as for 8-30-16). 
Thus, unless an implementation is willing to fully trust Google CT logs alone - 
something Google themselves are unwilling to do - then this suggests that this 
may be the same as wholesale distrusting.

In effect, a number of these options boil to a set of concerns:
- Distrusting can be significantly disruptive to end-users, potentially 
habituating them to SSL warnings or errors
- Distrusting potentially could interfere with those who may still want to 
trust WoSign manually, themselves
- Distrusting in a way that minimizes disruption has concerns for privacy, 
stability, or timeliness.

I'm not trying to suggest that distrusting is right or wrong, but I am curious 
for those who would advocate distrusting how browser vendors, such as Google 
and Mozilla, for example, might appropriately balance the 

Re: Incidents involving the CA WoSign

[watsonbladd]

On Tuesday, August 30, 2016 at 8:07:49 PM UTC-7, Richard Wang wrote:
> This case is in the BR report: 
> https://cert.webtrust.org/SealFile?seal=2019=pdf
> 
> Thanks.
> 
> Best Regards,
> 
> Richard
> 

Dear Richard,

It's clear WoSign has continuing compliance issues with CA/Browser forum rules, 
and has repeatedly failed to correct them. Furthermore there has been lots of 
questions about what it would take to improve CA practices given the degree of 
incompetence some have practiced, and it's clear penalties would go a long way.

Is there a reason we shouldn't permanently ban WoSign, and all CAs controlled 
by people involved with it, from the root program? It seems clear that WoSign 
has been misleading its auditors repeatedly and has insufficient tracking of 
which certificates are issued, has been aware of these problems for years, and 
has not been forthright in addressing them. Making an example would do a lot to 
encourage better CA behavior in general.

Sincerely,
Watson Ladd

> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com] 
> Sent: Wednesday, August 31, 2016 10:45 AM
> To: Gervase Markham <g...@mozilla.org>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang 
> <rich...@wosign.com>
> Subject: Re: Incidents involving the CA WoSign
> 
> On Wed, Aug 24, 2016 at 6:08 AM, Gervase Markham <g...@mozilla.org> wrote:
> > Dear m.d.s.policy,
> >
> > Several incidents have come to our attention involving the CA "WoSign".
> > Mozilla is considering what action it should take in response to these 
> > incidents. This email sets out our understanding of the situation.
> >
> > Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> > Enforcement Policy[0] says: "When a serious security concern is 
> > noticed, such as a major root compromise, it should be treated as a 
> > security-sensitive bug, and the Mozilla Policy for Handling Security 
> > Bugs should be followed." It is clear to us, and appears to be clear 
> > to other CAs based on their actions, that misissuances where domain 
> > control checks have failed fall into the category of "serious security 
> > concern".
> 
> I have run into another bug that appears to be fixed in WoSign's 
> infrastructure but is worth noting.
> 
> In April 2015, two different WoSign CAs issued multiple certificates to 
> distinct subjects using the same serial number.  The CT logs have picked up 
> two instances of this occuring:
> 
> https://crt.sh/?serial=0D3BBDC3A0175E38F9D0070CD050986A shows eight distinct 
> certificates with the same serial number, all with notBefore dates of 
> 2015-04-14.
> 
> https://crt.sh/?serial=056D1570DA645BF6B44C0A7077CC6769 shows dozens of 
> distinct certificates with the same serial number, with notBefore dates 
> between 2015-04-10 and 2015-04-14.
> 
> I have not examined their management assertions to see if this was documented 
> and I do not know if this was reported to Mozilla at the time.  These 
> certificates do not appear to meet RFC 5280's requirements, which say:
> 
>"The serial number MUST be a positive integer assigned by the CA to
>each certificate.  It MUST be unique for each certificate issued by a
>given CA (i.e., the issuer name and serial number identify a unique
>certificate)"
> (https://tools.ietf.org/html/rfc5280#section-4.1.2.2)
> 
> Was Mozilla advised of this issue?
> 
> 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

[jozef . izso]

As an admin I want to check the WoSign Issuer Policy provided by their "WoSign 
CA Free SSL Certificate G2" certificate.

Issuer Policy is linked to http://www.wosign.com/policy/
This page shows the source code instead of actual policy.

<% Dim strAcceptLanguage 
strAcceptLanguage=Request.ServerVariables("HTTP_ACCEPT_LANGUAGE") 
'response.write strAcceptLanguage if instr(strAcceptLanguage,"zh")>0 then 
Response.Redirect "cps.htm" else Response.Redirect "cps_e.htm" end if %>

WoSign does not look like trust worthy CA. Unfortunately their certificates are 
trusted because the StartCom CA is trusted by OS.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 24/08/16 14:08, Gervase Markham wrote:
> * The issuance of certificates using SHA-1 has been banned by the
> Baseline Requirements since January 1st, 2016. Browsers, including
> Firefox, planned to enforce this[2] by not trusting certs with a
> notBefore date after that date, but in the case of Firefox the fix had
> to be backed out due to web compatibility issues. 

Just as a note, this information is incomplete - the enforcement
returned for publicly-trusted CAs in bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1254667 , since Firefox 48.

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]

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

Re: Incidents involving the CA WoSign

[sam]

To the policymakers at Mozilla, my name is Samuel Pinder.
I consider myself an computer network analyst and have a degree in Web Systems 
Development. I also host a small number of websites on a technical level. I 
have used Startcom's services for a number of years. I only recently came 
across WoSign when I discovered that they offer 3-year valid certificates for 
free for up to 5 hostnames. That seemed quite an excessively long time in my 
opinion for a free certificate, almost too good to be true. As a customer of 
effectively both WoSign and Startcom, I have been having gradually growing 
concerns for some time about their recent practices and this recent news has 
not helped. I am currently looking into using other CA's for my needs but will 
watch what happens next closely before making a decision. I firmly believe 
WoSign have almost 'purchased' Startcom as I noticed that the nameserver domain 
for startssl.com (namely startcomca.net) would bring up WoSign's website for a 
time when accessed via a web browser as www.startcomca.net. I personally 
emailed Eddy Nigg (Startcom founder) about this, and this was eventually 
changed to redirect to startssl.com. So it is obvious that WoSign is 
hosting/sharing Startcom's infrastucture on it's own CA hardware/software, 
which Eddie confirmed in his email reply. The SSL certificate at the time for 
www.startcom.org had expired for over a week and still does have many broken 
links. Using the 'Live Chat' on www.startssl.com had a very confused employee 
tell me that startcom.org is no longer the website for Startcom, but 
startssl.com is. I stressed that this was confusing to people and that they 
should redirect the latter if that's the case. However... startcom.org remains 
using Israeli-based nameservers. Just how closely related Startcom is to WoSign 
is unknown, but it does mean that almost anything that renders WoSign 
vulnerable, also applies to Startcom. I would hope that Startcom re-evaluate 
their relationship with WoSign following this mess at the very least.
Regarding WoSign in particular, the SHA-1 miss-issued certificates does look 
like a genuine mistake, being issued off of an SHA-2 intermediate makes their 
existence rather pointless in the case of backward compatibility, as old 
operating systems need a whole SHA-1 chain to validate properly. So there is no 
obvious motive for this API functionality to be left there on purpose, 
unless a rogue employee/subcontractor left it in place for when a SHA-1 
hash collision becomes possible? What is likely here is that SHA-1 used to be 
the default signature choice, and was indeed legacy functionality left behind. 
It is very concerning however that despite WoSign having an external audit 
(which all CA's are meant to have) it appears nobody has independently 
performed a code audit of their API backend to prevent this being possible in a 
production environment. With regards to the mis-issued certificates applying to 
whole base domains validated only sub-domain, that prospect is horrifying. With 
regards to WoSign's API following 301 redirects from one domain to another 
though, I have noticed that Let's Encrypt's API (another CA at letsencrypt.org) 
also has this behaviour. This may be standard behaviour of the ACME protocol. 
Perhaps it would be prudent to decide in overall policy whether 301 redirects 
of verification URLs are acceptable. There are legitimate reasons why this 
would happen, for example if a customer owned www.example1.com and 
www.example2.net, but wanted the latter to always redirect to the other 
(because for example of a name change, but had many hardcoded https:// links), 
they would otherwise have to temporarily disable the redirect to get an SSL 
certificate covering both domains when validating with this method. With 
regards to ports other than 80 and 443 and 8080 being used for validation, I 
think the motive of this is because China has a mandatory media licencing 
requirement (ICP licence) for all servers that operate on either ports. It may 
not be practical for an individual in China to get one of these licences just 
to be able to gain an SSL certificate with this validation method. Of course 
allowing higher numbered ports does not give much excuse. I tested WoSign's 
website today however and can confirm that they have removed URL-based file 
verification, and now only allow DNS or email (from WHOIS) validation. All 
that's well and good, but the fact remains that there could be many other 
mis-issued certificates already in existence and the scope remains unknown at 
this point just how many. We only have WoSign's word that all of the mis-issued 
certificates are known and/or revoked. If it cannot be certain that WoSign have 
revoked all incorrectly-validated certificates, then the obvious choice is to 
add the "WoSign CA Free SSL Certificate G2" intermediate to OneCRL, and 
possibly their DV intermediate too, as these intermediates are known to have 

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 29/08/16 22:53, Percy wrote:
> 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

That might also help; thank you. Please ask them to contact me directly
to confirm this cert was not requested by them.

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

[Peter Gutmann]

itk98...@gmail.com  writes:

>Wosign indirectly bought StartSSL, https://www.letsphish.org

Has there been any independent investigation into this?  We know that CAs are
bought and sold like baseball trading cards, but it's usually done publicly
and freely acknowledged, whereas this one seems to have been done in a
somewhat underhanded manner...

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

Re: Incidents involving the CA WoSign

[Percy]

On Tuesday, August 30, 2016 at 7:47:43 PM UTC-7, itk9...@gmail.com wrote:
> Wosign indirectly bought StartSSL, https://www.letsphish.org


Ha! It makes so much sense now why StartEncrypt is such a 
catastrophe(https://www.google.com/search?q=StartEncrypt). I've revoked all 
StarCom certs in my OS. Thanks for the heads up! 

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

RE: Incidents involving the CA WoSign

[Richard Wang]

This case is in the BR report: 
https://cert.webtrust.org/SealFile?seal=2019=pdf

Thanks.

Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Wednesday, August 31, 2016 10:45 AM
To: Gervase Markham <g...@mozilla.org>
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Richard Wang 
<rich...@wosign.com>
Subject: Re: Incidents involving the CA WoSign

On Wed, Aug 24, 2016 at 6:08 AM, Gervase Markham <g...@mozilla.org> wrote:
> Dear m.d.s.policy,
>
> Several incidents have come to our attention involving the CA "WoSign".
> Mozilla is considering what action it should take in response to these 
> incidents. This email sets out our understanding of the situation.
>
> Before we begin, we note that Section 1 of the Mozilla CA Certificate 
> Enforcement Policy[0] says: "When a serious security concern is 
> noticed, such as a major root compromise, it should be treated as a 
> security-sensitive bug, and the Mozilla Policy for Handling Security 
> Bugs should be followed." It is clear to us, and appears to be clear 
> to other CAs based on their actions, that misissuances where domain 
> control checks have failed fall into the category of "serious security 
> concern".

I have run into another bug that appears to be fixed in WoSign's infrastructure 
but is worth noting.

In April 2015, two different WoSign CAs issued multiple certificates to 
distinct subjects using the same serial number.  The CT logs have picked up two 
instances of this occuring:

https://crt.sh/?serial=0D3BBDC3A0175E38F9D0070CD050986A shows eight distinct 
certificates with the same serial number, all with notBefore dates of 
2015-04-14.

https://crt.sh/?serial=056D1570DA645BF6B44C0A7077CC6769 shows dozens of 
distinct certificates with the same serial number, with notBefore dates between 
2015-04-10 and 2015-04-14.

I have not examined their management assertions to see if this was documented 
and I do not know if this was reported to Mozilla at the time.  These 
certificates do not appear to meet RFC 5280's requirements, which say:

   "The serial number MUST be a positive integer assigned by the CA to
   each certificate.  It MUST be unique for each certificate issued by a
   given CA (i.e., the issuer name and serial number identify a unique
   certificate)"
(https://tools.ietf.org/html/rfc5280#section-4.1.2.2)

Was Mozilla advised of this issue?

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

[itk98 . il]

Wosign indirectly bought StartSSL, https://www.letsphish.org

On Monday, August 29, 2016 at 11:27:59 AM UTC+3, Gervase Markham wrote:
 
> 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy