Yes, exactly.
On 30/05/17 18:49, Richard Barnes wrote:
That just argues for adding for an "https-06" (which is always HTTPS)
to go alongside "http-01" (which is always HTTP).
On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer <[email protected]
<mailto:[email protected]>> wrote:
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
<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
