Re: Incidents involving the CA WoSign

[Percy]

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

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

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

Re: Security concern on various domain validating methods

[Ryan Sleevi]

On Wednesday, September 7, 2016 at 10:43:34 AM UTC-7, Han Yuwei wrote:
> I raise this question because of the Wosign's incident about high port 
> validating. Many CA use email validating such as send a email to 
> webmas...@foo.bar, or put a specific file into the root of website.
> What I think is that this cannot validate *domain* is yours.  It just 
> verified you have the mail server or you control the host. The best way to 
> prove you own a domain is to change the DNS records of the domain.
> So I suggest to change domain validating method to verify DNS records. Is 
> that feel better?

Hi,

It sounds like you may not be familiar with the Baseline Requirements, which 
specifically spell out how to validate domains - 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.9.pdf

This already covers the specific set of email addresses that are 
reserved/acceptable to be used, the methods of file based validation, and other 
forms of DNS record-based validation. This was the result of a nearly 2 year 
effort to strengthen the requirements, and while it's far from being as rock 
solid as we might want, it hopefully provides a better path to prevent many of 
the mistakes made.

To understand specifically what changed recently, perhaps review 
https://cabforum.org/2016/08/05/ballot-169-revised-validation-requirements/

If you have any further concerns, you could certainly raise them to the 
CA/Browser Forum - questi...@cabforum.org - or by signing up as an Interested 
Party, as explained at https://cabforum.org/email-lists/ and in the Forum's 
Bylaws - but it's likely that you would find many concerns have already been 
discussed or are in the process of being discussed.
___
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 Wed, Sep 07, 2016 at 02:08:24PM +0200, Kurt Roeckx wrote:
> On 2016-09-07 13:00, Gervase Markham wrote:
> > Hi Richard,
> > 
> > On 07/09/16 11:06, Richard Wang wrote:
> > > This discuss has been lasting two weeks, I think it is time to end
> > > it, it doesn’t worth to waste everybody’s precious time.
> > 
> > Unfortunately, I think we may be only beginning.
> > 
> > I have prepared a list of the issues we are tracking with WoSign's
> > certificate issuance process and business:
> > 
> > https://wiki.mozilla.org/CA:WoSign_Issues
> 
> Thanks for putting this all in a page because I already lost track of most
> of the issues.
> 
> This URL was posted, and at least seems to match the date range:
> https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769=1662

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

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

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


Kurt

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

Re: (Optional) list of participants

[Kirk Hall]

On Tuesday, September 6, 2016 at 8:28:53 AM UTC-7, Gervase Markham wrote:
> While we try and evaluate contributions to this forum based on their
> content rather than on who posted them, the issue has been raised that
> it is sometimes useful to know where someone is coming from, who they
> represent, and what experience they have.
> 
> Therefore, I have started an entirely optional list of people who post
> to m.d.s.policy, along with information about them:
> 
> https://wiki.mozilla.org/CA:Policy_Participants
> 
> Please feel free to add yourself if you feel led; please do not add
> anyone other than yourself. This might also be a good place to say, if
> you want to be explicit about it, whether you are representing your
> employer or not.
> 
> Gerv

Great idea, Gerv.  Question: How will we remember how/where to find the list?  
(I never remember.)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Security concern on various domain validating methods

[Han Yuwei]

I raise this question because of the Wosign's incident about high port 
validating. Many CA use email validating such as send a email to 
webmas...@foo.bar, or put a specific file into the root of website.
What I think is that this cannot validate *domain* is yours.  It just verified 
you have the mail server or you control the host. The best way to prove you own 
a domain is to change the DNS records of the domain.
So I suggest to change domain validating method to verify DNS records. Is that 
feel better?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Jozef Izso]

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

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

Re: Incidents involving the CA WoSign

[dymutaos]

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

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

If the logs didn't store even the simple port information, what else isn't it 
storing? You say you'll do better in the future, but you have to be able to 
account for current and future bugs. In order to do that, you need accurate and 
verbose logs, or else a future vulnerability may be unable to be contained.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Steve Medin]

This certificate was just revoked. Kyle, thanks for bringing this to our
attention - we were able to start work once you posted here at m.d.s.policy.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o
rg] On Behalf Of Steve Medin
Sent: Tuesday, September 06, 2016 7:27 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham
; Kyle Hamilton 
Subject: RE: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)

Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3)
clearly applies as well as other clauses. At this point, revocation is less
harm than the key compromise. It may be an effective way to get the message
to the affected device operators who have not replaced the default
certificate with a purchased one.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
Sent: Tuesday, September 06, 2016 7:06 PM
To: Steve Medin 
Cc: Gervase Markham ; Kyle Hamilton ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)

