XSS via ACME implementations

[JuergenAuer]

Hi @hannob

@hannob

It turns out some implementations do this in a way that they don’t really care about the token, but always reflect whatever you request under the corresponding url (/.well-known/acme-challenge/token).

thanks. This is really not a good idea. My own client sends a 404, if the token is wrong.

But: There are sometimes curious questions:

[SOLVED] The client lacks sufficient authorization :: The key authorization file from the server did not match this challenge

M…

The key authorization file from the server did not match this challenge [U7Z05MbBan_sQRbagOsMUOrbrefGfGsWiYZqTbXdz_c.Mxd6puZz877ZrQ7u9cPPc2amincbkMvNFjbgIj9OlQU] != [U7Z05MbBan_sQRbagOsMUOrbrefGfGsWiYZqTbXdz_c.JQoYFoTtPDe2MIr4xFKqpRpt0eKti-HMnJ0BIl9eOjE]

The token is correct, the dot is correct. But the hash of the account key is wrong.

And: There were wrong ipv6 - settings, so ipv6 sends another content then ipv4.

Removing the ipv6 - AAAA record solved the problem.

So it looks that these hosters reflect /.well-known/acme-challenge/1234 with the content

1234.[Hash of the public account key]

With the consequence:

If Letsencrypt has this error validating a domain name, Letsencrypt could search all accounts to find the account with [Hash of the public account key] to find such a wrong reflection.