Draft: draft-ietf-acme-acme

Commentary: Server side request forgery ( SSRF ) is possible through ACME when using  because an attacker can use HTTP 3xx redirects to make the ACME verifier server perform an HTTP GET of any URL . Additionally ,  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 wo n't actually affect anything . But , if the ACME server returns any part of the HTTP body in error messages ( like  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 do n't include the HTTP body if a redirect was followed . Also , this is mostly mitigated by the actual implementation of Let 's Encrypt and  . Notably , only 128 characters ( maxResponseSize ) of the HTTP body are . And it does n'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 to before creating this GitHub issue . This is not an issue for Let 's Encrypt . ) 
 Thanks for reporting ! Can you post this to the mailing list for further discusion ? Not everyone who participates in the WG follows the GitHub repo .
Paragraph (version B):
Server-Side Request Forgery (SSRF) attacks can arise when an attacker
can cause a server to perform HTTP requests to an attacker-chosen
URL.  In the ACME HTTP challenge validation process, the ACME server
performs an HTTP GET request to a URL in which the attacker can
choose the domain.  This request is made before the server has
verified that the client controls the domain, so any client can cause
a query to any domain.
Paragraph (version B):
Some server implementations include information from the validation
server's response (in order to facilitate debugging).  Such
implementations enable an attacker to extract this information from
any web server that is accessible to the ACME server, even if it is
not accessible to the ACME client.
Paragraph (version B):
The risk of SSRF through this channel is limited by the fact that the
attacker can only control the domain of the URL, not the path.
Nonetheless, in order to further limit the SSRF risk, ACME server
operators should ensure that validation queries can only be sent to
servers on the public Internet, and not, say, web services within the
server operator's internal network.  Since the attacker could make
requests to these public servers himself, he can't gain anything
extra through an SSRF attack on ACME aside from a layer of
anonymization.
Paragraph (version B):
As noted above, DNS forgery attacks against the ACME server can
result in the server making incorrect decisions about domain control
and thus mis-issuing certificates.  Servers SHOULD verify DNSSEC when
it is available for a domain.  When DNSSEC is not available, servers
SHOULD perform DNS queries over TCP, which provides better resistance
to some forgery attacks than DNS over UDP.