Posting this to the list for discussion: https://github.com/ietf-wg-acme/acme/issues/136
Server side request forgery (SSRF) is possible through ACME when using http-01 because an attacker can use HTTP 3xx redirects to make the ACME verifier server perform an HTTP GET of any URL. Additionally, Boulder helpfully includes (part) of the HTTP body in the detail field of Unauthorized errors. In theory, an HTTP GET of any URL is idempotent and won't actually affect anything. But, if the ACME server returns any part of the HTTP body in error messages (like Boulder does), an attacker could potentially read sensitive data from internal servers. Typical targets for SSRF would be metadata services (like 169.254.169.254 in AWS or OpenStack), any not publicly exposed HTTP interface of the server's stack (like the HTTP API of the RabbitMQ management plugin), or any other internal HTTP server on the server's private network. Perhaps the IETF ACME protocol spec should acknowledge SSRF in its Security Considerations? One recommendation could be to not allow connections to internal network addresses. However, if someone wanted to use ACME for a private intranet CA, correct firewalling like that is much harder. The spec could also discourage including the HTTP body in an Unauthorized error's detail field. Or at least don't include the HTTP body if a redirect was followed. Also, this is mostly mitigated by the actual implementation of Let's Encrypt and Boulder. Notably, only 128 characters (maxResponseSize) of the HTTP body are returned by Boulder <https://github.com/letsencrypt/boulder/blob/51425cab815936d9f9ff2a2a6aef1aff75b5a042/va/va.go#L274>. And it doesn't seem possible to get Let's Encrypt to access HTTP servers on any port other than 80 or 443, even with a port number specified in the redirect URL, which limits what an attacker could access. (I reported this privately [email protected] before creating this GitHub issue. This is not an issue for Let's Encrypt.) -- Blake
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
