Re: Cerificate Concern about Cloudflare's DNS

[Itzhak Daniel]

On Sunday, November 6, 2016 at 12:11:43 AM UTC+2, Ryan Sleevi wrote:
> Can you tell me where that clause indicates that they should use the Alexa 
> Top 1 million to consider a request "High Risk"?

It doesn't, "High risk" is left for the CA's interpretation. But after the fact 
you can say that they failed to identify a "High risk" request with their 
current state of their system and they SHOULD be required to update it (to 
avoid future requests to pass for the specific domain in question), and they 
MAY need to make their system more robust to identify other "High risk" 
requests and not just acting after the fact.

Alexa top ~1000 is a good indicator for requests that should be considered as 
"High risk" [1] [2], especially in a free tier service.

Links:
1. https://github.com/certbot/certbot/issues/47#issuecomment-64060616
2. https://community.letsencrypt.org/t/name-is-blacklisted-on-renew/9012/19
___
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

[Ryan Sleevi]

On Saturday, November 5, 2016 at 2:54:05 PM UTC-7, Itzhak Daniel wrote:
 > (to my understanding) They did violate a "SHALL" guideline:
> 
> "The CA SHALL develop, maintain, and implement documented procedures that
> identify and require additional verification activity for High Risk 
> Certificate
> Requests prior to the Certificate’s approval, as reasonably necessary to 
> ensure
> that such requests are properly verified under these Requirements."
> 
> I don't recall if they automatically approved or manually approved it by 
> mistake (the operator wasn't familiar with Alibaba).
> 
> alicdn.com is ranked 760 in Alexa top 1 million, and requests for this domain 
> should be considered "high risk":
> 
> CMD$ wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip;gzip -cd 
> top-1m.csv.zip|grep alicdn.com

Can you tell me where that clause indicates that they should use the Alexa Top 
1 million to consider a request "High Risk"?

This is a known, and well understood, issue with the clause - it is perfectly 
acceptable from the BRs, and therefore, at present, the Mozilla policy, to 
state that "We consider any requests for the domain example.com as 'High Risk', 
and all other domains shall not be considered as such"

What's required is they have a policy, and document the policy, and follow the 
policy. That's it. Is that ideal? No. But is that what it says? Absolutely. CAs 
and Browsers have been discussing this nuance for several years now, but 
certainly, at the time it happened, and to this present day, it means the above.
___
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

[Itzhak Daniel]

On Friday, November 4, 2016 at 12:18:40 PM UTC+2, Gervase Markham wrote:
> ... But because WoSign had done the appropriate domain control checks,
> we did not consider this a mistake by WoSign.

(to my understanding) They did violate a "SHALL" guideline:

"The CA SHALL develop, maintain, and implement documented procedures that
identify and require additional verification activity for High Risk Certificate
Requests prior to the Certificate’s approval, as reasonably necessary to ensure
that such requests are properly verified under these Requirements."

I don't recall if they automatically approved or manually approved it by 
mistake (the operator wasn't familiar with Alibaba).

alicdn.com is ranked 760 in Alexa top 1 million, and requests for this domain 
should be considered "high risk":

CMD$ wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip;gzip -cd 
top-1m.csv.zip|grep alicdn.com


___
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

[Gervase Markham]

Hi Gerhard,

I realise you are upset with what Cloudflare has been doing, but having
considered the matter, I think the bottom line is that the only
reasonable position for Mozilla to take is "issuances which perform a
valid domain control check are OK". We can't go policing the terms of
service of every cloud provider and ISP.

To take a recent example, one of the issues raised against WoSign was
that they had "mis-issued" a cert for alicdn.com. The cert was not
requested by alicdn.com's management but by an attacker who had briefly
obtained the ability to control content on the domain. But because
WoSign had done the appropriate domain control checks, we did not
consider this a mistake by WoSign.

It therefore follows that if you don't want people issuing certs for
your domain, don't give them control over either your DNS, your WHOIS,
your server, or the content of your website.

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

[Jakob Bohm]

On 04/11/2016 07:01, Nigel Jones wrote:

On 11/09/2016 12:37 AM, Han Yuwei wrote:

I am using Cloudflare's DNS service and I found that Cloudflare has
issued a certficate to their server including my domain. But I didn't
use any SSL service of theirs. Is that ok to Mozilla's policy?

Issued certificate:https://crt.sh/?id=31206531
My domain is BUPT.MOE



I'm just going to reply to the top of the thread because it addresses
something said in multiple places now.

Is it allowed? Surely yes.

From: https://www.cloudflare.com/plans/

"Free Includes... These great features:

* ...
* Shared SSL Certificate
* ..."

IMO it doesn't need to be in the Ts because it says right on the box
that an SSL certificate is included with your plan.



Great find.


Should Cloudflare allow an opt-out?  Maybe, but that seems to be a
feature/enhancement request rather than a problem.  (Rob's case with
crt.sh is an example where an opt-out would be a good thing)

- N


The following issues reported by others remain:

1. The shared SSL certificate is generated even if only the DNS part of
  the plan is used.

2. The shared SSL certificate is generated even if a custom SSL
  certificate is uploaded.

3. Some say the custom SSL certificate is not revoked when the
  CloudFlare subscription/contract is ended by the subscriber.

4. Some posters think the CA has no obligation to revoke such
  after-contract-ended certificates, even though the BRs clearly state
  that the CA must do so if made aware that the "service agreement"
  allowing the issuance has been terminated.




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: Cerificate Concern about Cloudflare's DNS

[Matt Palmer]

On Thu, Nov 03, 2016 at 03:39:11PM -0700, gerhard.tin...@gmail.com wrote:
> On Thursday, November 3, 2016 at 11:23:18 PM UTC+1, Matt Palmer wrote:
> > On Thu, Nov 03, 2016 at 02:08:04PM -0700, gerhard.tin...@gmail.com wrote:
> > > Sadly, the shady behaviour is not with Comodo but with Cloudflare. As
> > > cloudflare does not state anywhere that they issue certificates when SSL
> > > and CDN features are explicitly switched off from the beginning.
> > 
> > They do state it: in a blog post from 2014.  They appear to believe this is
> > sufficient notice.
> 
> Well a blog post is not a TOS or a security policy. But maybe in some far
> away country it is accepted.  Any way, can you send me the link to that
> post??

https://blog.cloudflare.com/introducing-universal-ssl/

> > > 1. trust issue: Cloudflare issues certificates without asking permission
> > > or staing it in TOS or elsewhere.  Doing so when in DNS-only mode appears
> > > to me illegal.
> > 
> > Illegal?  In which jurisdiction(s)?
> 
> Well, If you buy a VPS and the provider creates a certificate by
> validating by adding content to your webserver, ...  we would agree that
> this is wrong, right?

It would depend on the circumstances.  However that is not what happened.

> But when I get a service to host MY DNS entries, it
> is fine if the provider manipulates them without my knowledge?  ...  But I
> have noticed that in some countries the understanding of legal and iligal
> is different.  Sad.

Which country or countries (or other legal jurisdiction) has an
understanding that Cloudflare's behaviour as described in this thread is
illegal?  You've made a fairly specific claim, I would be interested to see
the rationale for it.

> > > 2. trust issue: Cloudflare modifies the DNS entries to validate without
> > > consent of the domain owner or account holder.  Again, no mention of it in
> > > TOS or anywheer else.  So the modification is not permitted in DNS-only
> > > mode.
> > 
> > So go tell Cloudflare.  Take your business elsewhere.
> 
> I understand, go and just lieve with a certificate that is issued without
> my permission.  It seems that CT is useless if there are no actions are
> taken from wrong behaviour.

There are actions taken for wrong behaviour.  It's just that not every wrong
behaviour results in the same action.

I'm actually interested in what specific action you think should be taken
here, and how keeping on about it on this list will help that action to
occur.  Please, state exactly what you think should be done.

> > There is no need to keep banging on about it on this list.  Everyone here
> > knows what Cloudflare is doing, they have their opinion of it, and as a
> > group this list can do nothing about it.
> > 
> > > But from the moment on when the CA (Comodo) is informed about this shady
> > > behavior by multiple domain owners / account owners, Comodo should start
> > > acting.
> > 
> > As the Wikipedians say: "Citation Needed".
> > 
> > - Matt
> 
> Still sad that wrong behaviour of companies that trick CAs into issuing
> certificates

What trickery was involved with the CA?  Comodo requires proof of control
over the domain to issue a certificate.  $DEITY knows there are enough
perfectly legitimate reasons to look askance at Comodo, but this isn't one
of them.

Cloudflare demonstrated the required domain control to Comodo, because YOU
GAVE CONTROL TO CLOUDFLARE.  Cloudflare may well have acted in bad faith, by
taking an action you deemed unexpected or illegitimate, however that isn't
something that a browser vendor or root store program can do anything about. 

- Matt

___
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

[gerhard . tinned]

On Thursday, November 3, 2016 at 11:23:18 PM UTC+1, Matt Palmer wrote:
> On Thu, Nov 03, 2016 at 02:08:04PM -0700, gerhard.tin...@gmail.com wrote:
> > Sadly, the shady behaviour is not with Comodo but with Cloudflare. As
> > cloudflare does not state anywhere that they issue certificates when SSL
> > and CDN features are explicitly switched off from the beginning.
> 
> They do state it: in a blog post from 2014.  They appear to believe this is
> sufficient notice.

Well a blog post is not a TOS or a security policy. But maybe in some far away 
country it is accepted. Any way, can you send me the link to that post??

> 
> > 1. trust issue: Cloudflare issues certificates without asking permission
> > or staing it in TOS or elsewhere.  Doing so when in DNS-only mode appears
> > to me illegal.
> 
> Illegal?  In which jurisdiction(s)?

Well, If you buy a VPS and the provider creates a certificate by validating by 
adding content to your webserver, ... we would agree that this is wrong, right? 
But when I get a service to host MY DNS entries, it is fine if the provider 
manipulates them without my knowledge? ... But I have noticed that in some 
countries the understanding of legal and iligal is different. Sad.

> 
> > 2. trust issue: Cloudflare modifies the DNS entries to validate without
> > consent of the domain owner or account holder.  Again, no mention of it in
> > TOS or anywheer else.  So the modification is not permitted in DNS-only
> > mode.
> 
> So go tell Cloudflare.  Take your business elsewhere.

I understand, go and just lieve with a certificate that is issued without my 
permission. It seems that CT is useless if there are no actions are taken from 
wrong behaviour.

> 
> There is no need to keep banging on about it on this list.  Everyone here
> knows what Cloudflare is doing, they have their opinion of it, and as a
> group this list can do nothing about it.
> 
> > But from the moment on when the CA (Comodo) is informed about this shady
> > behavior by multiple domain owners / account owners, Comodo should start
> > acting.
> 
> As the Wikipedians say: "Citation Needed".
> 
> - Matt

Still sad that wrong behaviour of companies that trick CAs into issuing 
certificates is protected by "go away!" comments. I would have expected more. 

And as this thread shows, I am not alone.


___
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

[gerhard . tinned]

On Thursday, November 3, 2016 at 1:23:48 PM UTC+1, Rob Stradling wrote:
> On 03/11/16 12:13, Han Yuwei wrote:
> > 在 2016年11月3日星期四 UTC+8下午7:09:48，Rob Stradling写道：
> >> On 03/11/16 09:59, Gervase Markham wrote:
> >>> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
>  Befor I contacted this group, I contacted Cloudflare and asked them
>  to stop creating certificates with my domain. The answer in short
>  was, ... they cannot change it and as long as I am using there
>  service, they will continue.
> >>>
> >>> How would you expect the service to work without them doing that?
> >>>
>  I also contacted Comodo as the CA and asked them. The answer was
>  different but also not helping. In short, ... I can use a CAA DNS
>  record (not supported by many DNS providers like Cloudflare) to avoid
>  it in the future. But in the next sentence telling me that those
>  records are not honoured by many CA's.
> >>>
> >>> Hopefully this will change before too long.
> >>>
> >>> However, I still don't get why you want to use Cloudflare's SSL
> >>> termination services but are unwilling to allow them to get a
> >>> certificate for your domain name.
> >>>
> >>> AIUI their free tier uses certs they obtain, but if you pay, you can
> >>> provide your own cert. So if you want to use Cloudflare but don't want
> >>> them obtaining certs for you, join the paying tier.
> >>
> >> In my experience, joining Cloudflare's paying tier doesn't guarantee
> >> that Cloudflare won't also obtain a free cert.
> >>
> >> A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
> >> tier from the start, and we uploaded an EV cert straight away.  I was
> >> surprised when https://crt.sh/atom?q=crt.sh alerted me to
> >> https://crt.sh/?id=42619974
> >>
> >> -- 
> >> Rob Stradling
> >> Senior Research & Development Scientist
> >> COMODO - Creating Trust Online
> > 
> > So it is impossible to request a revocation even I do refuse to let 
> > Cloudflare issue the certificate of my domain and keep using Cloudflare's 
> > DNS service under these rules(CA/B BR and COMODO CPS)?
> 
> Comodo does check CAA records, so you could add a CAA record for your
> domain that doesn't permit Comodo to issue.  This won't stop Cloudflare
> from requesting a free cert, but it should block the issuance of any
> requested cert.  (Note however that our CAA checks fail open if there's
> an error with the CAA DNS lookup).
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online

This seems to be the standard answer from Comodo. Conveniently Cloudflare does 
not support CAA records. So this suggestion is not helping with Cloudflare.

___
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

[gerhard . tinned]

On Thursday, November 3, 2016 at 10:59:53 AM UTC+1, Gervase Markham wrote:
> On 02/11/16 23:26, wrote:
> > Befor I contacted this group, I contacted Cloudflare and asked them
> > to stop creating certificates with my domain. The answer in short
> > was, ... they cannot change it and as long as I am using there
> > service, they will continue.
> 
> How would you expect the service to work without them doing that?
> 
> > I also contacted Comodo as the CA and asked them. The answer was
> > different but also not helping. In short, ... I can use a CAA DNS
> > record (not supported by many DNS providers like Cloudflare) to avoid
> > it in the future. But in the next sentence telling me that those
> > records are not honoured by many CA's.
> 
> Hopefully this will change before too long.
> 
> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.
> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.
> 
> Gerv

Hi, 

I guess you never used Cloudflare, right? So let me explain it to you so you 
understand my concern. I have posted my whole explanation to this group but it 
is somewhere lost I think. 

1.) Yes, Cloudflare offers a kind of MITM as a service. You dont have a 
certificate, you want there protection, ... etc. So they create it for you, 
intercept and cache the traffic.

2.) Cloudflare does offer much more. beside other things you can disable all 
those features and use cloudflare as "DNS-only mode" as they call it. This 
means the SSL option is switched of by the user. (my expectation would be that 
there are no ssl certificates issued for my domain in that mode.

Now, knowing that, I get back to your questions:

> How would you expect the service to work without them doing that?

As far as I understand aDNS-only service, a SSL certificate is not required. My 
expectation would be that Cloudflare honers the settings I set on the 
account/domain.

> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.

Again, I sue Cloudflare in the DNS-only mode. All the features (except DNS) is 
disabled. SSL: OFF, Intercepting traffic: OFF, ...

> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.

As far as I understood you can even upload the cert in the free plan, but 
beside the point. DNS-Only mpde would not require it.


I would have at least expected that they stop issuing certificates after I 
requested it. But they dont!
___
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

[Rob Stradling]

On 03/11/16 14:18, Jakob Bohm wrote:
> On 03/11/2016 12:09, Rob Stradling wrote:
> 
>> In my experience, joining Cloudflare's paying tier doesn't guarantee
>> that Cloudflare won't also obtain a free cert.
>>
>> A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
>> tier from the start, and we uploaded an EV cert straight away.  I was
>> surprised when https://crt.sh/atom?q=crt.sh alerted me to
>> https://crt.sh/?id=42619974
> 
> So I guess you haven't added your own domains (such as crt.sh) to the
> list of "high-value manual review" domains for your own certificate
> issuance processes?

So it would seem.

-- 
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: Cerificate Concern about Cloudflare's DNS

[Jakob Bohm]

On 03/11/2016 12:09, Rob Stradling wrote:


In my experience, joining Cloudflare's paying tier doesn't guarantee
that Cloudflare won't also obtain a free cert.

A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
tier from the start, and we uploaded an EV cert straight away.  I was
surprised when https://crt.sh/atom?q=crt.sh alerted me to
https://crt.sh/?id=42619974



So I guess you haven't added your own domains (such as crt.sh) to the
list of "high-value manual review" domains for your own certificate
issuance processes?

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: Cerificate Concern about Cloudflare's DNS

[Rob Stradling]

On 03/11/16 12:13, Han Yuwei wrote:
> 在 2016年11月3日星期四 UTC+8下午7:09:48，Rob Stradling写道：
>> On 03/11/16 09:59, Gervase Markham wrote:
>>> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
 Befor I contacted this group, I contacted Cloudflare and asked them
 to stop creating certificates with my domain. The answer in short
 was, ... they cannot change it and as long as I am using there
 service, they will continue.
>>>
>>> How would you expect the service to work without them doing that?
>>>
 I also contacted Comodo as the CA and asked them. The answer was
 different but also not helping. In short, ... I can use a CAA DNS
 record (not supported by many DNS providers like Cloudflare) to avoid
 it in the future. But in the next sentence telling me that those
 records are not honoured by many CA's.
>>>
>>> Hopefully this will change before too long.
>>>
>>> However, I still don't get why you want to use Cloudflare's SSL
>>> termination services but are unwilling to allow them to get a
>>> certificate for your domain name.
>>>
>>> AIUI their free tier uses certs they obtain, but if you pay, you can
>>> provide your own cert. So if you want to use Cloudflare but don't want
>>> them obtaining certs for you, join the paying tier.
>>
>> In my experience, joining Cloudflare's paying tier doesn't guarantee
>> that Cloudflare won't also obtain a free cert.
>>
>> A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
>> tier from the start, and we uploaded an EV cert straight away.  I was
>> surprised when https://crt.sh/atom?q=crt.sh alerted me to
>> https://crt.sh/?id=42619974
>>
>> -- 
>> Rob Stradling
>> Senior Research & Development Scientist
>> COMODO - Creating Trust Online
> 
> So it is impossible to request a revocation even I do refuse to let 
> Cloudflare issue the certificate of my domain and keep using Cloudflare's DNS 
> service under these rules(CA/B BR and COMODO CPS)?

Comodo does check CAA records, so you could add a CAA record for your
domain that doesn't permit Comodo to issue.  This won't stop Cloudflare
from requesting a free cert, but it should block the issuance of any
requested cert.  (Note however that our CAA checks fail open if there's
an error with the CAA DNS lookup).

-- 
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: Cerificate Concern about Cloudflare's DNS

[Rob Stradling]

On 03/11/16 09:59, Gervase Markham wrote:
> On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
>> Befor I contacted this group, I contacted Cloudflare and asked them
>> to stop creating certificates with my domain. The answer in short
>> was, ... they cannot change it and as long as I am using there
>> service, they will continue.
> 
> How would you expect the service to work without them doing that?
> 
>> I also contacted Comodo as the CA and asked them. The answer was
>> different but also not helping. In short, ... I can use a CAA DNS
>> record (not supported by many DNS providers like Cloudflare) to avoid
>> it in the future. But in the next sentence telling me that those
>> records are not honoured by many CA's.
> 
> Hopefully this will change before too long.
> 
> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.
> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.

In my experience, joining Cloudflare's paying tier doesn't guarantee
that Cloudflare won't also obtain a free cert.

A few weeks ago we moved crt.sh onto Cloudflare.  It was in the paying
tier from the start, and we uploaded an EV cert straight away.  I was
surprised when https://crt.sh/atom?q=crt.sh alerted me to
https://crt.sh/?id=42619974

-- 
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: Cerificate Concern about Cloudflare's DNS

[Patrick Figel]

On 03/11/16 10:59, Gervase Markham wrote:
> However, I still don't get why you want to use Cloudflare's SSL
> termination services but are unwilling to allow them to get a
> certificate for your domain name.
> 
> AIUI their free tier uses certs they obtain, but if you pay, you can
> provide your own cert. So if you want to use Cloudflare but don't want
> them obtaining certs for you, join the paying tier.

It is possible to use Cloudflare as a DNS-only provider, without any
CDN/reverse proxying functionality. That's what seems to be the issue
here - certificates are requested as soon as a domain is added to
Cloudflare, even if the CDN functionality is never enabled.

I don't think these certificates are mis-issued or that this practice is
shady, but I can see how it might surprise a domain owner who is only
looking for a DNS provider.

This is probably not something that can or should be resolved by the
CA/B Forum or Mozilla. Realistically speaking, asking CAs to confirm
that the actual domain registrant has authorized the issuance (rather
than whoever is operating the DNS for that domain) is not possible in
practice for DV. Going overboard with such a requirement carries the risk

The only other thing the BRs could ask for is that a subscriber (which
would be Cloudflare in this case) has to include language regarding
certificate issuance in their ToS if they act on behalf of other domain
registrants. However, given that the goal is to avoid surprising the
domain registrant, adding yet another section to a typical ToS document
is hardly going to change anything.

I don't think it's worth optimizing for the "I trust someone to host my
entire DNS zone and hold my DNSSEC keys (if you're into that kind of
thing) but TLS certificates? Boo!"-use-case.
___
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

[Gervase Markham]

On 02/11/16 23:26, gerhard.tin...@gmail.com wrote:
> Befor I contacted this group, I contacted Cloudflare and asked them
> to stop creating certificates with my domain. The answer in short
> was, ... they cannot change it and as long as I am using there
> service, they will continue.

How would you expect the service to work without them doing that?

> I also contacted Comodo as the CA and asked them. The answer was
> different but also not helping. In short, ... I can use a CAA DNS
> record (not supported by many DNS providers like Cloudflare) to avoid
> it in the future. But in the next sentence telling me that those
> records are not honoured by many CA's.

Hopefully this will change before too long.

However, I still don't get why you want to use Cloudflare's SSL
termination services but are unwilling to allow them to get a
certificate for your domain name.

AIUI their free tier uses certs they obtain, but if you pay, you can
provide your own cert. So if you want to use Cloudflare but don't want
them obtaining certs for you, join the paying tier.

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

Re: [FORGED] Re: Cerificate Concern about Cloudflare's DNS

[gerhard . tinned]

On Wednesday, November 2, 2016 at 11:34:44 PM UTC+1, Peter Gutmann wrote:
> Tom Ritter  writes:
> 
> >There's been (some) mention that even if a user moves off Cloudflare, the CA
> >is not obligated to revoke.
> 
> Would it matter?  I guess it depends on circumstances (whether you control the
> private key or Cloudflare does, whether you intend to use the same domain
> elsewhere or not, etc), but in most cases it seems like no revocation is
> necessary, you destroy or stop using the private key and that's it.  

That is exactly the point of it, the "domain owner" / "Cloudflare customer" 
does not have or ever get the key of the certificate that was created without 
the knowledge of the domain owner. And Cloudflare will continue using the 
wildcard certificate with a number of domains in them. Oh, and they are valid 
for 2 years!

> Even in
> the worst-case scenario, Cloudflare has your private key and you intend to
> keep using the domain, presumably there's some contractual obligation for them
> to stop using it when you close your account with them.  It seems like a
> revocation isn't necessary (not just for this but for pretty much every
> revocation reason except keyCompromise).
> 
> 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

