
Cloudflare gets wildcard certs for a domain using their DNS-only service - michaelhoffman
https://groups.google.com/forum/#!topic/certificate-transparency/1tAcVS17wMM
======
jpalomaki
"With CloudFlare being in control of the DNS and having a wildcard certificate
without the domain owner's knowledge would give CloudFlare the possibility to
run a MITM on many, many domains without anybody noticing as the certificates
are valid and issued by a trusted CA"

This is how the system works when it comes to domain validated SSL certs.
Anybody who controls the domain's DNS, can get a trusted SSL certificate for
the domain from certificate vendor. As long as the DNS is controlled by third
party, revoking the existing certs does not make a big difference, since if
they want to do MITM, they can just get new certificates at any point.

~~~
btown
Would pinning mitigate this?

~~~
jpalomaki
Partly, but that requires the user has visited your site with their browser
before.

------
user5994461
> ... would give CloudFlare the possibility to run a MITM on many, many
> domains

A CDN is operating as a man in the middle, by design. It doesn't even make
sense to take about "MITM" in the context of CDN. If you have a problem with
that, don't sign up to a CDN.

------
matheweis
Hmm,
[https://news.ycombinator.com/user?id=jgrahamc](https://news.ycombinator.com/user?id=jgrahamc)
seems like the type to call something like this "hella creepy" ... comments?

------
jp_rider
Wow, same for my website (using Cloudflare for DNS-only). How do we get these
revoked?

Edit: If you're using Heroku, the zerigo_dns addon makes it easy to switch to
Zerigo.

------
kevin_b_er
The takeaway: Cloudflare fraudulently misrepresents your authorization to
issue a certificate.

It would appear the CA baseline requirements are insufficient to deal with
providers such as cloudflare. Comodo got authorization via control of DNS,
which not differentiated from the actual domain name owner. So when cloudflare
fraudulently impersonates the domain name owner it is not identifiable.

~~~
prdonahue
That may be your "takeaway", but it's wrong on several fronts:

1\. There's nothing "fraudulent" about providing a service explicitly
permitted by our Terms of Service[0]. See S7.4: "Other changes to increase
performance or security of your website."

2\. Continuing on #1, the BRs[1] provide explicitly for an agent to apply for
certificates on behalf of another person. Look for the defined term,
"Applicant Representative" and see 3.2.2.4.7 for DNS changes as permitted for
DV validation.

[0] [https://www.cloudflare.com/terms/](https://www.cloudflare.com/terms/) [1]
[https://github.com/cabforum/documents/blob/master/docs/BR.md](https://github.com/cabforum/documents/blob/master/docs/BR.md)

~~~
hlandau
It is unclear to me how issuing certificates you have no intention of using in
any way constitutes "other changes to increase performance or security of your
website."

In fact it can only decrease security, as it increases the number of valid
certificates in existence for a domain, and the number of certificates
available to be compromised.

Logically, you can only claim that this behaviour falls under "other changes
to increase performance or security of your website" if you actually make use
of the SSL certificate after obtaining it.

~~~
prdonahue
We don't know /a priori/ whether the user will, as 99%+ of zones on us do,
reverse proxy traffic through us. The vast majority do, and thus your
statement of "you have no intention of using" is wrong; we intend to use this
certificate, and almost always do.

The reason that a certificate is issued on zone activation is that issuance
takes non-zero time. And the second a user decides to route traffic through
us, we need to have a certificate in place terminating TLS otherwise the user
will experience downtime due to their visitors not being able to connect via
HTTPS.

~~~
rguiliani
you oblivious mouthpiece. The vast majority are sheeple who TRUST YOU. YOU ARE
ABUSING THAT TRUST.

