Please, confirm "no certificate" behavior

I assume that my origin CANNOT be accessed if it is 1/ proxied via Cf; 2/ Cf does not have a valid certificate. This is what I have in test:

curl -kv my_https_link

  • Trying 2606:4700:3030::6815:5ae7:443…
  • Connected to xxx (2606:4700:3030::6815:5ae7) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • TLSv1.0 (OUT), TLS header, Certificate Status (22):
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.0 (IN), TLS header, Unknown (21):
  • TLSv1.3 (IN), TLS alert, handshake failure (552):
  • error:0A000410:SSL routines::sslv3 alert handshake failure
  • Closing connection 0
    curl: (35) error:0A000410:SSL routines::sslv3 alert handshake failure

Could you confirm this is general, and my origin cannot be accessed by any other command or options/versions to curl?

I’m not sure I fully understand the reason for this question, but if you have enabled the proxy on the DNS record and there is no Edge Certificate active for your domain, then you would see an SSL handshake failure because we do not have a valid certificate to serve for the hostname.

Hi @simon , thanks for the quick response. I didn’t include the reason: it’s a complex workflow with workers and resolveOverride feature that works fine. So, in essence, my zone file has AAAA records with servers that shouldn’t be accessed outside workers. Having secrets in a zone file isn’t best practice from general DNS standpoint, but in case of resolveOverride there would be no alternative.

Back to my question. Curl -k option makes curl bypass certificate errors, so I just wanted to make sure Cf servers cut it right there - without ever going to the origin.

I think it’s risky to rely upon this behaviour. If you want to be sure that anyone directly accessing that hostname cannot reach the origin you have defined for it in DNS, deploy a firewall rule which blocks all traffic matching that hostname.

Hi @simon - would you like to expand on the risk? What could happen?

Firewall isn’t very good idea. First of all, I am not in the mood to track Cf IP address space. And if we talk WAF it is already there but it isn’t very helpful for high RPS numbers. So, we really do need to rely upon this behavior. And it might be worthwhile to lay it out before product folks who look after resolveOverride feature, and I bet they are not the same folks looking after DNS behavior…

@vitaly.zuevsky although the behaviour today is to fail the TLS handshake if we do not have a matching certificate, I am not sure it’s wise to assume that will always be the case and it’s also possible to accidentally deploy an edge certificate by enabling a feature like Total TLS or Universal SSL - so it’s not the right place logically to be “blocking” a request for a hostname. Relying on an SSL feature to “firewall” for you feels architecturally a bad idea.

Thus, the Cloudflare Firewall rules would be the best place to deny / block requests for a specific hostname. I’m not sure what you mean by “isn’t very helpful for high RPS numbers” - can you expand on that?


Except for all the alternatives.

Cool beans. Leaving your server exposed to the internet seems like a great plan. I am sure everything will work out well.

@simon I think I misunderstood - I was talking about firwall at my origin, and layer 5-7 protocols (waf) would still consume fair bit of cpu cycles (hence it’s not helpful at high rps rates of attack).

I can see now you were referring to a WAF at Cf edge, right? I haven’t used it before. I will check what it can. Meanwhile, anything specific in that WAF that comes together with resolveOverride?

That’s correct - you would use the WAF to deploy a Firewall Rule that blocks any requests using the HTTP Host you don’t want to be accessible. This will not block your “resolveOverride” behaviour because those requests will not match that HTTP Host.

I should also add that’s its worth having another layer of defence at your origin to drop traffic on that hostname, expecting that Cloudflare will of course drop 100% of the traffic before it reaches you. This would offer extra protection in case you misconfigure something on Cloudflare :slight_smile: .

yes, that’s already in place at the origin. I will mark it as the solution. Thanks again for your guidance @simon.

1 Like

No problem - glad you have some options now!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.