[gerhard . tinned]

On Wednesday, November 2, 2016 at 11:39:09 PM UTC+1, Peter Kurrasch wrote:
> This raises an interesting point and I'd be interested in any comments ‎that 
> Comodo or other CA's might have.
> 
> 
> It appears we have a situation where a cert is being issued to what is 
> presumably an authorized party yet that party is not actually authorized by 
> the subscriber. How does Comodo or any other CA validate that a "domain 
> manipulator" has been and continues to be authorized by the actual domain 
> registrant? Is any attestation provided by a party (such as CloudFlare) that 
> they have authorization by their own clients to do whatever they are doing?
> 
> 
> It's in the interest of CA's to ‎have some well thought-out plans here 
> because I think we know who is getting the blame when the system breaks down. 
> I don't think it would sit well if a CA were to come here and say "you can't 
> blame us for the misissuance because we will give CloudFlare any cert they 
> want."
> 
>   
> > 
>   
> > 
>   >   
> From: gerhard...@gmail.com
> Sent: Wednesday, November 2, 2016 4:16 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Cerificate Concern about Cloudflare's DNS
> 
> 
> Hi, 
> 
> > 
> > Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> > them to perform this certificate request on your behalf.
> > 
> > 
> This is where I strongly disagree! I have checked the TOS and Security 
> policy, ... etc. There is nowhere stated that Cloudflare is allowed without 
> the Users knowledge to manipulate there DNS settings. That sad, there is the 
> proxy service they offer which is changing the DNS settings. But as you 
> actively enable it, you are aware. 
> 
> By delegating the DNS server to Cloudflare, you entrust Cloudflare to 
> distribute the User defined DNS settings. To be able to validate for the 
> certificate, the DNS settings are changed without the users knowledge. No TOS 
> or any other policy states this. 
> 
> Even if that might not be issue for the CA itself (which i do not agree on), 
> This is definitely braking the trust to its users.
> 
> And the CA (Comodo) informed about it, and not at least requesting a 
> statement from Cloudflare, means they support this, from my point of view, 
> wrong behavior.
> 
> 
> As it seems the only thing that can be done is move to a different DNS 
> provider!! Still, this is a vialation of trust!!!
> 
> ___
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Thank you. I could not agree more.

