Not that big of a deal, but interesting.
The HTTP-01 challenge can only be done on port 80.
All that being said, this workflow is rather odd. We’re talking about a customer who uses an HTTP-01 challenge to get a certificate for a domain that is proxied by Cloudflare’s TLS-terminating proxy. Setting this up in a way that is useful is dramatically harder than letting Cloudflare deal with the certificate. Maybe the idea is that the user could example proxying and get something vaguely secure without any reconfiguration at all all on the origin machine? How many users have ACME configured and are willing to run a wide-open origin behind Cloudflare anyway?
The modern web requires secure (HTTPS) context for many things to work, so it’s commonplace to do so “HTTPS enforcement”; all requests are forcibly upgraded to HTTPS. However, you can’t do that to the CA when it’s performing a http-01 challenge validation. This necessitates a “well known” URL route be used for challenges so that they can very deliberately take a different code path that doesn’t enforce HTTPS (and be routed differently).
This is true of basically every ACME client used for http-01 challenges, not just cloudflare. So while they’ve unfortunately missed the mark on correctly explaining the mechanism at play here, I hope that I succeeded in making it a bit more clear. Other implementations are, of course, similarly exploitable.
Bizarre choice.
nick-sta•2w ago
cowsandmilk•2w ago
nightpool•2w ago
I'm not sure how realistic this is in practice. Does anyone actually configure Cloudflare WAF this way? (As opposed to, e.g., Cloudflare's dedicated zero-trust networking product, which I think works completely differently?)
nightpool•2w ago
That means that any client that relies on this WAF to authenticate users (like with the NextJS example, where some information that would not be considered sensitive "internally" is exposed externally) or cover over security holes in their application (like with the Spring example, where the path traversal vulnerability in Spring is normally caught by Cloudflare before Spring can see it) would have this assumption violated
tracker1•2w ago
I think it's not a severe issue in most cases, and maybe something worth noting or addressing if you are at least aware of it, you can just 404 without content, for example in the .well-known/ path. I run most of my apps behind Caddy, which handles that path itself and doesn't forward requests to that path, so I'm curious how it handles it tbh.
I'm also not sure that there's a clear/good fix for this, since CF is allowing the traffic through so that ACME negotiation can work against the final application host.