How secure is it to have web server respond statelessly to http-01 challenges?

Help
1

As per RFC8555 section 8.1, the key authorization is $token.$thumbprint, where the thumbprint is a secure hash of the public key to the account key (RFC7638).

Thus, I am considering making my HTTP server respond $1.THUMBPRINT for every \/\.well-known\/acme-challenge\/([^\/]+) requests, making it much easier than having the ACME client dynamically writing the challenge file into webroot or dealing with dynamic DNS updates.

Question follows: How secure it is? In the old way, the web server only responds to known challenge tokens (got from ACME server) for a very short of time; In the new way, the web server always responds to whatever string the client sends, and one can even GET /.well-known/acme-challenge/114514 to get 114514.THUMBPRINT immediately.

Although it is clear that we cannot trivially brute force a private key that matches the same thumbprint, always responding to any challenge still sounds scary to me, and users can also easily get my thumbprint.

Popular clients like acme.sh already supported this scheme, in its Stateless mode. I am wondering if setting it up would significantly reduce the security of my domain?

Thanks in advance.

1 Like
2

that's in effect pinning a acme account to authorize that subdomain: not sure you can use account. and keep mind even if you break sha256 you'd only get account's public key only, and you'd have much bigger problem you brake sha256-preimage: you can just forge certificate with same have with legit certificate.

3

I'm pretty sure one of the big web hosts was doing exactly this to answer http challenges, might have been GoDaddy, might not.

It's as secure as your private key is, public keys are public by design, and it probably depends on what you are hosting as to whether you are worth targeting.

If I had that computational power available I'd probably go after Satoshi's wallet key instead, thereafter I doubt I'd be looking to crack anymore keys.

1 Like