Befor I contacted this group, I contacted Cloudflare and asked them to stop
creating certificates with my domain. The answer in short was, ... they cannot
change it and as long as I am using there service, they will continue.

I also contacted Comodo as the CA and asked them. The answer was different but
also not helping. In short, ... I can use a CAA DNS record (not supported by
many DNS providers like Cloudflare) to avoid it in the future. But in the next
sentence telling me that those records are not honoured by many CA's.

I started reading the TOC and policies of Cloudflare again looking for any clue
about this. Nothing. No mention about the certificates that get issued, nothing
about the DNS changes, ... Still everybody tells me something like, "Well if
Cloudflare is doing it, it must be right. Why do you complain?"

It is nice to read a answer like this even if it doe not solve it. :)

Thanks!
___
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

[gerhard . tinned]

On Wednesday, November 2, 2016 at 11:42:00 PM UTC+1, Kristian Fiskerstrand 
wrote:
> On 11/02/2016 11:38 PM, Peter Kurrasch wrote:
> > This raises an interesting point and I'd be interested in any comments
> > ‎that Comodo or other CA's might have.
> > 
> 
> It really seems like a matter of discussion for the terms of agreement
> and interaction between the user and service provider, and not a CA matter.
> 

This is true in general. But when the used practice of validating a domain is
possible against the will and knowledge of the domain owner, ... I guess that
puts the CA in trouble at some point as well. Even if it is only in form of a
loss of trust.

> 
> -- 
> 
> Kristian Fiskerstrand
> Blog: https://blog.sumptuouscapital.com
> Twitter: @krifisk
> 
> Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> 
> Aurum est Potestas
> Gold is power
___
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

[Matt Palmer]

On Wed, Nov 02, 2016 at 09:50:41PM -0700, Han Yuwei wrote:
> 在 2016年9月10日星期六 UTC+8下午8:37:40，Han Yuwei写道：
> > I am using Cloudflare's DNS service and I found that Cloudflare has issued 
> > a certficate to their server including my domain. But I didn't use any SSL 
> > service of theirs. Is that ok to Mozilla's policy?
> > 
> > Issued certificate:https://crt.sh/?id=31206531
> > My domain is BUPT.MOE
> 
> Thanks for your time.
> 
> My question remains that,
> 1. If I request Comodo to revoke the certificate, how is it likely to be 
> approved?

Extremely close to zero.

> 2. If Cloudflare use this certificate to perform MITM, how can others know 
> about it?

Cloudflare *do* use their certificates to perform MitM, that's their entire
business model.

> 3. Is this concerned by Mozilla? If it isn't, I wouldn't post anything about 
> it anymore.

I don't speak for Mozilla, but I haven't seen anyone from Mozilla express
concern about the actions of Comodo in this case, and I don't know of any
aspect of Mozilla policies which this behaviour violates.

- Matt

___
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

[Han Yuwei]

在 2016年9月10日星期六 UTC+8下午8:37:40，Han Yuwei写道：
> I am using Cloudflare's DNS service and I found that Cloudflare has issued a 
> certficate to their server including my domain. But I didn't use any SSL 
> service of theirs. Is that ok to Mozilla's policy?
> 
> Issued certificate:https://crt.sh/?id=31206531
> My domain is BUPT.MOE

Thanks for your time.

My question remains that,
1. If I request Comodo to revoke the certificate, how is it likely to be 
approved?

2. If Cloudflare use this certificate to perform MITM, how can others know 
about it?

3. Is this concerned by Mozilla? If it isn't, I wouldn't post anything about it 
anymore.
___
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

[Matt Palmer]

On Wed, Nov 02, 2016 at 03:44:16PM +0100, Jakob Bohm wrote:
> What is the expected behaviour of a CA when they become aware that
> someone is using illicit/dubious methods to pass an otherwise correct
> application of BR and CPS mandated checks?

The "fraud or misuse" reason for revocation would be triggered, I suspect. 
However, I don't believe that an illicit or dubious method for domain
control validation was used in this case, so it doesn't apply.

- Matt

___
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

[Peter Kurrasch]

It depends. If a CA just hands out a cert to anyone who manipulates DNS, that's 
one thing. If a CA (such as Comodo) has a formal agreement‎ with another party 
(such as CloudFlare) to facilitate the issuance of certs, I think that's quite 
another. The former has all sorts of problems and I'm not so interested in 
rehashing them just now.

The latter, however, has not been formally addressed. I can envision scenarios 
where certs get mis-issued, people blame the CA for having some arrangement 
with CloudFlare (or whomever), and CA's scramble for cover from the storm that 
inevitably follows.‎ I think it would be useful to have some ideas in place in 
advance of any such scenarios. 


  Original Message  
From: Kristian Fiskerstrand
Sent: Wednesday, November 2, 2016 5:41 PM
To: Peter Kurrasch; gerhard.tin...@gmail.com; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Cerificate Concern about Cloudflare's DNS

On 11/02/2016 11:38 PM, Peter Kurrasch wrote:
> This raises an interesting point and I'd be interested in any comments
> ‎that Comodo or other CA's might have.
> 

It really seems like a matter of discussion for the terms of agreement
and interaction between the user and service provider, and not a CA matter.


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Aurum est Potestas
Gold is power

___
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

[Kristian Fiskerstrand]

On 11/02/2016 11:38 PM, Peter Kurrasch wrote:
> This raises an interesting point and I'd be interested in any comments
> ‎that Comodo or other CA's might have.
> 

It really seems like a matter of discussion for the terms of agreement
and interaction between the user and service provider, and not a CA matter.


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Aurum est Potestas
Gold is power



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

Re: Cerificate Concern about Cloudflare's DNS