BRs require revocation within 24 hours of notice. It's a terrible timeline
but one the browsers have strictly enforced for even wide spread
deployments.

> On Sep 6, 2016, at 4:30 PM, Steve Medin  wrote:
> 
> We have become aware of this certificate and its key compromise, thank 
> you for this information. We are contacting the owner to understand 
> impact to the deployed devices, but with clear intent to revoke. We 
> will provide updates while we make progress.
> 
> Kind regards,
> Steven Medin
> PKI Policy Manager, Symantec Corporation
> 
> 
> 
> 
> -Original Message-
> From: dev-security-policy
>
[mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o
> rg] On Behalf Of Gervase Markham
> Sent: Tuesday, September 06, 2016 2:02 PM
> To: Kyle Hamilton ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Compromised certificate that the owner didn't wish to 
> revoke (signed by GeoTrust)
> 
>> On 06/09/16 18:25, Kyle Hamilton wrote:
>> Aruba chose not to notify GeoTrust that it needed to be revoked due 
>> to compromised private  key.  I am notifying because I believe it 
>> violates the Basic Requirements for someone other than the identified 
>> subject to possess the private key for a publicly-trusted certificate.
> 
> It does; have you notified GeoTrust using whatever mechanism they make 
> available for such notifications? They are supposed to have one, 
> according to the BRs. I'm not sure posting here would count.
> 
> Gerv
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 07/09/16 13:52, Rob Stradling wrote:
> Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
> see an explanation), but I'm not convinced that it proves everything you
> think it proves.

Hi Rob,

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

Is every conclusion I draw justified from the data?

Gerv

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

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

> What is suspicious is:
> 
> - Twice as many SHA-1 certificates being issued on a specific Sunday in 
> December than the daily average that month. (Which also happens to be the 
> date on the certificates which I personally got from the StartEncrypt API.)

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

> - The long difference between the notBefore and the embedded SCTs, if any.
> - Some of these certificates having an almost identical copy issued using 
> SHA-256 on a date in January. If the SHA-1 cert has embedded SCTs, then the 
> SHA-256 cert has them too and the SCTs of both certs are less than a minute 
> apart.
> 
> Of course, I can’t present hard cryptographic evidence that these 
> certificates did not exist then, but I fear nothing can.

Indeed.

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

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

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

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

> Hello,
> 
> We obtained 2 certificates from the StartEncrypt API which had SHA-1 
> signatures and which were backdated to December 20, 2015.
> 
> After WoSign announced that all certificates issued in 2015 were logged to 
> their Certificate Transparency server, I analyzed them to check if any other 
> certificates using SHA-1 signatures show signs of being backdated. Using the 
> Python tools from Google’s Certificate Transparency repository I downloaded 
> all certificates from the log and then queried them from an sqlite database. 
> Considering this is the first time I’m working with Certificate Transparency 
> logs, it might be better if someone else tries to reproduce my results. I’ve 
> generated a table here: 
> https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 
> (timestamps are in UTC).
> 
> I found 1204 certificates with a SHA-1 signature issued after December 1, 
> 2015. 53 of them included embedded SCT data, so can be dated more accurately.
> 
> The most interesting pattern I noticed was from sorting the certificates 
> based on the ID they have in WoSign’s Certificate Transparency log. Up to ID 
> 109149 
> (https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a),
>  the notBefore values are (approximately) chronologically ordered. Those 
> which have embedded SCTs have timestamps which are about 2 hours later than 
> the notBefore date.

Hi Thijs.  I agree that this pattern is interesting (and it'd be nice to
see an explanation), but I'm not convinced that it proves everything you
think it proves.

> But after that follow 64 certificates which are all dated on December 20, 
> 2015 (CST, UTC+8), including our two test certificates. Six of these have 
> embedded SCT data, but they have a large discrepancy between the notBefore 
> and the earliest SCT: 3 have a SCT of December 31 (11 days later) and 1 even 
> has a SCT of January 18, 2016, almost a full month after the notBefore. 
> (Unless I misunderstand the use of pre-certificates, this by itself already 
> implies the certificate was signed using SHA-1 on or after January 18, 2016.)

Yes.  A certificate that has embedded SCTs cannot have been issued any
earlier than any of the timestamps in those embedded SCTs (assuming
those timestamps are accurate, of course).

Of course, "implies...was signed...after" is only demonstrably true when
you have a copy of both the precertificate and the corresponding
certificate.  You can't prove it if you only have a copy of the
precertificate; the signature on a precertificate "indicates the
certificate authority's intent to issue a certificate" [RFC6962 section
3.1], but this doesn't mean the CA is required to issue the certificate.

