Cloudflare gets wildcard certs for a domain using their DNS-only service | Hacker News Reader

Cloudflare gets wildcard certs for a domain using their DNS-only service

groups.google.com

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

Would pinning mitigate this?

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

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

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

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.

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.

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/ [1] https://github.com/cabforum/documents/blob/master/docs/BR.md

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.

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.

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

1. hlandau puts it correctly. It decreases security. So you sneaky terms of service do not apply.

As for #2, it looks like there's a good way to revoke cloudflare's automated wildcard certificate generators:

"In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL NOT accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant's verified written request."

That someone needs to write ALL CA's and explicit revoke authorization showcases how bad this is.

This is absurd. You don't need to make certs for SSL sites, you can proxy SNI without every touching the real connection. HAProxy handles this well: https://www.haproxy.com/doc/aloha/7.0/deployment_guides/tls_...

This is a horrible practice. BAD BAD BAD. No one cares about your terms of service, you need to rewrite that shit.

>explicitly permitted by our Terms of Service[0]. See S7.4: "Other changes to increase performance or security of your website."

That's implicit, not explicit.

Reply on news.ycombinator.com