[Peter Kurrasch]

  This raises an interesting point and I'd be interested in any comments ‎that Comodo or other CA's might have.It appears we have a situation where a cert is being issued to what is presumably an authorized party yet that party is not actually authorized by the subscriber. How does Comodo or any other CA validate that a "domain manipulator" has been and continues to be authorized by the actual domain registrant? Is any attestation provided by a party (such as CloudFlare) that they have authorization by their own clients to do whatever they are doing?It's in the interest of CA's to ‎have some well thought-out plans here because I think we know who is getting the blame when the system breaks down. I don't think it would sit well if a CA were to come here and say "you can't blame us for the misissuance because we will give CloudFlare any cert they want."From: gerhard.tin...@gmail.comSent: Wednesday, November 2, 2016 4:16 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Cerificate Concern about Cloudflare's DNSHi, > > Since you delegated your DNS server to Cloudflare, you implicitly allowed them to perform this certificate request on your behalf.> > This is where I strongly disagree! I have checked the TOS and Security policy, ... etc. There is nowhere stated that Cloudflare is allowed without the Users knowledge to manipulate there DNS settings. That sad, there is the proxy service they offer which is changing the DNS settings. But as you actively enable it, you are aware. By delegating the DNS server to Cloudflare, you entrust Cloudflare to distribute the User defined DNS settings. To be able to validate for the certificate, the DNS settings are changed without the users knowledge. No TOS or any other policy states this. Even if that might not be issue for the CA itself (which i do not agree on), This is definitely braking the trust to its users.And the CA (Comodo) informed about it, and not at least requesting a statement from Cloudflare, means they support this, from my point of view, wrong behavior.As it seems the only thing that can be done is move to a different DNS provider!! Still, this is a vialation of trust!!!___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: [FORGED] Re: Cerificate Concern about Cloudflare's DNS

[Peter Gutmann]

Tom Ritter  writes:

>There's been (some) mention that even if a user moves off Cloudflare, the CA
>is not obligated to revoke.

Would it matter?  I guess it depends on circumstances (whether you control the
private key or Cloudflare does, whether you intend to use the same domain
elsewhere or not, etc), but in most cases it seems like no revocation is
necessary, you destroy or stop using the private key and that's it.  Even in
the worst-case scenario, Cloudflare has your private key and you intend to
keep using the domain, presumably there's some contractual obligation for them
to stop using it when you close your account with them.  It seems like a
revocation isn't necessary (not just for this but for pretty much every
revocation reason except keyCompromise).

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

[Peter Bowen]

On Wed, Nov 2, 2016 at 9:38 AM, Jakob Bohm  wrote:
> On 02/11/2016 17:08, Peter Bowen wrote:
>>
>> On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter  wrote:
>>>
>>> On 2 November 2016 at 09:44, Jakob Bohm  wrote:

 The only thing that might be a CA / BR issue would be this:
>>>
>>>
>>> There's been (some) mention that even if a user moves off Cloudflare,
>>> the CA is not obligated to revoke.  I don't agree with that. If a user
>>> purchased a domain from someone (or bought a recently expired domain)
>>> and a TLS certificate was still valid for it, would the new owner not
>>> be able to get it revoked?  If so, how is this different?
>>
>>
>> Tom,
>>
>> As written today, there is no obligation of CAs to do anything a the
>> request of domain registrants.  There is an obligation that the CA
>> SHALL revoke a certificate if:
>>
>> " The CA is made aware of any circumstance indicating that use of a
>> Fully-Qualified Domain Name or IP
>> address in the Certificate is no longer legally permitted (e.g. a
>> court or arbitrator has revoked a Domain Name
>> Registrant’s right to use the Domain Name, a relevant licensing or
>> services agreement between the Domain
>> Name Registrant and the Applicant has terminated, or the Domain Name
>> Registrant has failed to renew the
>> Domain Name)"
>>
>
> Note that the phrase "services agreement" seems to apply directly to
> the Cloudflare situation.  When a domain owner stops using Cloudflare,
> the services agreement between the domain registrant and Cloudflare has
> terminated.  This when a CA is made aware that a domain registrant has
> stopped using Cloudflare, the above clause is triggered directly,
> leaving only the possibility that the domain registrant explicitly
> wants to keep the certificate in place for an upcoming return to
> Cloudflare.

I agree that would appear to cover this case.

>> Note that this does not give special authority to registrants.  In
>> particular, the straight up "request revocation" option is limited to
>> the _Subscriber_, which is the entity that acquired the certificate.
>>
>> I think that this is a massive gap, especially in the current state of
>> "WebPKI" where certificates are really a third party (CA) assertion
>> that they performed a Trust On First Use (TOFU) operation with the
>> objective that the CA is better positioned avoid attackers than the
>> party later relying upon the certificate.
>>
>>> Aside, it would be very interesting to watch domain renewals + contact
>>> info changes (if one can do this at scale) and pair it up with the CT
>>> logs to see how much of an issue this is/could be.
>>
>>
>> Given that every CA I know of will issue a certificate for a validity
>> period that exceeds the domain registration period, I suspect it is
>> not hard to find many certificates containing FQDNs under expired
>> domains.
>>
>
> Again, the above text explicitly says that if the CA is made aware that
> the domain has not been renewed, it must act accordingly.

Yes, but it does not require CAs to go checking such.  I strongly
doubt any CA is proactively revoking certificates for expired domains.

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

[Gervase Markham]

On 02/11/16 16:01, Nick Lamb wrote:
> Maybe this can to some extent be fixed, but there are many other ways
> in which DNS names now have a footprint that extends beyond the life
> of the domain registration. Cookies and HSTS rules, spam blocks,
> Google search karma, and so on. So arguably buying the domain name
> foo.example "second hand" comes with many risks, pre-existing Web PKI
> certs isn't one of the biggest. 

I think this is probably a reasonable position; I'd say that the domain
name sales market needs to evolve such that their contracts require
sellers to disclose if the domain has ever had SSL certs issued, HSTS
applied, etc. For all I know, that may be true even now.

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

[Jeremy Rowley]

Agreed, I'd support a requirement that mandated revocation of a certificate 
using the domain validation processes supported by the CA in issuance. If you 
can prove control enough to get a certificate from the CA, then you are able 
to prove control enough to revoke a certificate.

-Original Message-
From: Tom Ritter [mailto:t...@ritter.vg]
Sent: Wednesday, November 2, 2016 10:45 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Peter Bowen <pzbo...@gmail.com>; 
mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm 
<jb-mozi...@wisemo.com>
Subject: Re: Cerificate Concern about Cloudflare's DNS

On 2 November 2016 at 11:24, Jeremy Rowley <jeremy.row...@digicert.com> wrote:
> Revocation support for non-subscribers is sort of implied...sort of:
>
> Section 4.9.3:
> The CA SHALL provide Subscribers, Relying Parties, Application
> Software Suppliers, and other third parties with clear instructions
> for reporting suspected Private Key Compromise, Certificate misuse, or
> other types of fraud, compromise, misuse, inappropriate conduct, or any 
> other matter related to Certificates. The CA SHALL publicly disclose the 
> instructions through a readily accessible online means.
>

This was the text I was imagining being triggered by this scenario.

I certainly accept the fact that a CA has a reasonable reason to doubt random 
incoming "Please revoke this certificate" requests, and could or should 
require additional verification before taking action. I would imagine that for 
DV revocations, such verification would be pretty much identical to DV 
verification. The hard part is merely automating the process for scale like 
they do for DV issuance. (But if a CA got enough of these requests it could 
save some engineering by reusing that verification infrastructure!)

-tom


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: Cerificate Concern about Cloudflare's DNS

[Tom Ritter]

On 2 November 2016 at 11:24, Jeremy Rowley  wrote:
> Revocation support for non-subscribers is sort of implied...sort of:
>
> Section 4.9.3:
> The CA SHALL provide Subscribers, Relying Parties, Application Software 
> Suppliers, and other third parties with
> clear instructions for reporting suspected Private Key Compromise, 
> Certificate misuse, or other types of fraud,
> compromise, misuse, inappropriate conduct, or any other matter related to 
> Certificates. The CA SHALL publicly
> disclose the instructions through a readily accessible online means.
>

This was the text I was imagining being triggered by this scenario.

I certainly accept the fact that a CA has a reasonable reason to doubt
random incoming "Please revoke this certificate" requests, and could
or should require additional verification before taking action. I
would imagine that for DV revocations, such verification would be
pretty much identical to DV verification. The hard part is merely
automating the process for scale like they do for DV issuance. (But if
a CA got enough of these requests it could save some engineering by
reusing that verification infrastructure!)

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

[Jakob Bohm]

On 02/11/2016 17:08, Peter Bowen wrote:

On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter  wrote:

On 2 November 2016 at 09:44, Jakob Bohm  wrote:

The only thing that might be a CA / BR issue would be this:


There's been (some) mention that even if a user moves off Cloudflare,
the CA is not obligated to revoke.  I don't agree with that. If a user
purchased a domain from someone (or bought a recently expired domain)
and a TLS certificate was still valid for it, would the new owner not
be able to get it revoked?  If so, how is this different?


Tom,

As written today, there is no obligation of CAs to do anything a the
request of domain registrants.  There is an obligation that the CA
SHALL revoke a certificate if:

" The CA is made aware of any circumstance indicating that use of a
Fully-Qualified Domain Name or IP
address in the Certificate is no longer legally permitted (e.g. a
court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or
services agreement between the Domain
Name Registrant and the Applicant has terminated, or the Domain Name
Registrant has failed to renew the
Domain Name)"



Note that the phrase "services agreement" seems to apply directly to
the Cloudflare situation.  When a domain owner stops using Cloudflare,
the services agreement between the domain registrant and Cloudflare has
terminated.  This when a CA is made aware that a domain registrant has
stopped using Cloudflare, the above clause is triggered directly,
leaving only the possibility that the domain registrant explicitly
wants to keep the certificate in place for an upcoming return to
Cloudflare.


Note that this does not give special authority to registrants.  In
particular, the straight up "request revocation" option is limited to
the _Subscriber_, which is the entity that acquired the certificate.

I think that this is a massive gap, especially in the current state of
"WebPKI" where certificates are really a third party (CA) assertion
that they performed a Trust On First Use (TOFU) operation with the
objective that the CA is better positioned avoid attackers than the
party later relying upon the certificate.


Aside, it would be very interesting to watch domain renewals + contact
info changes (if one can do this at scale) and pair it up with the CT
logs to see how much of an issue this is/could be.


Given that every CA I know of will issue a certificate for a validity
period that exceeds the domain registration period, I suspect it is
not hard to find many certificates containing FQDNs under expired
domains.



Again, the above text explicitly says that if the CA is made aware that
the domain has not been renewed, it must act accordingly.


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: Cerificate Concern about Cloudflare's DNS

[Jeremy Rowley]

Revocation support for non-subscribers is sort of implied...sort of:

