Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: