3 ms·

- request http://example.com/<path http://example.com/<path or query containing random token> - if random token is echoed in the response, and the HTTP respons

by sebcat 10y ago

- request http://example.com/<path http://example.com/<path or query containing random token> - if random token is echoed in the response, and the HTTP response code is 200, they consider that the applicant has control over the requested FQDN Do I understand their validation method correctly? If so, I wouldn't consider it very secure.

kodablah 10y ago
I believe this is essentially what ACME does when using the domain challenge, granted it likely requires a certain set of content to ensure your misconfigured webserver doesn't return 200 for all paths.
- ploxiln 10y ago
  ACME does not include the expected response in the path or query. So it can't be accidentally included in the response. EDIT: quote by Nick Lamb in the discussion linked: > ACME http-01 won't get tripped here because the checked content of the URL is very much not the random string (it's a JWS signature over a data structure containing that random string, thereby proving it was made by whoever the ACME server is talking to). But yes, doing something that _looks_ superficially like the ACME style of validation without such subtlety will trip you up.
  - deleted 10y ago
    [deleted]
- eridius 10y ago
  I haven't looked at ACME, but any properly-designed system should require the entire response to match some expected value instead of just searching for the value as a substring.
- andrewstuart2 10y ago
  As ploxiln mentioned, there's a lot more to ACME. ACME uses challenge-response validation, which is significantly more complicated than an echo. You've already sent a CSR to LetsEncrypt that contains your server's generated public key. LetsEncrypt then issues a challenge that your server must sign using the associated private key that it generated, and that only it has access to. Then LetsEncrypt validates the signature using the public key and checks that a) the signed data matches the nonce they sent as a challenge and b) the signature is valid given the known public key. This sufficiently guarantees the fact that you control both the domain name and the key associated with your submitted CSR. At that point, they sign and issue your certificate and send it back to you.
  - tialaramex 10y ago
    Almost. The way you've described only works if the ACME user also has access to the private key for the CSR. But that isn't true if you're using CSRs from some appliance you bought which doesn't let you change or view its private keys and doesn't implement ACME itself. That's a good secure design for the appliance so we don't want to discourage it. Thus, ACME doesn't do it that way. It has a separate key pair for the ACME protocol itself, the "account key" pair. Your challenge signature is signed with the private key for the ACME account. The ACME client never needs to know the private key for a CSR it presents, although in the easy-to-use default modes in popular clients like Certbot they do generate these keys too.

by sebcat 10y ago

kodablah 10y ago

I believe this is essentially what ACME does when using the domain challenge, granted it likely requires a certain set of content to ensure your misconfigured webserver doesn't return 200 for all paths.

ploxiln 10y ago
ACME does not include the expected response in the path or query. So it can't be accidentally included in the response. EDIT: quote by Nick Lamb in the discussion linked: > ACME http-01 won't get tripped here because the checked content of the URL is very much not the random string (it's a JWS signature over a data structure containing that random string, thereby proving it was made by whoever the ACME server is talking to). But yes, doing something that _looks_ superficially like the ACME style of validation without such subtlety will trip you up.
- deleted 10y ago
  [deleted]
eridius 10y ago
I haven't looked at ACME, but any properly-designed system should require the entire response to match some expected value instead of just searching for the value as a substring.
andrewstuart2 10y ago
As ploxiln mentioned, there's a lot more to ACME. ACME uses challenge-response validation, which is significantly more complicated than an echo. You've already sent a CSR to LetsEncrypt that contains your server's generated public key. LetsEncrypt then issues a challenge that your server must sign using the associated private key that it generated, and that only it has access to. Then LetsEncrypt validates the signature using the public key and checks that a) the signed data matches the nonce they sent as a challenge and b) the signature is valid given the known public key. This sufficiently guarantees the fact that you control both the domain name and the key associated with your submitted CSR. At that point, they sign and issue your certificate and send it back to you.
- tialaramex 10y ago
  Almost. The way you've described only works if the ACME user also has access to the private key for the CSR. But that isn't true if you're using CSRs from some appliance you bought which doesn't let you change or view its private keys and doesn't implement ACME itself. That's a good secure design for the appliance so we don't want to discourage it. Thus, ACME doesn't do it that way. It has a separate key pair for the ACME protocol itself, the "account key" pair. Your challenge signature is signed with the private key for the ACME account. The ACME client never needs to know the private key for a CSR it presents, although in the easy-to-use default modes in popular clients like Certbot they do generate these keys too.