Subject: [Acme] tls-alpn-01 spec: TLS-SNI history

From: Felipe Gasper <[email-masked]>
Date: Tue, 19 Jun 2018 20:30:32 -0400

Having read over the history of TLS-SNI as reported in the draft spec, I feel like it might be prudent to mention that a significant part of the failure of TLS-SNI was Apache httpd and its (nonsensical, IMO) behavior of sending certificates for domains that don’t match the SNI request.

The write-up mentions “service providers”; for what it’s worth, I feel like a more complete and accurate picture would also indicate that “popular server software” (e.g., Apache … maybe others?) will happily serve up a certificate that has no connection with the SNI request, and that this is also a significant part of why TLS-SNI did not work.

-Felipe Gasper
Mississauga, ON

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Jun 2018 12:34:45 +0300

On Tue, Jun 19, 2018 at 08:30:32PM -0400, Felipe Gasper wrote:
> Having read over the history of TLS-SNI as reported in the draft
> spec, I feel like it might be prudent to mention that a
> significant part of the failure of TLS-SNI was Apache httpd and
> its (nonsensical, IMO) behavior of sending certificates for domains
> that don’t match the SNI request.
> 
> The write-up mentions “service providers”; for what it’s worth, I
> feel like a more complete and accurate picture would also indicate
> that “popular server software” (e.g., Apache … maybe others?) will
> happily serve up a certificate that has no connection with the SNI
> request, and that this is also a significant part of why TLS-SNI did
> not work.

My understanding was that catastrophic problem was not the default-
vhost behavior of Apache or Nginx, altough that could casue security
issues. But instead, the problem was  that many hosting provoders let
one claim arbitrary hostnames on FCFS basis. This let attacker upload
arbitrary validation certificates to be served, and due to how TLS-SNI
worked, this lead to misvalidation.

TLS-ALPN addresses the latter problem by requiring the server_name to
match the validation target (which is AFACIT also required by the
Baseline Requirements). This stops claiming arbitary names from
allowing misvalidations.

The TLS-SNI-01 included was default-vhost countermeasures, but those
were dropped from TLS-SNI-02, and from what I can tell, were not
actually used.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 20 Jun 2018 08:45:48 -0400

> worked, this lead to misvalidation.

This is correct, although it was not necessarily dependent on FCFS
behaviour - the issue would still exist because there was no implicit or
explicit binding between the ACME challenge name and the name being
validated in the protocol. That, combined with service providers reliance
on DNS to resolve conflicts, lead to these issues.

I'm not aware of any of the issues that were responsibly disclosed to
browser vendors having been related to Apache configuration.

> Baseline Requirements). This stops claiming arbitary names from

Note: The Baseline Requirements do not require this.

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 21 Jun 2018 12:40:49 +0000

> TLS-ALPN addresses the latter problem by requiring the server_name to match
> the validation target (which is AFACIT also required by the Baseline
> Requirements). This stops claiming arbitary names from allowing
> misvalidations.

This was certainly the intent.  Never in over two years of some pretty
detailed discussions about the mechanics of validation did anyone ever
propose it was reasonable to validate domain name A by contacting
the web server for a name that is not A (except for the approved the _prefix 
stuff).

I realize that after it was pointed out that TLS-SNI was horribly broken
in this regard, there were attempts by some to retroactively claim that
such behavior was compliant, but I always found those explanations a
bit tortured and unconvincing.  Certainly if I a large commercial CA had
made them, they would have been laughed at and ridiculed.

I would actually love to work with some people on updating the CABF
method 10 validation requirements in order to properly express the
security requirements that ALPN-01 satisfies.  The whole TLS-SNI
experience showed that Method 10 does not have sufficiently rigorous
requirements to guarantee it actually validates what it claims to validate.
Since the CABF VWG is currently working on adding more security rigor
to all the approved validation methods, it would be a great time to fix
up Method 10.

ALPN-01 is a much better validation method, and I'm very thankful
to all the people who worked hard to come up with a replacement,
which as far as I can tell from looking at it briefly (I wish I had more time)
looks pretty secure and robust.

-Tim

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 21 Jun 2018 10:56:36 -0400

On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek <[email-masked]>
wrote:

> match

That's not what is done under TLS-SNI.

> made them, they would have been laughed at and ridiculed.

Considering that large commercial CAs similarly interpreted the language as
described, I don't think this claim is well-supported. At the time of
TLS-SNI, it was seen as acceptable practice, and indeed, judging by the
minutes, CAs that similarly interpreted it as such were actively
participating in the validation WG and explicitly suggesting equivalent
solutions.

> looks pretty secure and robust.

I think it's good for CAs to look at improving validation requirements. I
think an easier way, however, than that attempt to describe prosaically
what TLS-ALPN expresses from guarantees is a simple and explicit
requirement to use TLS-ALPN. To that end, the question for TLS-ALPN spec is
whether it sufficiently expresses the expectations for where things go
right - and the handling mode for errors along the way. Thus, if there is
any time or energy for fixing Method 10, it seems that diverting it to
TLS-ALPN and ensuring it's well-specified in terms of failure handling and
expectations is the best way to achieve that laudable goal.

---

From: Felipe Gasper <[email-masked]>
Date: Thu, 21 Jun 2018 12:09:55 -0400

> On Jun 21, 2018, at 10:53 AM, Ilari Liusvaara <[email-masked]> wrote:
> 
> On Thu, Jun 21, 2018 at 09:53:07AM -0400, Felipe Gasper wrote:
> 
>> I would guess that the reason why Apache didn’t get much grief over
>> TLS-SNI is that many--most?--hosting services require a certificate
>> to match one or more domains on the associated Apache virtual host.
>> But that’s not universal by any stretch.
> 
> Also, getting the default virtual host on most hosting services is
> probably not easy. And without default vhost, you can only answer to
> names you have.

At least one entity on every IP address has it. And it’s trivial for anyone to check to see who it is.

-FG

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 21 Jun 2018 17:40:46 +0000

So the disagreement is whether the it is sufficient to merely use the name for the

DNS lookup, and then accept whatever happens afterwards, or whether the intent 

was that the web page should be retrieved in much the same way as it is retrieved by

browsers.  Matching them as closely as possible makes the validation more reliable.

Unfortunately, historically, the requirements are underspecified, and there is freedom

to implement the validation mechanism badly.  There are improvements 

that were discussed in the excellent discussion in Virginia, but even today, we

aren’t there yet.  So yes, it is possible by using a very strict, technical reading,

an argument can be made that TLS-SNI is compliant.

I’m just not a fan of that argument.  When the BRs say “retrieve a […] web page”, I

believe that includes a responsibility to interpret that provision in a way that meets

the intent of the validation method, and doesn’t introduce security risks.

-Tim

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 21 Jun 2018 13:47:35 -0400

> browsers.  Matching them as closely as possible makes the validation more

I think TLS-ALPN documents why this is true, but we know multiple CAs that
implemented either TLS-SNI or alternatives viewed it the same at the time.
I am greatly appreciative of hindsight being 20/20, but I think it's
important to recall that it is hindsight. As part of the introduction of
3.2.2.4.10, CAs were actively discussing about how this avoids the need to
do such matches, and the CA/Browser Forum Validation WG acknowledged it as
a correct interpretation. This is not about strict interpretations - this
is about documented and uncontested discussion in the Validation WG.

However, as to the remainder of the message, it seems we're echoing each
other - that a well-specified TLS-ALPN that concretely documents the
processing mode is of great benefit to the community, both in terms of
client implementers knowing what edge cases to expect that may cause an
ACME server to reject their response, and ACME servers to consider in
implementing when considering the validation level of the client's request.
My hope, then, is that any energy that might be directed at trying to
duplicate this work in 3.2.2.4.10 in the CA/Browser Forum might otherwise
be more productively and holistically directed at this effort within the
IETF and TLS-ALPN, allowing both broader participation and review, and
resulting in a state such that 3.2.2.4.10 can simply be replaced,
wholesale, with a statement "Using TLS-ALPN as specified is acceptable".