But removing the restriction would mean that the CA is free to do either
HTTP or HTTPS, and the client doesn't know what to expect. So if my port
80 is firewalled, I'm still not in good shape.
Thanks,
Yaron
On 30/05/17 18:38, Richard Barnes wrote:
On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <[email protected]
<mailto:[email protected]>> wrote:
I'm not sure I understand why the section that describes HTTP
validation so specifically forbids using HTTPS.
This was because of the default-vhost attack.
https://ietf-wg-acme.github.io/acme/#rfc.section.11.2
Given that we don't really have any data on how common this
vulnerability is, I'm split on whether to keep the restriction.
--Richard
On the other hand, I can think of use cases where I would want
*only* HTTPS authorization:
- The server only supports HTTPS, and perhaps port 80 is blocked
by a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the
server has a perfectly valid HTTPS cert. Or migrating from one
ACME CA to a different one.
- I would like to ensure (using CAA records) that my CA is not
subject to a DNS cache corruption attack - a threat that the ACME
Security Considerations specifically mention.
I would suggest that we specify a HTTPS validation that's exactly
like http-01, except that it runs over authenticated HTTPS.
Thanks,
Yaron
_______________________________________________
Acme mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/acme
<https://www.ietf.org/mailman/listinfo/acme>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
