Re: [Acme] Fixing the TLS-SNI challenge type

[Ilari Liusvaara <[e-mail]>]

On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote:
> >
> > I agree this approach will limit compatible TLS servers but luckily
> > HAProxy should be fully compatible.
> 
> 
> Alas, there's nothing like hitting send on a message to a mailing list to
> make you think a little bit harder.
> 
> I overlooked the fact that it doesn't seem possible to select the
> certificate based on the ALPN, just the backend. That's not really the
> primary difficulty at hand. I suspect matching the request to the `bind`
> with the correct alpn is still going to be problematic if the server needs
> to respond to requests for the real identifier with both a certificate and
> a challenge response certificate.
> 
> I would be happy to be corrected :-)

Basically, for security, one needs to put the domain to be validated to
the SNI field. Not doing that was the reason for the TLS-SNI-01/02
vulernability.

AFAICT, the hard constraints are:

- No taking site offline when validating.
- The validation certificates are not publically trusted.
- SNI needs to be set to the domain being validated.
- Compliant with reasonably strict reading of "10 methods" (which
  essentially impiles the third point and using certificate to
  transmit data).

(I do not consider compatiblity with present software a hard
requirment).


Few ways that come to mind:

- Have "acme" ALPN and send validation certificate for that.
- Have some new TLS extension and send validation certificate for that.
- Have "acme" ALPN, establish data link and exchange an exported
  authenticator request/response over it (response carries an X.509
  certificate).


One also wants as good assurance as possible that the entity
terminating the TLS link approves the certificate. This entity may be
the applicatnt themselves (e.g., applicant's VPS with direct IP-
layer connectivity, or with SNI-level routing of unterminated TLS
connections), or it might not be (shared hosting).

The first and second method are much better there than the third
(any provoder that lets users claim ALPN protocols runs into trouble).
And of the first two, the second would be slightly more safe, but
probably not enough for it to be worth trouble.


However, one should keep in mind that if hosting provoder allows
claiming https hosts regardless of http ones (some provoders have
problems of this sort[1]), they would probably also approve the
certificate requests for the owner of the https host.


[1] The Detectify article started with one unnamed such provoder
I think it would have been easy to find a CA that would have
validated the domain as-is, and it was only due to author's fixation at
using LE that the TLS-SNI issue was discovered.



-Ilari