Section 4.9.3:
The CA SHALL provide Subscribers, Relying Parties, Application Software 
Suppliers, and other third parties with
clear instructions for reporting suspected Private Key Compromise, Certificate 
misuse, or other types of fraud,
compromise, misuse, inappropriate conduct, or any other matter related to 
Certificates. The CA SHALL publicly
disclose the instructions through a readily accessible online means.



-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Peter Bowen
Sent: Wednesday, November 2, 2016 10:08 AM
To: Tom Ritter <t...@ritter.vg>
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm 
<jb-mozi...@wisemo.com>
Subject: Re: Cerificate Concern about Cloudflare's DNS

On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter <t...@ritter.vg> wrote:
> On 2 November 2016 at 09:44, Jakob Bohm <jb-mozi...@wisemo.com> wrote:
>> The only thing that might be a CA / BR issue would be this:
>
> There's been (some) mention that even if a user moves off Cloudflare, 
> the CA is not obligated to revoke.  I don't agree with that. If a user 
> purchased a domain from someone (or bought a recently expired domain) 
> and a TLS certificate was still valid for it, would the new owner not 
> be able to get it revoked?  If so, how is this different?

Tom,

As written today, there is no obligation of CAs to do anything a the request of 
domain registrants.  There is an obligation that the CA SHALL revoke a 
certificate if:

" The CA is made aware of any circumstance indicating that use of a 
Fully-Qualified Domain Name or IP address in the Certificate is no longer 
legally permitted (e.g. a court or arbitrator has revoked a Domain Name 
Registrant’s right to use the Domain Name, a relevant licensing or services 
agreement between the Domain Name Registrant and the Applicant has terminated, 
or the Domain Name Registrant has failed to renew the Domain Name)"

Note that this does not give special authority to registrants.  In particular, 
the straight up "request revocation" option is limited to the _Subscriber_, 
which is the entity that acquired the certificate.

I think that this is a massive gap, especially in the current state of "WebPKI" 
where certificates are really a third party (CA) assertion that they performed 
a Trust On First Use (TOFU) operation with the objective that the CA is better 
positioned avoid attackers than the party later relying upon the certificate.

> Aside, it would be very interesting to watch domain renewals + contact 
> info changes (if one can do this at scale) and pair it up with the CT 
> logs to see how much of an issue this is/could be.

Given that every CA I know of will issue a certificate for a validity period 
that exceeds the domain registration period, I suspect it is not hard to find 
many certificates containing FQDNs under expired domains.

Thanks,
Peter
___
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: Cerificate Concern about Cloudflare's DNS

[Peter Bowen]

On Wed, Nov 2, 2016 at 8:26 AM, Tom Ritter  wrote:
> On 2 November 2016 at 09:44, Jakob Bohm  wrote:
>> The only thing that might be a CA / BR issue would be this:
>
> There's been (some) mention that even if a user moves off Cloudflare,
> the CA is not obligated to revoke.  I don't agree with that. If a user
> purchased a domain from someone (or bought a recently expired domain)
> and a TLS certificate was still valid for it, would the new owner not
> be able to get it revoked?  If so, how is this different?

Tom,

As written today, there is no obligation of CAs to do anything a the
request of domain registrants.  There is an obligation that the CA
SHALL revoke a certificate if:

" The CA is made aware of any circumstance indicating that use of a
Fully-Qualified Domain Name or IP
address in the Certificate is no longer legally permitted (e.g. a
court or arbitrator has revoked a Domain Name
Registrant’s right to use the Domain Name, a relevant licensing or
services agreement between the Domain
Name Registrant and the Applicant has terminated, or the Domain Name
Registrant has failed to renew the
Domain Name)"

Note that this does not give special authority to registrants.  In
particular, the straight up "request revocation" option is limited to
the _Subscriber_, which is the entity that acquired the certificate.

I think that this is a massive gap, especially in the current state of
"WebPKI" where certificates are really a third party (CA) assertion
that they performed a Trust On First Use (TOFU) operation with the
objective that the CA is better positioned avoid attackers than the
party later relying upon the certificate.

> Aside, it would be very interesting to watch domain renewals + contact
> info changes (if one can do this at scale) and pair it up with the CT
> logs to see how much of an issue this is/could be.

Given that every CA I know of will issue a certificate for a validity
period that exceeds the domain registration period, I suspect it is
not hard to find many certificates containing FQDNs under expired
domains.

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

[Nick Lamb]

On Wednesday, 2 November 2016 15:26:37 UTC, Tom Ritter  wrote:
> There's been (some) mention that even if a user moves off Cloudflare,
> the CA is not obligated to revoke.  I don't agree with that. If a user
> purchased a domain from someone (or bought a recently expired domain)
> and a TLS certificate was still valid for it, would the new owner not
> be able to get it revoked?  If so, how is this different?

ISRG / Let's Encrypt has said that although in principle they are sympathetic 
in this sort of scenario, there would be a big practical obstacle to achieving 
the certainty needed to revoke the old certificate (if they just said "Yes" 
without an investigation then you can DOS any certificate owner by sending off 
emails saying you just bought their domain and need the certificates to be 
revoked...), and they would recommend usually just to wait for the certificate 
to expire naturally (their end entity certificates of course only last 90 days 
each).

That balance might look rather different for a 2 year EV certificate but I 
believe the underlying principle (the validation is OK for a prolonged period 
under the BRs) is the same.

Maybe this can to some extent be fixed, but there are many other ways in which 
DNS names now have a footprint that extends beyond the life of the domain 
registration. Cookies and HSTS rules, spam blocks, Google search karma, and so 
on. So arguably buying the domain name foo.example "second hand" comes with 
many risks, pre-existing Web PKI certs isn't one of the biggest. I suspect that 
even if you could get a license to name a new technology product "Zune" 
tomorrow that would be a bad idea too.

> Aside, it would be very interesting to watch domain renewals + contact
> info changes (if one can do this at scale) and pair it up with the CT
> logs to see how much of an issue this is/could be.

Most large registries go out of their way to make collecting bulk WHOIS data 
(which is what you need here) this technically difficult, largely as a measure 
to protect registrants from truly mind-boggling amounts of spam from SEO 
companies and suchlike.

A legitimate researcher (e.g. someone with related academic credentials) might 
be able to approach them and agree an NDA where they only release aggregate 
statistical results, in exchange for getting the raw data. But it may well just 
not be worth the hassle for a registry to agree that.
___
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

[Tom Ritter]

On 2 November 2016 at 09:44, Jakob Bohm  wrote:
> The only thing that might be a CA / BR issue would be this:

There's been (some) mention that even if a user moves off Cloudflare,
the CA is not obligated to revoke.  I don't agree with that. If a user
purchased a domain from someone (or bought a recently expired domain)
and a TLS certificate was still valid for it, would the new owner not
be able to get it revoked?  If so, how is this different?

Aside, it would be very interesting to watch domain renewals + contact
info changes (if one can do this at scale) and pair it up with the CT
logs to see how much of an issue this is/could be.

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

[Jakob Bohm]

On 02/11/2016 15:05, Ryan Sleevi wrote:

On Wednesday, November 2, 2016 at 2:16:34 AM UTC-7, gerhard...@gmail.com wrote:

This is where I strongly disagree! I have checked the TOS and Security policy, 
... etc. There is nowhere stated that Cloudflare is allowed without the Users 
knowledge to manipulate there DNS settings. That sad, there is the proxy 
service they offer which is changing the DNS settings. But as you actively 
enable it, you are aware.


Certainly, this is stated via the CA/Browser Forum's Baseline Requirements, 
which is incorporated in to the Mozilla Policy by reference and which 
enumerates acceptable means to obtain certificates.

You're focused on 'manipulation' of DNS (which is a bit of misnomer), but 
because you're delegating control of the IP to Cloudflare, they can just obtain 
a certificate that way.


And the CA (Comodo) informed about it, and not at least requesting a statement 
from Cloudflare, means they support this, from my point of view, wrong behavior.


As it seems the only thing that can be done is move to a different DNS 
provider!! Still, this is a vialation of trust!!!


If you feel that way, it may suggest Cloudflare may not be the right DNS 
provider for you. As you note, however, it's not an issue for the CA - it's a 
fully permitted and specified method - so if there's issue, this may not be the 
right forum for that.



The only thing that might be a CA / BR issue would be this:

What is the expected behaviour of a CA when they become aware that
someone is using illicit/dubious methods to pass an otherwise correct
application of BR and CPS mandated checks?

As an extreme example, imagine the Hollywood movie scenario where
someone goes into a bank with guns and hoods, and then while they are
in there robbing the cash, they also use their control of the banks
buildings and equipment to obtain an EV certificate that passes all the
usual checks because the Banks CEO had a machine gun at his head when
confirming the request etc. etc.  If the CA learns from the news that
the bank had been completely under siege on those days, should they
revoke the certificate as quickly as possible, or should they wait for
the (now dead) bank CEO to ask for revocation using the account
password he never had?

Note that I am not saying that CloudFlare's actions are illicit or that
the allegations are in any way comparable to armed robbery.  Only that
the CA operational principle in question might be the same.

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: Cerificate Concern about Cloudflare's DNS

[Ryan Sleevi]

On Wednesday, November 2, 2016 at 2:16:34 AM UTC-7, gerhard...@gmail.com wrote:
> This is where I strongly disagree! I have checked the TOS and Security 
> policy, ... etc. There is nowhere stated that Cloudflare is allowed without 
> the Users knowledge to manipulate there DNS settings. That sad, there is the 
> proxy service they offer which is changing the DNS settings. But as you 
> actively enable it, you are aware. 

Certainly, this is stated via the CA/Browser Forum's Baseline Requirements, 
which is incorporated in to the Mozilla Policy by reference and which 
enumerates acceptable means to obtain certificates.

You're focused on 'manipulation' of DNS (which is a bit of misnomer), but 
because you're delegating control of the IP to Cloudflare, they can just obtain 
a certificate that way.

> And the CA (Comodo) informed about it, and not at least requesting a 
> statement from Cloudflare, means they support this, from my point of view, 
> wrong behavior.
> 
> 
> As it seems the only thing that can be done is move to a different DNS 
> provider!! Still, this is a vialation of trust!!!

If you feel that way, it may suggest Cloudflare may not be the right DNS 
provider for you. As you note, however, it's not an issue for the CA - it's a 
fully permitted and specified method - so if there's issue, this may not be the 
right forum for that.
___
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

[gerhard . tinned]

Hi, 