> Aside from the 3 embedded SCTs on December 31, none of these certificates 
> have been logged to a Certificate Transparency server before January 1, 2016.

When a precertificate is logged, there is no need for the corresponding
certificate to be logged.  If the corresponding certificate does get
logged at some point later, so what?
Let's look at one of your examples:
aceeccdbb17b9096251dd11a84041ec75fe7a92e903ffe07c6d6b0a0c980d399
The fact that the certificate (https://crt.sh/?id=12367098) wasn't
logged until late January 2016 is uninteresting, because the
precertificate (https://crt.sh/?id=11751158) was logged on (and has a
notBefore date of) 31st December 2015.

Except for EV, certificates issued by WoSign aren't required (by Chrome)
to be logged.  If a certificate (for which there is no corresponding
precertificate) does get logged at some point long after its issuance
date, so what?
Let's look at one of your examples:
61b6289b1d3786e8f362e4049a4c5e24bb1356c0776fadb3a8a569f99d071a98
I see no evidence to suggest that this certificate was not issued on
30th December 2015, as suggested by its notBefore date.



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

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

Re: Incidents involving the CA WoSign

[Richard Wang]

We posted all 2015 certificates, total 109,405

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

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


Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On 2016-09-07 13:00, Gervase Markham wrote:

Hi Richard,

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

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


Unfortunately, I think we may be only beginning.

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

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


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


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

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


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


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



Kurt

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

Re: Incidents involving the CA WoSign

[Richard Wang]

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

Regards,

Richard

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


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

Re: Incidents involving the CA WoSign

[Gervase Markham]

Hi Richard,

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

Unfortunately, I think we may be only beginning.

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

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

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

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

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

With best wishes,

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

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Nick Lamb]

Responding to the scenario Jakob described which I agree is likely in outline

Let's Encrypt has seen a number of enquiries about relaxing their rate limits 
or granting some sort of exception so that firmware OEMs can use Let's Encrypt 
to have their devices self-issue using ACME from a name pool controlled by the 
OEM.

With ACME, out of the box a device can get itself unique, working Web PKI certs 
periodically so long as:

* It has some source of entropy
* It has an FQDN in the Internet's public DNS or can get one
* It can either make FQDN:80 or FQDN:443 reach it, or add DNS leaf records off 
the FQDN in the public DNS.

These are all eminently soluble problems and don't involve changes to the 
manufacturing process, unless entropy has to be somehow "baked in" to the 
devices to achieve that bullet point.

If you DIY, the rate limits obviously aren't a problem, and lots of DIY devices 
have Let's Encrypt issued certificates today. Home "routers" built out of a 
Raspberry Pi or a Mini PC are fairly popular with hobbyists. So rate limits 
(which exist for a perfectly sensible reason) are the only reason you can't buy 
a device that does this off the shelf.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Incidents involving the CA WoSign

[Richard Wang]

Hi Gerv, Kathleen and Richard,

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

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

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

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Hi all,

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

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

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


Best Regards,

Richard Wang
CEO
WoSign CA Limited


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

Dear m.d.s.policy,

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

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

Incident 0
--

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

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

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

Re: Incidents involving the CA WoSign

[Rob Stradling]

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

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

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

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

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

Re: Reuse of serial numbers

[Rob Stradling]

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=435013

On 06/09/16 18:55, Paul Wouters wrote:
> On Tue, 6 Sep 2016, Kyle Hamilton wrote:
> 
>>> That seems unlikely to me (in that browsers don't really keep a server
>>> cert database).
>>
>> Has that changed?  I talked with Dan Veditz (at Mozilla) around 5 years
>> ago regarding the fact that NSS had told me of duplicate serial numbers
>> being issued by a single issuer, and that as a result Firefox had
>> refused to permit me to connect to a site and also refused to allow me
>> to examine the certificate or identify it issuer for myself.  I had to
>> use OpenSSL to get it.  His action item at the time was to increase
>> reportability of those issues to Mozilla, because (paraphrased from his
>> words) "a CA issuing duplicate serial numbers is a violation of all of
>> the specifications and we need to know about it, to figure out what else
>> they're doing wrong".
> 
> I recently ran into this when NSS rejected an IPsec client certificate
> after a libreswan ipsec software upgrade. The upgrade replaced openswan
> which used custom X.509 code and did not use NSS and it did accept the
> certificate with duplicate serial number.
> 
> For IPsec, a seperate non-system NSS store is used, so I don't know
> how browsers handle this, but the NSS code is there to reject it _if_
> it encounters this.
> 
> Paul

