> 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. > Yep, I think this makes sense to include in the Security Considerations. Specifically we should reference the IANA Special-Purpose Address Registries, which Boulder / Let's Encrypt use to ensure we don't contact internal addresses during validation:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml > However, if someone wanted to use ACME for a private intranet CA, > correct firewalling like that is much harder. > This is a good point. Perhaps the guidance should be that an intranet CA that chooses to allow validation of special-purpose addresses should not allow requests from untrusted zones. > > The spec could also discourage including the HTTP body in an > Unauthorized error's detail field. > This is a tradeoff. For the public CA case, I think it is useful to be able to inform users what was received instead of the expected token, since it can help them debug the problem. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
