Hey Blake, Thanks for bringing this up. I agree that this would be good to document in the Security Considerations, or maybe within the Operational Considerations below. Would you like to take a shot at a PR?
Thanks, --Richard On Thu, Jun 9, 2016 at 8:30 PM, Blake Burkhart <[email protected]> wrote: > 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 > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