-- 
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: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Jakob Bohm]

Given the specific name in those certificates, and the place where the
private key was seen, I would guess the actual use case is this:

Each router (presumably a SOHO router) contains a DNS server that
responds with its own internal RFC1918 IP address for the name
securelogin.arubanetworks.com and then the routers internal user
interface shows a https page with the router configuration user
interface.  The printed 1 page manual that accompanies those routers
probably says to plug in the router then open your browser and type in
that name with https in front.  No actual legitimate public server
would use that DNS name or certificate, and arubanetworks.com
presumably ensures this (that is certainly the current status of the
public DNS).

If that is indeed the use case, users are not going to replace that
certificate by any "real" certificate and will probably either generate
a per device self-signed certificate and then add a browser exception
OR they will just add a browser exception for the certificate that is
now going to be revoked.  Depending on the actual router firmware
available at github (and any older versions incorporating the same
certificate), the user may not even have the ability to replace the
certificate with a self-signed one.  Now sharing a single private key
among thousands of router user interfaces is obviously bad security,
but the common alternative (used by most other routers) is to use
unencrypted http, perhaps over an (initially) unencrypted WiFi link.

The correct, but more expensive, option would be for each router to get
a unique certificate for securelogin-.arubanetworks.com
(where  is the MAC address of the router) with an
intercepting redirect from securelogin.arubanetworks.com or something
similar.  However the process to securely generate and install a
different private key and certificate for each router on the
assembly line, and preserve those across routine firmware upgrades
would probably be costly in a cost-competitive market, even if the
router manufacturer ran a trusted sub-ca or could otherwise get the
certificates for free.  I guess that is why this router manufacturer
(presumably) chose to get a single low cost certificate and embed the
private key in the firmware images.

On 07/09/2016 01:26, Steve Medin wrote:

Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3)
clearly applies as well as other clauses. At this point, revocation is less
harm than the key compromise. It may be an effective way to get the message
to the affected device operators who have not replaced the default
certificate with a purchased one.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
Sent: Tuesday, September 06, 2016 7:06 PM
To: Steve Medin 
Cc: Gervase Markham ; Kyle Hamilton ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)

BRs require revocation within 24 hours of notice. It's a terrible timeline
but one the browsers have strictly enforced for even wide spread
deployments.


On Sep 6, 2016, at 4:30 PM, Steve Medin  wrote:

We have become aware of this certificate and its key compromise, thank you
for this information. We are contacting the owner to understand impact to
the deployed devices, but with clear intent to revoke. We will provide
updates while we make progress.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation




-Original Message-
From: dev-security-policy


[mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o

rg] On Behalf Of Gervase Markham
Sent: Tuesday, September 06, 2016 2:02 PM
To: Kyle Hamilton ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)


On 06/09/16 18:25, Kyle Hamilton wrote:
Aruba chose not to notify GeoTrust that it needed to be revoked due to
compromised private  key.  I am notifying because I believe it
violates the Basic Requirements for someone other than the identified
subject to possess the private key for a publicly-trusted certificate.


It does; have you notified GeoTrust using whatever mechanism they make
available for such notifications? They are supposed to have one, according
to the BRs. I'm not sure posting here would count.




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

Re: Reuse of serial numbers by StartCom

[Ryan Sleevi]

Kyle,

It is one trying to say NSS doesn't let you have multiple certificates with the 
same issuer and serial, which is factually true, but it's another to suggest 
this means it pins as you described, which is incorrect speculation.

I appreciate your attention to detail citing X.509, but let's not forget that 
it assumes the global directory of X.500 - which is a pure fiction that never 
truly manifest. NSS enforces the fictional, technically non-existent, entirely 
unreasonable assumption the Disitinguished Names are hierarchal and unique, 
neither of which is true, and enforces a serial number uniqueness upon that 
assumption, which can lead to trivial DoS issues for NSS using applications.

I mention all of this so that we can ignore the distraction presented by Eddy 
as to impact of relying parties, and instead focus on the technical conformance 
that was violated here. These certs won't work in NSS applications 
simultaneously, and they have to be revoked simultaneously, and both of these 
are explicitly undesirable. But more importantly, it is not for a CA to decide 
what violations are acceptable or not acceptable, or what their timeline is 
going to be for conformance, because otherwise that's indistinguishable from an 
absence of standards. If there are legitimate concerns with the standards as 
written, then it's worth publicly discussing to change the standards, but it's 
not acceptable to ignore them because it is inconvenient to conform, nor is 
"it's hard" a suitable response to continued misissuance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy