Subject: [Acme] ACME -06: HTTPS authorization

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 May 2017 18:32:51 +0300

I'm not sure I understand why the section that describes HTTP
validation so specifically forbids using HTTPS. 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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 May 2017 11:38:29 -0400

On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <[email-masked]>
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-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 30 May 2017 18:45:57 +0300

>     like http-01, except that it runs over authenticated HTTPS.

The issue is that many webservers just pick the first vhost they find
as default vhost, and attacker might be able to make oneself the
default vhost for HTTPS (HTTP is seemingly also subject to similar
behavior, but it is controlled by different options).

If attacker can get itself as default vhost, he can pass validation
for any domain name that isn't explicitly configured (for HTTP or
HTTPS, depending on what is used for valdiation).

-Ilari

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 May 2017 18:47:59 +0300

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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     validation so specifically forbids using HTTPS.
>
>
> 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.
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 30 May 2017 11:49:43 -0400

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-masked]>
wrote:

> 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
>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 May 2017 19:04:36 +0300

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-masked] 
>     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 Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     <https://ietf-wg-acme.github.io/acme/#rfc.section.11.2>
>>
>>         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.
>>         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
>>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 30 May 2017 19:42:07 +0300

> alongside "http-01" (which is always HTTP).

One idea would be to require matching SAN in certificate (but not
trusted signer nor in-validity-window). That is required anyway for
HTTPS site selection on webservers to operate sanely.

Lack of trusted signer requirement allows using self-signed certs
for the initial validation and lack of in-validity-window allows
renewing an expired certificate.

However, that wouldn't fix the issues if the host lets one upload
arbitrary certificates for one's vhost (however, if one can do that,
then even TLS-SNI-02 is vulernable).

-Ilari