Re: Cerificate Concern about Cloudflare's DNS

[Matt Palmer]

On Sat, Sep 17, 2016 at 04:38:50PM +0200, Florian Weimer wrote:
> * Peter Bowen:
> 
> > On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei  wrote:
> >> So when I delegated the DNS service to Cloudflare, Cloudflare have
> >> the privilege to issue the certificate by default? Can I understand
> >> like that?
> >
> > I would guess that they have a clause in their terms of service or
> > customer agreement that says they can update records in the DNS zone
> > and/or calls out that the subscriber consents to them getting a
> > certificate for any domain name hosted on CloudFlare DNS.
> 
> I find it difficult to believe that the policies permit Cloudflare's
> behavior, but are expected to prevent the issue of interception
> certificates.  Aren't they rather similar, structurally?

I'm not seeing any similarity, but I don't understand your use of
"structurally", so if you could expand on your meaning, that would be
useful.

- Matt

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

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Peter Bowen]

On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson  wrote:
> This request from Guangdong Certificate Authority (GDCA) is to include the 
> "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit, and 
> enabled EV treatment.
>
> * CA Hierarchy: This root certificate has internally-operated subordinate CAs
> - GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs)
> - GDCA TrustAUTH R4 Generic CA (issues 2048-bit individual certs)
> - GDCA TrustAUTH R4 CodeSigning CA (issues 2048-bit CodeSigning certs)
> - GDCA TrustAUTH R4 Extended Validation SSL CA (issues 2048-bit EV SSL certs)
> - GDCA TrustAUTH R4 Extended Validation Code Signing CA (issues 2048-bit EV 
> CodeSigning certs)
>
> * Audit: Annual audits are performed by PricewaterhouseCoopers Zhong Tian LLP 
> according to the WebTrust criteria.
> WebTrust CA: https://cert.webtrust.org/SealFile?seal=2024=pdf
> WebTrust BR: https://cert.webtrust.org/SealFile?seal=2025=pdf
> WebTrust EV: https://cert.webtrust.org/SealFile?seal=2026=pdf

Kathleen and team,

I reviewed the annual audit reports linked in your email, including
the auditor's opinion and the management assertions.

Good:
- The reports and management assertion include an English language version
- The English versions are authoritative (no qualification the Chinese
language version holds in case of conflict)
- The reports clearly state they use the International Standard on
Assurance Engagements (ISAE) 3000 standard
- The report and assertion use the current version of the criteria
- The assertions include details of each CA in the appendix, including
an indication of whether it is a Root CA and a cryptographic hash
(fingerprint) associated with each CA

Opportunties for Improvement:
- The basic WebTrust Report and assertion do not specify location(s)
where services are provided.  Other reports do indicate the services
are provided in/from China.
- The opinions do not specify the list of Certification Authorities in scope
- The reports and asssertions do not specify the versions of the CP and CPS
- The management assertion appendixes mix keys and certificates.  The
certificate is not the interesting part; the CA Distinguished Name
(DN), type (Root or not), Key, and Key ID are the interesting parts.
- The BR report repeats a bullet under "Maintained effective controls
to provide reasonable assurance that:"

Bad:
- The basic WebTrust for CA Report does not cover controls that
provide assurance that subordinate CA certificate requests are
accurate, authenticated, and approved (the management assertion does,
so this indicates the auditor might have found issues with the
controls)
- The basic WebTrust for CA Management assertion does not include
Subordinate CA [cross-]certification in the list of CA services
- The basic WebTrust for CA  Management assertion does not include
"Subordinate CA Certificate Lifecycle Management Controls" in the list
of portions of criteria used
- After the reporting period ended, GDCA issued at least two new
subordinate CA certificates from the R5 root.  These use the
organization name of "Global Digital Cybersecurity Authority Co.,
Ltd." and have keys and key IDs that are identical to those found in
CA certificates for GUANG DONG CERTIFICATE AUTHORITY CO.,LTD.  This is
problematic as re-use of key IDs with different issuer names causes
problems on some platforms.  Additionally the separate DN means it is
out of scope for the submitted report.  Combined with the lack of
audited controls around subordinate CA management, CAs outside of the
scope of the report may be a significant concern.
- The Baseline + Network Security Requirements report and management
assertion only covers two of the CAs.  However the cross-certs issued
by the root to the subordinate CAs do not include EKU constraints, so
the subordinate CAs are capable of issuing server authentication
("SSL") certificates.  The assertion and report should include all CAs
that are capable of issuing ser authentication certificates.
- The Baseline report does not provide an option that GDCA "maintained
effective controls to provide reasonable assurance that it meets the
Network and Certificate System Security Requirements as set forth by
the CA/Browser Forum"
- The Extended Validation report and management assertion attempts to
merge the Extended Validation SSL and Extended Validation Code Signing
criteria.  These should be distinct reports.  As writtten, the report
fails to adequately cover the EVCS critera.

