Re: Reuse of serial numbers by StartCom

[Kyle Hamilton]

On 9/4/2016 02:04, Eddy Nigg wrote:
> On 09/02/2016 07:02 PM, Nick Lamb wrote:
>> On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg  wrote:
>>> Lets speak about relying parties - how does this bug affect you?
>> As a relying party I am entitled to assume that there is no more than
>> one certificate signed by a particular issuer with a certain serial
>> number. If I have seen this certificate and verified by whatever
>> means I choose that it's OK, then I can safely assume that any time I
>> see a certificate in the future signed by that issuer with that same
>> serial number it's the same one, and skip the verification process.
>
> Well, according to the CA policies and relying party terms, you should
> always check with the CRL or OCSP responders if a certificate is
> considered valid or not. So the verification process shouldn't be
> skipped beyond the advertised refresh time (in CRLs/OCSP).
>
> Of course if you do some sort of certificate pinning based on serial
> and issuer, than this wouldn't work. But I'm not aware of any common
> software that doesn't use the certificate's public key for pinning and
> relies just on a serial numbers.
>

1: NSS does in fact pin on serial numbers.  It has actually stopped me
from utilizing a site in Firefox specifically because a CA had issued
multiple certificates with the same serial number.  As a relying party,
my first and foremost requirement is that my verification software can
and will actually let me rely on your assertions of identity, even
though it enforces the technical mandates of the specifications involved.

(A duplicate certificate serial number explicitly violates the
definition in section 3.5.13 of X.509.  Since PKIX is a profile of
X.509, PKIX inherits all assumptions and definitions of X.509. 
Furthermore, 4.1.2.2 of RFC 5280 specifies that it MUST be unique for
each certificate issued by a given CA.)

There is no mandate that a public key not be certified multiple times
(thus permitting renewals without rekeying), but there is a mandate that
multiple certificates with different information not be given the same
serial number.

2: If I were to get into a legal dispute with the subject of a
certificate you issued and needed to obtain the documentation you had
that was related to your issuance of that particular certificate, I
would probably request the documents from you based on the certificate
serial number.  You would then be able to pull the documents related to
that serial number and copy them appropriately.  With multiple
certificates having the same serial number it would be easier for the
following errors to show up:

a) provision of documents that related to a certificate that wasn't the
one in question (thus muddying the waters as to exactly who had been
identified by the certificate in question), and
b) failure to provision documents that did relate to the certificate in
question (thus throwing your due diligence and my reliance on it into
question), by being improperly identified by StartCom as not relevant to
the certificate in question.

In either case, your errors and omissions insurance would probably be
paying out because I wouldn't be able to prove the validity of my
reliance to pin whatever dispute on the entity I was suing.

-Kyle H
___
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)

[Jeremy Rowley]

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: Hongkong Post recently issued SHA1 cert that could be used in TLS

[Kathleen Wilson]

I updated https://bugzilla.mozilla.org/show_bug.cgi?id=1299579#c9
with:
""
... here is the approach that we plan to take:

We will add the "Hongkong Post e-Cert CA 1 - 10" intermediate cert to OneCRL at 
the end of October.

Please replace all of the SSL certs chaining up to this intermediate cert that 
expire after October, because we do not plan to add them to a whitelist.

We believe that this is a reasonable compromise. However, if there is 
compelling evidence to do so, we will add the intermediate cert to OneCRL 
earlier -- we will let you know if this becomes necessary.
""

Thanks,
Kathleen

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

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


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

Re: Incidents involving the CA WoSign

[Jakob Bohm]

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



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

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

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


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

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

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



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

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

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

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

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

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



Enjoy

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

Re: Incidents involving the CA WoSign

[Thijs Alkemade]

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

Hello,

We obtained 2 certificates from the StartEncrypt API which had SHA-1 signatures 
and which were backdated to December 20, 2015.

After WoSign announced that all certificates issued in 2015 were logged to 
their Certificate Transparency server, I analyzed them to check if any other 
certificates using SHA-1 signatures show signs of being backdated. Using the 
Python tools from Google’s Certificate Transparency repository I downloaded all 
certificates from the log and then queried them from an sqlite database. 
Considering this is the first time I’m working with Certificate Transparency 
logs, it might be better if someone else tries to reproduce my results. I’ve 
generated a table here: 
https://gist.github.com/anonymous/72920ff1b4450d38893dfa1b4863af52 (timestamps 
are in UTC).

I found 1204 certificates with a SHA-1 signature issued after December 1, 2015. 
53 of them included embedded SCT data, so can be dated more accurately.

The most interesting pattern I noticed was from sorting the certificates based 
on the ID they have in WoSign’s Certificate Transparency log. Up to ID 109149 
(https://crt.sh/?q=6d8665951cf6d8743200393a1085e0f6eb226270cc1f1402507d61faae93256a),
 the notBefore values are (approximately) chronologically ordered. Those which 
have embedded SCTs have timestamps which are about 2 hours later than the 
notBefore date.

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

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

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

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

For “ebank.pcnkbank.com”, similar:

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

For “congfubao.com”:

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

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

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



Best regards,
Thijs Alkemade

Computest • Pine Digital Security
E: talkem...@computest.nl • I: www.computest.nl  
A: Signaalrood 25 • 2718 SH Zoetermeer

Pine Digital Security is part of Computest



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

Re: Incidents involving the CA WoSign

[Gervase Markham]

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

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

Gerv


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

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

[Gervase Markham]

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

Re: Shipping custom certificate chain whithin Thunderbird

[Gervase Markham]

Hi vfbsilva,

On 05/09/16 19:28, vfbsi...@gmail.com wrote:
> Howdy, I need to deploy Thunderbird to all users of my company. We
> use a set of CA certificate which are not registered in Mozzila as of
> the current moment. We need that upon creation of cert.db on users
> home our chain whose files are presented here:
> https://ccd.serpro.gov.br/serproacf/opcoes/cadeia.html
> 
> I know I could place a new cert.db in every user folder but I would
> prefer to have the installer (in ubuntu) doing it.

It is not permitted under the Mozilla trademark policy to ship a product
called "Thunderbird" with an altered cert store. (As you can imagine, if
it were, that might lead to bad things happening.)

You can either a) rebuild and rebrand the product, after which point you
can do what you like, or b) have the certificate installation be an
entirely separate installation step, triggered by the user, which runs
after Thunderbird is installed, or c) use your OS's remote admin tools
to add it after installation (ideally with user knowledge).

Gerv

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

Re: (Optional) list of participants

[Gervase Markham]

Hi Percy,

On 06/09/16 16:46, Percy wrote:
> Percy Alpha; Researcher on Internet security and censorship in China
> http://percya.com ; CA related stuff: Broke the news on China's large
> scale MITM of Github in 2013, iCloud, Outlook, Yahoo in 2014; victim
> of Great Cannon (hijacking HTTP request) DDOS of the website and
> Github in 2015; called for CNNIC's revocation in 2013; monitored
> CNNIC's censorship on the news of it being revoked in 2015.

People should either a) get themselves an account on the Mozilla wiki
and add themselves, or b) if they feel they'd never use such an account
again, email me privately with specific permission to add them, and I will.

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

Re: Reuse of serial numbers

[Paul Wouters]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Jonathan Rudenberg]

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

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

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

[0] https://www.wosign.com/report/wosign_incidents_report_09042016.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Reuse of serial numbers

[Kyle Hamilton]

On 9/6/2016 04:59, Ben Laurie wrote:
> On 1 September 2016 at 11:29, Peter Gutmann  wrote:
>> Rob Stradling  writes:
>>
 I guess it makes them easy to revoke, if a single revocation can kill 313
 certs at once.
>>> That's true.
>> Hey, WoSign has solved the CRL scalability problem!
>>
>>> It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313
>>> certs though.
>> I also get the feeling that a lot of PKI software won't handle the revocation
>> properly, because they're expecting to revoke *the* certificate, not the
>> certificate, and the other certificate, and that other one there too, and 
>> that
>> one in the corner, and ... .  In other words I'm assuming most code will 
>> treat
>> serial numbers as unique and assume the revocation acted on when the first
>> cert has been marked as invalid.
> 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".

(That was during a conversation where I told him I'd come up with a
means of putting multiple end-entity certs into the TLS Certificate
message, in a way that proved possession of all of them but which would
break strict PKIX formatting of that message's content.)

-Kyle H

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

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

[Kyle Hamilton]

As far as I know, GeoTrust is not at fault here.  They just signed this
(domain validated) certificate, and I don't know if they've been
notified of it before.  That said, I don't have GeoTrust's contact info,
and I'm presuming that someone here does.

Information here comes from
http://blog.sec-consult.com/2016/09/house-of-keys-9-months-later-40-worse.html
.  The private key for this certificate was published by SEC Consult (a
Singaporean company) in a public github repo that documents static TLS
keys in embedded device firmware, located at
https://github.com/sec-consult/houseofkeys/ .

Aruba is the OEM for various Alcatel-Lucent OmniAccess firmware.  They
embedded a certificate (trusted by GeoTrust) and its private key into
the firmware for more than 10 different models of OmniAccess.  This
certificate is in CT logs, and is currently valid until August 11, 2017. 
Issuer is OU "C=US, O=GeoTrust Inc., OU=Domain Validated SSL,
CN=GeoTrust DV SSL CA".
Subject is "serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF, C=US,
O=securelogin.arubanetworks.com, OU=GT28470348, OU=See
www.geotrust.com/resources/cps (c)11, OU=Domain Control Validated -
QuickSSL(R) Premium, CN=securelogin.arubanetworks.com".
Serial number is 121426.

The certificate (and the usual information about it) can be found at
https://censys.io/certificates/47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
.

The private key for the certificate can be found at
https://github.com/sec-consult/houseofkeys/blob/master/certificates/47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534.key
or by pulling the aforementioned github repo.

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.

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

Shipping custom certificate chain whithin Thunderbird

[vfbsilva]

Howdy, I need to deploy Thunderbird to all users of my company. We use a set of 
CA certificate which are not registered in Mozzila as of the current moment. We 
need that upon creation of cert.db on users home our chain whose files are 
presented here: https://ccd.serpro.gov.br/serproacf/opcoes/cadeia.html

I know I could place a new cert.db in every user folder but I would prefer to 
have the installer (in ubuntu) doing it.

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

Re: Incidents involving the CA WoSign

[xcrailfans]

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

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

[1]: 
http://wayback.archive.org/web/20160903185601/https://companycheck.co.uk/company/09744347/STARTCOM-CA-LIMITED/companies-house-data#
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Will Hughes]

Hello,

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

Addressing Mozillas' response to WoSigns' breach:

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

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

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

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

Thank you all for your time,
Will Hughes

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

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

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

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

Re: Incidents involving the CA WoSign

[moonbingbing]

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

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

Re: Incidents involving the CA WoSign

[Julian Brost]

Hi,

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

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

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

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

Regards,
Julian Brost

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

Re: Incidents involving the CA WoSign

[hanyuwei70]

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

So I think it is very important to audit how many certificates mis-issued by 
Wosign. Because this bug is used widely when I am running websites for Wosign 
provide FREE 3 year multi-domain certificates that time. ( We dont have Let's 
encrypt that time and Startcom just issue single domain.)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sanctions short of distrust

[Jakob Bohm]

On 06/09/2016 18:15, Ryan Hurst wrote:

On Tuesday, September 6, 2016 at 7:54:14 AM UTC-7, Jakob Bohm wrote:

On 06/09/2016 16:43, Martin Rublik wrote:

On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm  wrote:


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

IIS for Windows Server 2008 (latest IIS supporting pure 32 bit
configurations): No obvious (if any) OCSP stapling support.



AFAIK IIS 7.0 supports OCSP stapling and it is enabled by default, for more
information see https://unmitigatedrisk.com/?p=95 or
https://www.digicert.com/ssl-support/windows-enable-ocsp-stapling-on-server.htm




Nice surprise (if true), this was unreasonably well hidden, for example
there is no indication of this in any relevant parts of the
administration user interface.  I'll have to device a test to check if
it actually does staple OCSP on our servers.

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


It is true. Windows (and IIS as a result) was the first to support OCSP 
stapling and has the most robust support for it. Sleevi has a nice summary OCSP 
stapling issues here - https://gist.github.com/sleevi/5efe9ef98961ecfb4da8

Lets start a new thread to discuss OCSP stapling vs re-using this one.



As I stated elsewhere, the only point of mentioning OCSP problems in
here was to counter repeated suggestions in this thread that adding
something to stapled OCSP responses would be a viable solution
to dealing with partially distrusted CAs.  I had no intention of
discussing the details of OCSP stapling implementation in this forum.

Enjoy

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

Re: Incidents involving the CA WoSign

[Eddy Nigg]

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

Hi Eddy,

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

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

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


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


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


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


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

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

Re: Sanctions short of distrust

[Ryan Hurst]

On Tuesday, September 6, 2016 at 7:54:14 AM UTC-7, Jakob Bohm wrote:
> On 06/09/2016 16:43, Martin Rublik wrote:
> > On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm  wrote:
> >
> >> Here are a list of software where I have personally observed bad OCSP
> >> stapling support:
> >>
> >> IIS for Windows Server 2008 (latest IIS supporting pure 32 bit
> >> configurations): No obvious (if any) OCSP stapling support.
> >
> >
> > AFAIK IIS 7.0 supports OCSP stapling and it is enabled by default, for more
> > information see https://unmitigatedrisk.com/?p=95 or
> > https://www.digicert.com/ssl-support/windows-enable-ocsp-stapling-on-server.htm
> >
> 
> 
> Nice surprise (if true), this was unreasonably well hidden, for example
> there is no indication of this in any relevant parts of the
> administration user interface.  I'll have to device a test to check if
> it actually does staple OCSP on our servers.
> 
> 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

It is true. Windows (and IIS as a result) was the first to support OCSP 
stapling and has the most robust support for it. Sleevi has a nice summary OCSP 
stapling issues here - https://gist.github.com/sleevi/5efe9ef98961ecfb4da8

Lets start a new thread to discuss OCSP stapling vs re-using this one.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: (Optional) list of participants

[Percy]

Percy Alpha; Researcher on Internet security and censorship in China 
http://percya.com ; CA related stuff: Broke the news on China's large scale 
MITM of Github in 2013, iCloud, Outlook, Yahoo in 2014; victim of Great Cannon 
(hijacking HTTP request) DDOS of the website and Github in 2015; called for 
CNNIC's revocation in 2013; monitored CNNIC's censorship on the news of it 
being revoked in 2015. 

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

___
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

[Percy]

Yeah, it's almost impossible to distrust all WoSign authority manually from
keychain access. WoSign has 28 root certs or intermediate certs signed by
other CAs, listed below. (List from
https://github.com/chengr28/RevokeChinaCerts/wiki/ReadMe_Online#about-certificates
)

Certification Authority of WoSign  WoSign
CA Limited 
B94294BF91EA8FB64BE61097C7FB001359B676CB
CA 沃通根证书  WoSign CA Limited
 1632478D89F9213A92008563F5A4A7D312408AD6
Class 1 Primary CA WoSign CA Limited 
6A174570A916FBE84453EED3D070A1D8DA442829
Certification Authority of WoSign WoSign CA Limited
 33A4D8BC38608EF52EF0E28A35091E9250907FB9
Certification Authority of WoSign G2  WoSign
CA Limited 
FBEDDC9065B7272037BC550C9C56DEBBF27894E1
CA WoSign ECC Root  WoSign CA Limited
 D27AD2BEED94C0A13CC72521EA5D71BE8119F32B
Certification Authority of WoSign StartCom Certification Authority
 868241C8B85AF79E2DAC79EDADB723E82A36AFC3
Certification Authority of WoSign StartCom Certification Authority
 692790DA5189529CC5CE1E16E984277A03023E99
Certification Authority of WoSign StartCom Certification Authority
 804E5FB7DE84F5F5B28347233EAF07846B6070D3
Certification Authority of WoSign StartCom Certification Authority
 B0B68AE97CFE2AFACD0DC2010B9D70ACE593E8A6
Certification Authority of WoSign StartCom Certification Authority
 27D5BBE04301E1604839708D172CF09296ED9033
Certification Authority of WoSign UTN-USERFirst-Object
 7C1913D189C46577D7513F980A2CFD7EDCBA0EC9
Certification Authority of WoSign UTN-USERFirst-Object
 1C1ECDCCF764E6168177C5711F33EC9229A29F88
Certification Authority of WoSign G2 Certum CA 
B39191CFF08EB6FD8B447C21CAAEF6FC33F1D5AE
Certification Authority of WoSign G2 Certum CA 
73FFCA3F815B7A77717FE91912A4DC7B6BFB79CA
CA 沃通根证书 StartCom Certification Authority 
D8EFF6C28BB508E4702565F42748454A872BD412
CA 沃通根证书 StartCom Certification Authority 
CE335662F0EA6764B95C7F50A995A514ACE8C815
CA 沃通根证书 StartCom Certification Authority 
B2FBDA222493A93C38F77C90D4BE6DA17F15F0B0
Certification Authority of WoSign UTN – DATACorp SGC
 56FAADDC596DCF78D585D83A35BC04B690D12736
WoSign Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware 
E3D569137E603E7BACB6BCC66AE943850C8ADF38
WoSign Server Authority AddTrust External CA Root/UTN-USERFirst-Hardware
 3E14B8BD6C568657D852D95D387249AE857B4A39
WoSign SGC Server Authority UTN – DATACorp SGC 
6D5A18050D56BFDE525CBE89E8C45DD1B53D12E9
WoSign Client Authority UTN-USERFirst-Client Authentication and Email
 FAD4319D4E173FF3853E51C98D21919BF3DA1A1E
WoTrust Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware 
381CBC5048AFD9A02D3E5882D5F22D962B1A5F72
WoTrust Premium Server Authority AddTrust External CA
Root/UTN-USERFirst-Hardware 
CF37A5B5C9166BD6B57A56BF67165A584B057241
WoTrust Server Authority AddTrust External CA Root/UTN-USERFirst-Hardware
 337DF96418F08A9355870513AFCEBDC68BCED767
WoTrust SGC Server Authority UTN – DATACorp SGC 
46A762F3C3CF3732DE22A8BA1EBBA3BC048F9B8C
WoTrust Client Authority UTN-USERFirst-Client Authentication and Email
 38CFE78D9F1F0B0637AFCAAA3D5549D87C0AA1D0

Percy Alpha(PGP
)


On Tue, Sep 6, 2016 at 8:19 AM, Peter Gutmann 
wrote:

> Nick Lamb  writes:
>
> >On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann  wrote:
> >> Why would a public CA even need cross-certification from other CAs?
> >
> >Maybe this question has some subtlety to it that I'm missing?
>
> OK, I really meant "that many other CAs".  To take one example, the cross-
> certifying CA known as Usertrust that eventually became part of Comodo has
> been around since the late 1990s, so it's presumably trusted by everything
> under the sun, and then Comodo owns (at least) AddTrust AB, eBiz Networks,
> Positive Software, RegisterFly, Registry Pro, The Code Project, The
> USERTRUST
> Network, WebSpace-Forum e.K., and Wotone Communications.  Getting a whole
> pile
> of other cross-certifications from additional CAs seems a bit redundant,
> and
> has the flipside that once you've got a sufficiently complex mesh of cross-
> certifications you've established 

(Optional) list of participants

[Gervase Markham]

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

Nick Lamb  writes:

>On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann  wrote:
>> Why would a public CA even need cross-certification from other CAs?
>
>Maybe this question has some subtlety to it that I'm missing?

OK, I really meant "that many other CAs".  To take one example, the cross-
certifying CA known as Usertrust that eventually became part of Comodo has
been around since the late 1990s, so it's presumably trusted by everything
under the sun, and then Comodo owns (at least) AddTrust AB, eBiz Networks,
Positive Software, RegisterFly, Registry Pro, The Code Project, The USERTRUST
Network, WebSpace-Forum e.K., and Wotone Communications.  Getting a whole pile
of other cross-certifications from additional CAs seems a bit redundant, and
has the flipside that once you've got a sufficiently complex mesh of cross-
certifications you've established such a level of fault-tolerance that it's
difficult to untrust a CA because there'll always be another cross-
certification somewhere leading to a trusted root.

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

[Nick Lamb]

On Tuesday, 6 September 2016 15:11:00 UTC+1, Peter Gutmann  wrote:
> Why would a public CA even need cross-certification from other CAs?

Maybe this question has some subtlety to it that I'm missing?

Acceptance into root trust stores is slow. Glacial in some cases. Mozilla has a 
published process. Microsoft, Apple and Oracle all say basically "email this 
address with your details" and beyond that all is opaque, other trust stores 
are worse / slower.

Let's Encrypt was announced in 2014, with its intention from the outset being 
to operate as a public CA. The ISRG Root (ISRG is the actual 501(c)3 entity 
behind Let's Encrypt formally) was self-signed in June 2015. In September 2015 
they formally applied to all major root trust stores including Mozilla.

In October 2015 they received a cross-certification from IdenTrust for Let's 
Encrypt Authority X1 (and its backup X2) and soon after began "beta" issuance, 
making real working leaf certificates for the web PKI, obeying the BRs and so 
on, initially for subscribers who had been pre-vetted and then for the general 
public.

By June 2016, with all major root trust stores still deliberating (Mozilla 
publicly, everyone else behind closed doors) Let's Encrypt was one of the 
biggest issuers on the entire World Wide Web. Officially, they were merely a 
subCA of IdenTrust as far as every trust store is concerned. In practice they 
were now bigger than almost all the directly trusted public CAs (Symantec and 
Comodo are bigger by most measures).

In July 2016 Mozilla signalled that future Firefox versions would add ISRG Root 
X1 to their trust store. No word yet from any other major trust store. This is 
not at all unusual.

So, cross signatures are the difference between being able to actually "enter 
the market" in reasonable time and being stalled out essentially indefinitely.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sanctions short of distrust

[Jakob Bohm]

On 06/09/2016 16:43, Martin Rublik wrote:

On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm  wrote:


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

IIS for Windows Server 2008 (latest IIS supporting pure 32 bit
configurations): No obvious (if any) OCSP stapling support.



AFAIK IIS 7.0 supports OCSP stapling and it is enabled by default, for more
information see https://unmitigatedrisk.com/?p=95 or
https://www.digicert.com/ssl-support/windows-enable-ocsp-stapling-on-server.htm




Nice surprise (if true), this was unreasonably well hidden, for example
there is no indication of this in any relevant parts of the
administration user interface.  I'll have to device a test to check if
it actually does staple OCSP on our servers.

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

[Martin Rublik]

On Tue, Sep 6, 2016 at 2:16 PM, Jakob Bohm  wrote:

> Here are a list of software where I have personally observed bad OCSP
> stapling support:
>
> IIS for Windows Server 2008 (latest IIS supporting pure 32 bit
> configurations): No obvious (if any) OCSP stapling support.


AFAIK IIS 7.0 supports OCSP stapling and it is enabled by default, for more
information see https://unmitigatedrisk.com/?p=95 or
https://www.digicert.com/ssl-support/windows-enable-ocsp-stapling-on-server.htm


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

[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 
To: Peter Bowen , Gervase Markham

Cc: Richard Wang ,
"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  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 
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Sanctions short of distrust
Message-ID: 
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: No OCSP stapling 
support in the standard version.

IIS for Windows Server 2008 (latest IIS supporting pure 32 bit
configurations): No obvious (if any) OCSP stapling support.

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

[Jakob Bohm]

On 06/09/2016 15:37, Kurt Roeckx wrote:

On 2016-09-06 14:16, Jakob Bohm wrote:

On 06/09/2016 10:25, Kurt Roeckx wrote:

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.


As far as I know the functions for that are:
https://www.openssl.org/docs/manmaster/ssl/SSL_set_tlsext_status_type.html


  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.


SSL_CTX_add_server_custom_ext() was added in 1.0.2, see
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_add_server_custom_ext.html



Neither of those calls (which I know) provide the lacking
functionality. Specifically, the _tlsext_ OCSP calls require each
server to design and build its own OCSP response acquisition and
caching code.  While the _server_custom_ functions seemingly lack the
functionality to implement multistapling, at least as I read them.



PS: I just found: https://istlsfastyet.com/

This is probably also getting a little off topic.



But yes, the details of OpenSSL are off-topic in this newsgroup, this
was merely two entries in a long list of HTTPS server implementations
that cannot be easily configured to send the OCSP stapling responses
that some other posters suggested would be an appropriate workaround
for half-bad CAs.

The point of the list was simply to explain why requiring OCSP stapling
would not work on the current Internet.



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

[Kurt Roeckx]

On 2016-09-06 14:16, Jakob Bohm wrote:

On 06/09/2016 10:25, Kurt Roeckx wrote:

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.


As far as I know the functions for that are:
https://www.openssl.org/docs/manmaster/ssl/SSL_set_tlsext_status_type.html


  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.


SSL_CTX_add_server_custom_ext() was added in 1.0.2, see 
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_add_server_custom_ext.html


PS: I just found: https://istlsfastyet.com/

This is probably also getting a little off topic.


Kurt

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

Re: Sanctions short of distrust

[Jakob Bohm]

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: No OCSP 
stapling support in the standard version.


IIS for Windows Server 2008 (latest IIS supporting pure 32 bit 
configurations): No obvious (if any) OCSP stapling support.





Enjoy

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

Re: Incidents involving the CA WoSign

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

[Kurt Roeckx]

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.



Kurt

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

Re: Sanctions short of distrust

[Nick Lamb]

On Tuesday, 6 September 2016 08:31:33 UTC+1, Kurt Roeckx  wrote:
> I would really like to see OCSP stapling as mandatory. There currently 
> only seem to be around 25% of the servers that do it, and the progress 
> seem to be very slow. I'm wondering if there is something we can do so 
> that it's used more.

We see a small but significant fraction of servers where if they enable OCSP 
stapling everything breaks because their server isn't permitted to access the 
OCSP server (usually a well-intentioned firewall rule forbidding outbound TCP 
connections to the Internet from the web server) and it staples the resulting 
error to the certificate, then browsers reject the resulting unverified 
certificate.

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.

I would also be more enthusiastic about multi-stapling than the original 
stapling, since I get the impression that all too often any problems aren't 
with the leaf certificate's OCSP response but with an intermediate, and so 
stapling only the response for the leaf won't help there.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sanctions short of distrust

[Kurt Roeckx]

On 2016-09-05 17:55, Jakob Bohm wrote:

Indeed, I have found that a number of common web server implementations
simply lack the ability to do OCSP stapling at all.


I would really like to see OCSP stapling as mandatory. There currently 
only seem to be around 25% of the servers that do it, and the progress 
seem to be very slow. I'm wondering if there is something we can do so 
that it's used more.


About the only idea I have is to do something with TLS 1.3, like if you 
have a non self-signed certificate OCSP stapling is mandatory. But I 
don't see that working out.



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