> 
> Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> them to perform this certificate request on your behalf.
> 
> 
This is where I strongly disagree! I have checked the TOS and Security policy, 
... etc. There is nowhere stated that Cloudflare is allowed without the Users 
knowledge to manipulate there DNS settings. That sad, there is the proxy 
service they offer which is changing the DNS settings. But as you actively 
enable it, you are aware. 

By delegating the DNS server to Cloudflare, you entrust Cloudflare to 
distribute the User defined DNS settings. To be able to validate for the 
certificate, the DNS settings are changed without the users knowledge. No TOS 
or any other policy states this. 

Even if that might not be issue for the CA itself (which i do not agree on), 
This is definitely braking the trust to its users.

And the CA (Comodo) informed about it, and not at least requesting a statement 
from Cloudflare, means they support this, from my point of view, wrong behavior.


As it seems the only thing that can be done is move to a different DNS 
provider!! Still, this is a vialation of trust!!!

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

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

Well, there is .

My concern goes like this: If I move my infrastructure to Cloudflare,
I give them implied permission, based on their terms of service, to
obtain a X.509 certificate for my domain names hosted there, so that
they can intercept traffic.

On the other hand, if I move my infrastructure to Germany, I give the
German authorities implied permission, based on applicable German law,
to ask my service provide to obtain an X.509 certificate for my domain
names hosted there, so that they can intercept traffic in the clear
(in accordance with German law).

In both cases, we have implied consent, but the alleged certificate
subscriber never has control over the private key, and how it is used.
I don't think neither setup is intended to exist per the Mozilla CA
guidelines.
___
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

[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: 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: Cerificate Concern about Cloudflare's DNS

[Fotis Loukos]

On 09/10/2016 05:43 PM, Erwann Abalea wrote:
> Bonjour,
> 
> Le samedi 10 septembre 2016 14:37:40 UTC+2, Han Yuwei a écrit :
>> I am using Cloudflare's DNS service and I found that Cloudflare has issued a 
>> certficate to their server including my domain. But I didn't use any SSL 
>> service of theirs. Is that ok to Mozilla's policy?
>>
>> Issued certificate:https://crt.sh/?id=31206531
>> My domain is BUPT.MOE
> 
> Technically speaking, Cloudflare did not issue a certificate, they requested 
> one and have it been issued by a CA.


And they state this clearly at https://www.cloudflare.com/plans/. The
free and pro plans have cloudflare issued certificates (cloudflare
issued means that they initiate the issue procedure) while the business
and enterprise plans can have either cloudflare issued certificates or
certificates issued by the user and uploaded to cloudflare.

Regards,
Fotis

> 
> I won't say wether it's ok for Mozilla or not, but it's at least authorized 
> by the CABForum Baseline Requirements.
> 
> Cloudflare was the Applicant (it's now the Subscriber), Comodo is the CA, you 
> are the Domain Name Registrant, your Registrar appears to be Hosting Concept 
> (Openprovider), the requested FQDN is bupt.moe.
> 
> The Applicant requested a certificate for the FQDN to the CA, the CA has 
> several methods declared in its CPS to verify that the Applicant is 
> authorized by the Domain Name Registrant to control the FQDN.
> 
> Of all these methods, some of them won't work here without your knowledge 
> (phone-call, sending you an email as listed in the Whois, sending an email to 
> admin/administrator/webmaster/hostmaster/postmaster@yourdomain).
> One of the remaining methods may have been possible only if Cloudflare 
> redirected the DNS record of your FQDN to one of their servers just for the 
> verification to pass ("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"), which could be considered problematic.
> In my opinion, the most plausible verification method in this case is the 
> last one: "Having the Applicant demonstrate practical control over the FQDN 
> by making an agreed-upon change to information found in the DNS containing 
> the FQDN"; for example asking the Applicant to add a CA-chosen random value 
> in a TXT record of the FQDN.
> 
> Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> them to perform this certificate request on your behalf.
> 
> 
> 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.
> ___
> 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: Cerificate Concern about Cloudflare's DNS

[Matt Palmer]

On Tue, Sep 13, 2016 at 07:04:31AM -0700, Han Yuwei wrote:
> 在 2016年9月13日星期二 UTC+8下午7:12:22，Matt Palmer写道：
> > On Mon, Sep 12, 2016 at 08:38:00PM -0700, Han Yuwei wrote:
> > > 在 2016年9月13日星期二 UTC+8上午8:07:31，Matt Palmer写道：
> > > I am the owner of BUPT.MOE and I just use DNS service.
> > 
> > And you've never ticked (or unticked[1]) the little "cloud" icon to the
> > right of *any* record in bupt.moe?
> 
> Maybe I ticked it by accident. And I don't remember it.But I think it is
> better to notice me that Cloudflare is going to apply the certificate. 

That's something you'll want to raise with Cloudflare support.  It really
isn't within the remit of this group to mandate how CDN providers manage
their user experience.

- Matt

___
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

[Matt Palmer]

On Mon, Sep 12, 2016 at 08:38:00PM -0700, Han Yuwei wrote:
> 在 2016年9月13日星期二 UTC+8上午8:07:31，Matt Palmer写道：
> > If Cloudflare *was*, in fact, obtaining certificates on behalf of all its
> > DNS-using (only) customers on the "off chance" that they might want to use
> > their proxy services in the future, that would be extremely creepy and
> > unpleasant, but so far I don't think there's enough evidence to be able to
> > say such a thing is happening at present.  It seems far more likely that
> > bupt.moe was a Cloudflare proxy customer (if only for a *very* brief time),
> > the certificate was issued for that purpose, and now the domain has been
> > pointed elsewhere, and the name is just hanging around in a cert which will
> > expire in six months or so.
> 
> I am the owner of BUPT.MOE and I just use DNS service.

And you've never ticked (or unticked[1]) the little "cloud" icon to the
right of *any* record in bupt.moe?

- Matt

[1] I took a support request today for a "DNS only" Cloudflare customer, and
it appeared that their root record was being passed through Cloudflare.  I
haven't heard back as to whether someone at their end knowingly enabled it,
but there's the possibility that Cloudflare automagically enables proxying
by default -- which is deplorable, IMO, from a user experience perspective,
but not something that is relevant from an SSL perspective.

-- 
The main advantages of Haynes and Chilton manuals are that they cost $15,
where the factory manuals cost $100 and up, and that they will tell you how
to use two hammers, a block of wood, and a meerkat to replace "special tool
no. 2-112-A"-- Matt Roberds in asr.

___
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

[Matt Palmer]

On Sat, Sep 10, 2016 at 06:33:59PM -0700, xiaoyi...@outlook.com wrote:
> But is it a OK behavior if a CDN vendor doesn't immediately revoke the old
> cert after I stop using its CDN service?

I don't think it's automatically terrible behaviour.  Plenty of people let
certificates lapse rather than actively revoking them when they stop using
the name, it doesn't appear to have caused massive problems.  As long as the
private key for the certificate is appropriately protected for the lifetime
of the certificate, I can't think of any particular problem with it.  That
goes double when it's a multi-sAN cert -- revoking the cert and reissuing it
with everything the same except for one less sAN doesn't seem worth the
hassle.

- Matt

___
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

[Han Yuwei]

在 2016年9月13日星期二 UTC+8上午8:07:31，Matt Palmer写道：
> On Mon, Sep 12, 2016 at 08:57:29PM +0100, Rob Stradling wrote:
> > On 12/09/16 18:57, Jakob Bohm wrote:
> > > On 11/09/2016 07:49, Peter Bowen wrote:
> > >> 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.
> > > 
> > > This seems another reason for the web to not trust cloudflare as a
> > > trustworthy domain proxy handler.
> > > 
> > > Just because their (paid, presumably) job gives them the technical
> > > ability to requests certificates without the consent of the domain
> > > owner, this does not given them any legitimate right to do so.
> > 
> > Hi Jakob.  Do you find any fault with Comodo for issuing this cert
> > (https://crt.sh/?id=31206531) ?
> > 
> > We validated domain control, but we did not attempt to establish "the
> > consent of the domain owner"(s) directly.  As others have pointed out,
> > this is compliant with the CABForum BRs.
> 
> Are you able, by any chance, to reveal whether the domain control was
> validated by HTTP request, DNS change, or "other" (please specify )? 
> At present, it looks like every domain listed in that certificate *other*
> than the domain at issue (bupt.moe) resolves to Cloudflare IP space, so my
> working theory is that the domain was previously pointed to a Cloudflare
> proxy, and has since been moved elsewhere.
> 
> However, it would be nice, for my peace of mind at least, to know how
> control was validated in this instance, if that's something you're able to
> share (I understand you reasonably might not be able, and if so, no
> problem).
> 
> If Cloudflare *was*, in fact, obtaining certificates on behalf of all its
> DNS-using (only) customers on the "off chance" that they might want to use
> their proxy services in the future, that would be extremely creepy and
> unpleasant, but so far I don't think there's enough evidence to be able to
> say such a thing is happening at present.  It seems far more likely that
> bupt.moe was a Cloudflare proxy customer (if only for a *very* brief time),
> the certificate was issued for that purpose, and now the domain has been
> pointed elsewhere, and the name is just hanging around in a cert which will
> expire in six months or so.
> 
> - Matt

I am the owner of BUPT.MOE and I just use DNS service.
___
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

[Jakob Bohm]

On 13/09/2016 01:28, Ryan Sleevi wrote:

On Monday, September 12, 2016 at 3:51:56 PM UTC-7, Jakob Bohm wrote:

Note that this is *entirely* outside CA/B and CA inclusion related
guidelines, since CloudFlare is (presumably) not a CA and thus not
subject to such guidelines.


Then isn't it also generally outside the scope of this list?



I would not have discussed it if there had not already been a thread.

I have mostly written about why this is not a CA fault and what minimal
handling of the complaint would be reasonable CA behavior if such a
case was raised to them by the domain owner.


I am saying that they are (if the story is true) morally at fault for
requesting a certificate that the domain owner did not authorize them
to request, abusing their job of handling some technical aspects of the
domain owners operation.


This gets into emotionally laden language that makes it hard to engage in a 
reasoned discussion with you. To wit, we've established nothing in CA's 
policies prohibit this, nothing in Mozilla's policies prohibit this, you've 
acknowledged that there is harm in creating such policies to prohibit this, so 
it's unclear what positive things you expect to result from this discussion, or 
the value being brought.



I am using the word "morally" simply to distinguish suggested policy
from any current legalities (a previous poster mentioned the
possibility that it might be formally permitted by contract language),
not to express emotion.


And I would presume that any security conscious CA would have an
internal black list of bad networks that they refuse to sell to because
it tends to create too many practical, security or legal problems.


The presumption is, of course, just that - pure speculation. It does seem 
you're opposed to creating such a list, however, so shall we just move on?



Not in principle, just stating that the current incident is not a
reason to establish such a list.  I could imagine cases where some
other hoster was creating havoc across multiple CAs.

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: Cerificate Concern about Cloudflare's DNS

[xiaoyin . l]

On Saturday, September 10, 2016 at 10:44:05 AM UTC-4, Erwann Abalea wrote:
> Bonjour,
> 
> Le samedi 10 septembre 2016 14:37:40 UTC+2, Han Yuwei a écrit :
> > I am using Cloudflare's DNS service and I found that Cloudflare has issued 
> > a certficate to their server including my domain. But I didn't use any SSL 
> > service of theirs. Is that ok to Mozilla's policy?
> > 
> > Issued certificate:https://crt.sh/?id=31206531
> > My domain is BUPT.MOE
> 
> Technically speaking, Cloudflare did not issue a certificate, they requested 
> one and have it been issued by a CA.
> 
> I won't say wether it's ok for Mozilla or not, but it's at least authorized 
> by the CABForum Baseline Requirements.
> 
> Cloudflare was the Applicant (it's now the Subscriber), Comodo is the CA, you 
> are the Domain Name Registrant, your Registrar appears to be Hosting Concept 
> (Openprovider), the requested FQDN is bupt.moe.
> 
> The Applicant requested a certificate for the FQDN to the CA, the CA has 
> several methods declared in its CPS to verify that the Applicant is 
> authorized by the Domain Name Registrant to control the FQDN.
> 
> Of all these methods, some of them won't work here without your knowledge 
> (phone-call, sending you an email as listed in the Whois, sending an email to 
> admin/administrator/webmaster/hostmaster/postmaster@yourdomain).
> One of the remaining methods may have been possible only if Cloudflare 
> redirected the DNS record of your FQDN to one of their servers just for the 
> verification to pass ("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"), which could be considered problematic.
> In my opinion, the most plausible verification method in this case is the 
> last one: "Having the Applicant demonstrate practical control over the FQDN 
> by making an agreed-upon change to information found in the DNS containing 
> the FQDN"; for example asking the Applicant to add a CA-chosen random value 
> in a TXT record of the FQDN.
> 
> Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> them to perform this certificate request on your behalf.
> 
> 
> 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.

But is it a OK behavior if a CDN vendor doesn't immediately revoke the old cert 
after I stop using its CDN service?
___
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

[asherkin]

On Monday, September 12, 2016 at 2:43:09 PM UTC+1, Peter Kurrasch wrote:
> I was thinking of more the server (cloud) side of things. I'm not familiar 
> enough with Cloudflare's service, but I imagine that if I have a server set 
> up I will also have access to my private key. If so, I now have access to the 
> private key of the other domains. Perhaps there are protections set up?

CloudFlare perform SSL termination for these certificates on their side before 
proxying, you never get access to the private key.
___
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

[Matt Palmer]

On Mon, Sep 12, 2016 at 08:57:29PM +0100, Rob Stradling wrote:
> On 12/09/16 18:57, Jakob Bohm wrote:
> > On 11/09/2016 07:49, Peter Bowen wrote:
> >> 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.
> > 
> > This seems another reason for the web to not trust cloudflare as a
> > trustworthy domain proxy handler.
> > 
> > Just because their (paid, presumably) job gives them the technical
> > ability to requests certificates without the consent of the domain
> > owner, this does not given them any legitimate right to do so.
> 
> Hi Jakob.  Do you find any fault with Comodo for issuing this cert
> (https://crt.sh/?id=31206531) ?
> 
> We validated domain control, but we did not attempt to establish "the
> consent of the domain owner"(s) directly.  As others have pointed out,
> this is compliant with the CABForum BRs.

Are you able, by any chance, to reveal whether the domain control was
validated by HTTP request, DNS change, or "other" (please specify )? 
At present, it looks like every domain listed in that certificate *other*
than the domain at issue (bupt.moe) resolves to Cloudflare IP space, so my
working theory is that the domain was previously pointed to a Cloudflare
proxy, and has since been moved elsewhere.

However, it would be nice, for my peace of mind at least, to know how
control was validated in this instance, if that's something you're able to
share (I understand you reasonably might not be able, and if so, no
problem).

If Cloudflare *was*, in fact, obtaining certificates on behalf of all its
DNS-using (only) customers on the "off chance" that they might want to use
their proxy services in the future, that would be extremely creepy and
unpleasant, but so far I don't think there's enough evidence to be able to
say such a thing is happening at present.  It seems far more likely that
bupt.moe was a Cloudflare proxy customer (if only for a *very* brief time),
the certificate was issued for that purpose, and now the domain has been
pointed elsewhere, and the name is just hanging around in a cert which will
expire in six months or so.

- Matt

___
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

[Ryan Sleevi]

On Monday, September 12, 2016 at 3:51:56 PM UTC-7, Jakob Bohm wrote:
> Note that this is *entirely* outside CA/B and CA inclusion related
> guidelines, since CloudFlare is (presumably) not a CA and thus not
> subject to such guidelines.

Then isn't it also generally outside the scope of this list?

> I am saying that they are (if the story is true) morally at fault for
> requesting a certificate that the domain owner did not authorize them
> to request, abusing their job of handling some technical aspects of the
> domain owners operation.

This gets into emotionally laden language that makes it hard to engage in a 
reasoned discussion with you. To wit, we've established nothing in CA's 
policies prohibit this, nothing in Mozilla's policies prohibit this, you've 
acknowledged that there is harm in creating such policies to prohibit this, so 
it's unclear what positive things you expect to result from this discussion, or 
the value being brought.

> And I would presume that any security conscious CA would have an
> internal black list of bad networks that they refuse to sell to because
> it tends to create too many practical, security or legal problems.

The presumption is, of course, just that - pure speculation. It does seem 
you're opposed to creating such a list, however, so shall we just move on?
___
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

[Jakob Bohm]

On 12/09/2016 23:48, Ryan Sleevi wrote:

On Monday, September 12, 2016 at 2:33:47 PM UTC-7, Jakob Bohm wrote:

I find fault in CloudFlare (presuming the story is actually as
reported).


Why? Apologies, but I fail to see what you believe is "wrong", given how 
multiple people have pointed to you it being well-understood and permissible, under past 
and present guidelines.



Note that this is *entirely* outside CA/B and CA inclusion related
guidelines, since CloudFlare is (presumably) not a CA and thus not
subject to such guidelines.

I am saying that they are (if the story is true) morally at fault for
requesting a certificate that the domain owner did not authorize them
to request, abusing their job of handling some technical aspects of the
domain owners operation.

The common equivalent would be a network administrator requesting a
certificate that his boss had not authorized him to request.  There is
no way an outside CA could know that such authorization had not been
given if that employee was in a position where the only difference
between a real or bad request would be what their boss did or did not
tell the employee to do.

This common equivalent would be sufficiently common (on a worldwide
statistical basis), that it would be useful for large CAs to have
standard procedures and policies (be they manual or automated, public
or internal) for handling such situations.  The defining characteristic
would be "this person claims to outrank the original certificate
requestor and is requesting revocation of a certificate without having
access to the files etc. involved in the original request".


 From the story as reported, Comodo had every reason to believe that
CloudFlare was authorized by the domain owner to request that DV cert,
and had no additional preemptive tests to do (baring a future finding
that CloudFlare should be blacklisted from requesting DV certificates,
which would require a large number of cases given the huge number of
domains they handle without objection by domain owners).


This gets further into "What you're proposing doesn't exist" territory, such as 
the notion of blacklisting an organization from requesting a DV cert, when the whole 
notion of DV is that the only thing validated is the domain (not the organization 
operating the domain or requesting the cert)



I was arguing *against* adding CloudFlare to such a list, even if it
existed.

And I would presume that any security conscious CA would have an
internal black list of bad networks that they refuse to sell to because
it tends to create too many practical, security or legal problems.


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: Cerificate Concern about Cloudflare's DNS

[Ryan Sleevi]

On Monday, September 12, 2016 at 2:33:47 PM UTC-7, Jakob Bohm wrote:
> I find fault in CloudFlare (presuming the story is actually as
> reported).

Why? Apologies, but I fail to see what you believe is "wrong", given how 
multiple people have pointed to you it being well-understood and permissible, 
under past and present guidelines.

>  From the story as reported, Comodo had every reason to believe that
> CloudFlare was authorized by the domain owner to request that DV cert,
> and had no additional preemptive tests to do (baring a future finding
> that CloudFlare should be blacklisted from requesting DV certificates,
> which would require a large number of cases given the huge number of
> domains they handle without objection by domain owners).

This gets further into "What you're proposing doesn't exist" territory, such as 
the notion of blacklisting an organization from requesting a DV cert, when the 
whole notion of DV is that the only thing validated is the domain (not the 
organization operating the domain or requesting the cert)
___
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

[Jakob Bohm]

On 12/09/2016 21:57, Rob Stradling wrote:

On 12/09/16 18:57, Jakob Bohm wrote:

On 11/09/2016 07:49, Peter Bowen wrote:

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.


This seems another reason for the web to not trust cloudflare as a
trustworthy domain proxy handler.

Just because their (paid, presumably) job gives them the technical
ability to requests certificates without the consent of the domain
owner, this does not given them any legitimate right to do so.


Hi Jakob.  Do you find any fault with Comodo for issuing this cert
(https://crt.sh/?id=31206531) ?

We validated domain control, but we did not attempt to establish "the
consent of the domain owner"(s) directly.  As others have pointed out,
this is compliant with the CABForum BRs.

Given that establishing "the consent of the domain owner" is the
territory of OV certs and EV certs, is it your opinion that DV certs
should be outlawed?



I find fault in CloudFlare (presuming the story is actually as
reported).

I also think that CAs (of any cert type) should have a process where
the owner of the certified identity can request revocation based on
disavowal of a (technically valid) request (not at all limited to the
DV case, legitimate representatives get ousted all the time).  This
would be a routine process involving identity checks to confirm that
the revocation requestor outranks the certificate requestor, rather
than the fallback of public reporting of bad certs.

From the story as reported, Comodo had every reason to believe that
CloudFlare was authorized by the domain owner to request that DV cert,
and had no additional preemptive tests to do (baring a future finding
that CloudFlare should be blacklisted from requesting DV certificates,
which would require a large number of cases given the huge number of
domains they handle without objection by domain owners).




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: Cerificate Concern about Cloudflare's DNS

[Rob Stradling]

On 12/09/16 18:57, Jakob Bohm wrote:
> On 11/09/2016 07:49, Peter Bowen wrote:
>> 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.
> 
> This seems another reason for the web to not trust cloudflare as a
> trustworthy domain proxy handler.
> 
> Just because their (paid, presumably) job gives them the technical
> ability to requests certificates without the consent of the domain
> owner, this does not given them any legitimate right to do so.

Hi Jakob.  Do you find any fault with Comodo for issuing this cert
(https://crt.sh/?id=31206531) ?

We validated domain control, but we did not attempt to establish "the
consent of the domain owner"(s) directly.  As others have pointed out,
this is compliant with the CABForum BRs.

Given that establishing "the consent of the domain owner" is the
territory of OV certs and EV certs, is it your opinion that DV certs
should be outlawed?

Just curious.

Thanks.

-- 
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: Cerificate Concern about Cloudflare's DNS

[Jakob Bohm]

On 11/09/2016 07:49, Peter Bowen wrote:

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.



This seems another reason for the web to not trust cloudflare as a
trustworthy domain proxy handler.

Just because their (paid, presumably) job gives them the technical
ability to requests certificates without the consent of the domain
owner, this does not given them any legitimate right to do so.

Just because a (non-negotiable, presumably) set of "terms of service"
contains a clause to allow them to obtain necessary certificates for
customers hosting HTTPS on their shared proxy, does not given them any
legitimate (even if legal) right to obtain such certificates for those
customer domains where HTTPS hosting has not been requested by the
customer.

CA policies and BR requirements should reflect that occasionally a
person or company acting on behalf of another entity might request
certificates against the will of the legitimate entity, and that the
legitimate entity might thus need to request revocation on a first
party basis, regardless what a third party may have done in their
name.

P.S.

Those of us who run white-list based security plugins in Mozilla-
derived browsers are already faced with the frequent need to guess if a
"number-url" under cloudflare's own domains represents a proxy cache of
a trustworthy site or not.  If cloudflare itself starts to play fast
and loose with the identity of the proxied domains, that becomes a
security concern in itself, unrelated to CA inclusion policy.


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: Cerificate Concern about Cloudflare's DNS

[Erwann Abalea]

Le lundi 12 septembre 2016 15:59:14 UTC+2, Ben Laurie a écrit :
> 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."

You're right; I was reading version 1.3.0 of the BR, to match with Comodo's 
CPS, and that section was less easily open to revocation requests by third 
parties.
So Mr Huan Yuwei, you can contact Comodo by email (the exact address is found 
in their CPS) and request for this certificate to be revoked if you want. Be 
sure to provide enough information, and a reasonable cause to perform this 
revocation.
___
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

[Peter Bowen]

On Mon, Sep 12, 2016 at 6:42 AM, Peter Kurrasch  wrote:
> I was thinking of more the server (cloud) side of things. I'm not familiar 
> enough with Cloudflare's service, but I imagine that if I have a server set 
> up I will also have access to my private key. If so, I now have access to the 
> private key of the other domains. Perhaps there are protections set up?

CloudFlare doesn't offer server hosting.  They are a content delivery
service which basically is a massive reverse proxy.  The private key
is never exposed to the customer.  The TLS connection is from client
to proxy and then a separate connection is made from proxy to
backend/origin.  So the key listed here, while for a number of
different customers, really represents a group of hosts behind a
shared reverse proxy.

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

[Peter Kurrasch]

Hi Erwann, 

I was thinking of more the server (cloud) side of things. I'm not familiar 
enough with Cloudflare's service, but I imagine that if I have a server set up 
I will also have access to my private key. If so, I now have access to the 
private key of the other domains. Perhaps there are protections set up?

Thanks for letting me know about the BR stipulation. I was hoping it would say 
something but didn't know what. 39 months seems too long though. A lot can 
happen in 3.5 years.


  Original Message  
From: Erwann Abalea
Sent: Monday, September 12, 2016 7:41 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Cerificate Concern about Cloudflare's DNS

Bonjour,

Le lundi 12 septembre 2016 14:30:56 UTC+2, Peter Kurrasch a écrit :
> I noticed there a several other domains listed on that cert besides Han's 
> (and wildcard versions for each).‎ Unless Han is the registrar or has some 
> other affiliation with those domains it seems to me there is a risk of some 
> private key compromise situation.

How is the risk of key compromise higher because there are several domain names 
in the certificate?

> Also, if I want to add a new domain to a cert that has several other domains 
> already on it, will I need to demonstrate control over all of the domains or 
> only the new one?

For a DV, if you demonstrated control less than 39 months ago, the CA MAY keep 
the result and issue the certificate for the previously verified domains.

Again, this is in the Baseline Requirements, not in this particular CA's CPS.
___
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: Cerificate Concern about Cloudflare's DNS

[Erwann Abalea]

Bonjour,

Le lundi 12 septembre 2016 14:30:56 UTC+2, Peter Kurrasch a écrit :
> I noticed there a several other domains listed on that cert besides Han's 
> (and wildcard versions for each).‎ Unless Han is the registrar or has some 
> other affiliation with those domains it seems to me there is a risk of some 
> private key compromise situation.

How is the risk of key compromise higher because there are several domain names 
in the certificate?

> Also, if I want to add a new domain to a cert that has several other domains 
> already on it, will I need to demonstrate control over all of the domains or 
> only the new one?

For a DV, if you demonstrated control less than 39 months ago, the CA MAY keep 
the result and issue the certificate for the previously verified domains.

Again, this is in the Baseline Requirements, not in this particular CA's CPS.
___
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

[Peter Kurrasch]

I noticed there a several other domains listed on that cert besides Han's (and 
wildcard versions for each).‎ Unless Han is the registrar or has some other 
affiliation with those domains it seems to me there is a risk of some private 
key compromise situation.

Also, if I want to add a new domain to a cert that has several other domains 
already on it, will I need to demonstrate control over all of the domains or 
only the new one?


  Original Message  
From: Rob Stradling
Sent: Monday, September 12, 2016 4:18 AM
To: Erwann Abalea; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Cerificate Concern about Cloudflare's DNS

On 10/09/16 15:43, Erwann Abalea wrote:

> In my opinion, the most plausible verification method in this case is the 
> last one: "Having the Applicant demonstrate practical control over the FQDN 
> by making an agreed-upon change to information found in the DNS containing 
> the FQDN";

Correct. That's what happened.

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

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

[Han Yuwei]

在 2016年9月10日星期六 UTC+8下午10:44:05，Erwann Abalea写道：
> Bonjour,
> 
> Le samedi 10 septembre 2016 14:37:40 UTC+2, Han Yuwei a écrit :
> > I am using Cloudflare's DNS service and I found that Cloudflare has issued 
> > a certficate to their server including my domain. But I didn't use any SSL 
> > service of theirs. Is that ok to Mozilla's policy?
> > 
> > Issued certificate:https://crt.sh/?id=31206531
> > My domain is BUPT.MOE
> 
> Technically speaking, Cloudflare did not issue a certificate, they requested 
> one and have it been issued by a CA.
> 
> I won't say wether it's ok for Mozilla or not, but it's at least authorized 
> by the CABForum Baseline Requirements.
> 
> Cloudflare was the Applicant (it's now the Subscriber), Comodo is the CA, you 
> are the Domain Name Registrant, your Registrar appears to be Hosting Concept 
> (Openprovider), the requested FQDN is bupt.moe.
> 
> The Applicant requested a certificate for the FQDN to the CA, the CA has 
> several methods declared in its CPS to verify that the Applicant is 
> authorized by the Domain Name Registrant to control the FQDN.
> 
> Of all these methods, some of them won't work here without your knowledge 
> (phone-call, sending you an email as listed in the Whois, sending an email to 
> admin/administrator/webmaster/hostmaster/postmaster@yourdomain).
> One of the remaining methods may have been possible only if Cloudflare 
> redirected the DNS record of your FQDN to one of their servers just for the 
> verification to pass ("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"), which could be considered problematic.
> In my opinion, the most plausible verification method in this case is the 
> last one: "Having the Applicant demonstrate practical control over the FQDN 
> by making an agreed-upon change to information found in the DNS containing 
> the FQDN"; for example asking the Applicant to add a CA-chosen random value 
> in a TXT record of the FQDN.
> 
> Since you delegated your DNS server to Cloudflare, you implicitly allowed 
> them to perform this certificate request on your behalf.
> 
> 
> 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.

Thanks for your time.

So when I delegated the DNS service to Cloudflare, Cloudflare have the 
priviliage to issue the certficate by default? Can I understand like that?
___
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

[Erwann Abalea]

Bonjour,

Le samedi 10 septembre 2016 14:37:40 UTC+2, Han Yuwei a écrit :
> I am using Cloudflare's DNS service and I found that Cloudflare has issued a 
> certficate to their server including my domain. But I didn't use any SSL 
> service of theirs. Is that ok to Mozilla's policy?
> 
> Issued certificate:https://crt.sh/?id=31206531
> My domain is BUPT.MOE

Technically speaking, Cloudflare did not issue a certificate, they requested 
one and have it been issued by a CA.

I won't say wether it's ok for Mozilla or not, but it's at least authorized by 
the CABForum Baseline Requirements.

Cloudflare was the Applicant (it's now the Subscriber), Comodo is the CA, you 
are the Domain Name Registrant, your Registrar appears to be Hosting Concept 
(Openprovider), the requested FQDN is bupt.moe.

The Applicant requested a certificate for the FQDN to the CA, the CA has 
several methods declared in its CPS to verify that the Applicant is authorized 
by the Domain Name Registrant to control the FQDN.

Of all these methods, some of them won't work here without your knowledge 
(phone-call, sending you an email as listed in the Whois, sending an email to 
admin/administrator/webmaster/hostmaster/postmaster@yourdomain).
One of the remaining methods may have been possible only if Cloudflare 
redirected the DNS record of your FQDN to one of their servers just for the 
verification to pass ("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"), which 
could be considered problematic.
In my opinion, the most plausible verification method in this case is the last 
one: "Having the Applicant demonstrate practical control over the FQDN by 
making an agreed-upon change to information found in the DNS containing the 
FQDN"; for example asking the Applicant to add a CA-chosen random value in a 
TXT record of the FQDN.

Since you delegated your DNS server to Cloudflare, you implicitly allowed them 
to perform this certificate request on your behalf.


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

Cerificate Concern about Cloudflare's DNS

[Han Yuwei]

I am using Cloudflare's DNS service and I found that Cloudflare has issued a 
certficate to their server including my domain. But I didn't use any SSL 
service of theirs. Is that ok to Mozilla's policy?

Issued certificate:https://crt.sh/?id=31206531
My domain is BUPT.MOE
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy