Pattern for validation tokens

[orangepizza]

because the way boulder generates is base64url encode of 32byte string, but boulder isn't only acme server and rfc8555 doesn't require much about token itself: just it's something can passed as string
while it'll need to pass (37/64)^43 odd(there is no underbar too) to be have all cap token, and while odd for that is like 50 times in trillion tries

[webprofusion]

Anyone could fake a /well-known/acme-challenge / request fairly convincingly and the only difference would be the source IP.

If your public http server has a vulnerability that means you cannot safely accept a fake challenge request you could just address that vulnerability and continue as normal, you could also consider just not load balancing challenge requests and send them to a static server that's as lightweight as possible (you should be able to serve millions per hour with a dedicated solution).

If you're worried about denial of service from the sheer weight of http requests I would suggest as others have said to push your http (challenge) responses out to an edge server that has automated denial of service detection, away from your main application infrastructure. e.g. cloudflare, possibly with Workers to wrap requests.

If you still don't want to receive faked acme challenges switch to DNS validation and block http requests (or request patterns) as normal.

As an aside, it's interesting that you have a reasonably complex http challenge response system (load balanced, cached/db etc) and that someone who knows that is choosing to attack it, presumably so that you will incur cloud computing costs. Start by alerting the source IP block owners that an abuse is happening, that does work well in the case of AWS etc because they really do follow up.

[maxmayer]

I always prefer to act differently, I don't like to rely on probabilities, but since there are no alternatives or even the possibility of changing this I will have to do in this way.

Thank you all

[jvanasco]

@maxmayer

In a cloud scenario, multiple servers handle the validation request for issuing a certificate (http-01), so the token/auth association must be placed in some form of shared storage between the servers (e.g., DB, cache).

Reiterating what @mcpherrinm suggested above, a popular method to handle these multi-node situations is to use redirects onto a single domain that will handle all ACME processes. While they suggested using a static host, many people with multi-node integrations will run the ACME service on a single node (e.g. acme-authz.example.com) and redirect /.well-known/acme-challenge for all domains on their network to that host.

@maxmayer

Why has Let's Encrypt never thought of a way to verify the token that clearly doesn't decrease the security of the token itself?

Because your concern has not been considered an issue to anyone involved in the RFC or operating an ACME service.

@maxmayer

Here are some examples:

/.well-known/acme-challenge/KD1D7TSUMLR8S7Y4GGOO-U7QKQ0QNHATGAZC32388IQ
/.well-known/acme-challenge/TFHZJ4EE6GANA440SICB9RTECU1ZA3X8GEJEUTQJCQP

I see lots of those on my systems. It's usually just scriptkits looking for vulnerabilities and probing to see if anything is installed on those things (similar to how some actors track registrations and dns records, then try to do a timing attack to corrupt a wordpress/etc install - though many hosts and apps now protect from that vector).

If you are truly paranoid, I would suggest the following:

1- Use CAA records to lock down the domains on your system to only use LetsEncrypt.
2- Block the all-caps due to statistical improbabilities.

The reason for using the CAA record is this: there is no guarantee or knowledge about the format that other CAs use for tokens. If you lock down the issuance to LetsEncrypt only, and someone on your network tries to use another CA, they will get an informative error about the CAA record and not just a failure during the authorization process.