The WebTrust/PKI Task Force has published a draft set of illustrative
reports to use as a basis
(http://www.webtrust.org/practitioner-qualifications/item83253.pdf),
so it should be faily easy to resolve the missing bits.

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

Re: Cerificate Concern about Cloudflare's DNS

[Patrick Figel]

On 17/09/16 16:38, Florian Weimer wrote:
> * Peter Bowen:
> 
>> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei 
>> wrote:
>>> So when I delegated the DNS service to Cloudflare, Cloudflare 
>>> have the privilege to issue the certificate by default? Can I 
>>> understand like that?
>> 
>> I would guess that they have a clause in their terms of service or 
>> customer agreement that says they can update records in the DNS 
>> zone and/or calls out that the subscriber consents to them getting
>> a certificate for any domain name hosted on CloudFlare DNS.
> 
> I find it difficult to believe that the policies permit Cloudflare's 
> behavior, but are expected to prevent the issue of interception 
> certificates.  Aren't they rather similar, structurally?

I don't see how they're similar. Interception certificates are issued
without the knowledge and permission of the domain owner. Someone
signing up for CloudFlare willingly chooses to trust a CDN provider with
all their web traffic and DNS (in order to enable CloudFlare for a
domain, the NS record for that domain needs to point to CloudFlare.)

I could understand this argument if they'd somehow pretend to be a
DNS-only provider and then abuse that to issue certificates. However,
nothing about their site (or their marketing approach in general) gives
me that impression - it's made quite clear that they're primarily a CDN
with SSL support.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Florian Weimer]

* Peter Bowen:

> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei  wrote:
>> So when I delegated the DNS service to Cloudflare, Cloudflare have
>> the privilege to issue the certificate by default? Can I understand
>> like that?
>
> I would guess that they have a clause in their terms of service or
> customer agreement that says they can update records in the DNS zone
> and/or calls out that the subscriber consents to them getting a
> certificate for any domain name hosted on CloudFlare DNS.

I find it difficult to believe that the policies permit Cloudflare's
behavior, but are expected to prevent the issue of interception
certificates.  Aren't they rather similar, structurally?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Florian Weimer]

* Ben Laurie:

> On 10 September 2016 at 15:43, Erwann Abalea  wrote:
>> Ironically, since you're not the Subscriber, you cannot request for
>> the revocation of this certificate, at least not directly to the
>> CA. If you want this certificate to be revoked, you need to ask
>> Cloudflare.
>
> Surely not? The BRs say (4.9.2):
>
> "The Subscriber, RA, or Issuing CA can initiate revocation.
> Additionally, Subscribers, Relying Parties, Application Software
> Suppliers, and other third parties may submit Certificate Problem
> Reports informing the issuing CA of reasonable cause to revoke the
> certificate."

This is fairly new.  Third-party revocation requests are very tricky
to process promptly.  For many (most?) interesting certificates, the
guaranteed damage from an immediate revocation outweighs the risk from
a potential man-in-the-middle attack enabled by the compromised
certificate.

Back in 2008, most CAs flat out refused to revoke certificates even
though there was proof that the private key has been compromised.  A
very small-scale repeat exercise showed that this is no longer the
case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: WoSign Issue L and port 8080

[Florian Weimer]

* Nick Lamb:

> On Sunday, 11 September 2016 21:05:12 UTC+1, Lee  wrote:
>> does dns hijacking or dns cache poisoning count as mitm?
>
> A careful CA validator does DNS only by making authoritative queries,
> so they're not subject to cache poisoning since they don't look at
> cached answers.

I'm not sure if you can resolve all domains without some sort of DNS
cache, in the sense that you never use data from one answer to satisfy
more than one query (which can be internally generated).

More reasonable would be to require that the resolver starts with a
cold cache (possibly preloaded with a copy of the root zone) and
performs DNSSEC validation starting with the IANA keys.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Is Firefox SHA-1 Deprecation Policy configurable?

[sjw]

I think that's the security.pki.sha1_enforcement_level pref [1][2].

Regards,
Jonas


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=942515#c35
[2]
https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-interfering-with-increased-security/



Am 16.09.2016 um 16:53 schrieb therickf...@gmail.com:
> Working with a client on "workarounds" for avoiding SHA-1 deprecation on a 
> system they are woefully behind on updating for SHA-256 compatible.  They 
> asked/stated that Chrome & probably Firefox were "configurable" in regards to 
> shutting out the trust for SHA-1 SSL/TLS certs. I'm skeptical as I haven't 
> seen anything like that.   
>
> Is there any configurability in Firefox regarding this (e.g. from a GPO 
> perspective - Windows environment), or is all the SHA-1 deprecation policy 
> embedded in the Firefox code - to be enforced when that update is pushed out 
> (presumably on/around 1/1/17)? Thanks
>
> Rick
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy