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

[Daniel McCarney <[e-mail]>]

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

On Fri, Jan 19, 2018 at 9:43 AM, Daniel McCarney <[e-mail]>
wrote:

> If we use the "real" identifier for SNI, we'd limit that option to web
>> servers that natively support the ALPN value for ACME and can route
>> based on it.
>> Not sure how common this kind of setup is, if it's just a small subset of
>> HAProxy deployments it'd probably not have much of an impact.
>
>
> I agree this approach will limit compatible TLS servers but luckily
> HAProxy should be fully compatible.
>
> HAProxy has a "ssl_fc_alpn"[0] layer 5 fetch method that can be referenced
> in a "use_backend" directive to route based on the negotiated ALPN from the
> handshake. It looks like the feature has been present since HAProxy version
> 1.5 which hopefully means most HAProxy deployments will have access to it.
> As one data-point Ubuntu 16.04 LTS packages HAProxy 1.6.3 and should be
> able to build a ALPN-based routing solution similar to what was done for
> SNI.
>
> [0] - http://cbonte.github.io/haproxy-dconv/1.8/
> configuration.html#7.3.4-ssl_fc_alpn
>
> On Fri, Jan 12, 2018 at 10:29 AM, Patrick Figel <[e-mail]>
> wrote:
>
>> On 12.01.18 04:06, Roland Bracewell Shoemaker wrote:
>> > I'm actually going to roll back my thoughts on the SNI value. Thinking
>> > about this more I think it does actually make sense to revert to using
>> > the actual host name here.
>> >
>> > In the initial design of the TLS-SNI challenge the XXX.acme.invalid
>> > value was used as a way to allow servers to dynamically serve both
>> > regular and validation traffic. Since we would be using ALPN here we no
>> > longer need a special SNI value in order to differentiate validation
>> > traffic from regular traffic so this token value is no longer needed.
>>
>> One minor advantage of keeping the current acme.invalid scheme is that
>> it allows people to use SNI-based routing. Web servers like HAProxy
>> allow you to proxy requests (on the TCP layer) based on the SNI value,
>> so you could match "*.acme.invalid" and forward it to a validation
>> server that supports the new challenge and the ALPN ACME protocol, even
>> if the web server itself doesn't. If we use the "real" identifier for
>> SNI, we'd limit that option to web servers that natively support the
>> ALPN value for ACME and can route based on it.
>>
>> Not sure how common this kind of setup is, if it's just a small subset
>> of HAProxy deployments it'd probably not have much of an impact.
>>
>> Patrick
>>
>> [1]:
>> https://www.cloudoptimizedsmb.com/articles/20160409-00/using
>> -haproxy-to-split-letsencrypt-acme-challenges-from-regular-traffic
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>
>