The attack described below wouldn't work on Let's Encrypt because it hasn't implemented the order list feature yet, so this is more of a hypothetical attack for anyone who finishes implementing the standard.
Scenario: 1) A hacker secretly stole a copy of an account private key months ago 2) This hacker periodically polls that account's info and looks the order list 3) Today the hacker gets lucky: the order list reveals a pending order that hasn't been fulfilled yet 4) The real DNS/HTTP website owner finishes authorizing the certificate, but has not yet finalized the order 5) The hacker swoops in at the last minute and submits a CSR to /acme/order/abc123/finalize, winning the race condition to finalize the request 6) The CA grants the request, presuming that because the hacker has the account key it must be the same client who proved ownership of the domain Now the hacker has obtained a signed certificate for a domain without ever having control of DNS or HTTP serving for that domain. Some ideas to prevent this attack: - Don't support order listing in the standard. Seems like people have been doing fine so far without it. - Support listing valid and invalid orders, but not pending orders - Have an additional, temporary, order-specific secret that's used both when creating an order and when finalizing it. This allows the order list to reveal the existence and status of an order without revealing the extra secret a client would need to finalize it. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
