Hi Tim,

Thanks for sharing your thoughts. This was the first time I've heard about
sort of SNI multiplexing middleware in the context of IPv6 hosting.

I'm newer to the list/draft process but I suspect your idea of using
"x.y.token.acme.client2-example.com" to support the SNI multiplexing
will run counter to the intent behind using the ".acme.invalid" suffix as
described in the current draft. Perhaps someone with more historical
context can
help clarify why that particular suffix strategy was selected.

It would help me understand your feedback better if you could speak to why
doesn't make more sense for users of this sort of middleware to favour the
HTTP-01 or DNS-01 challenge type. My own opinion leans towards thinking that
using a more appropriate challenge type is preferred to trying to address
middleware in the context of the TLS-SNI-02 challenge design. This class of
middleware can introduce all sorts of complication that might end up
significantly complicating the challenge design.

- Daniel/cpu

On Wed, Oct 12, 2016 at 6:45 AM, Tim Small <t...@seoss.co.uk> wrote:

> Hello,
> Having read draft-ietf-acme-acme-02, and made a number of early
> deployments using the tls-sni-01 mechanism, I thought I'd highlight what
> I perceive to be a possible shortcoming with the tls-sni-02 draft.
> It's becoming more wide-spread (as a result of IPv4 exhaustion) to
> deploy TLS SNI "switches" to provide IPv4 connectivity to autonomously
> managed web servers.
> The typical deployment pattern is that a web server is assigned a
> publicly accessible IPv6 address only - this can be used for direct
> management and direct IPv6 https requests etc.  The TLS request are
> terminated on the web server itself.
> The customer is also informed of an IPv4 addresses to be used for web
> access by IPv4-only clients, and asked to provide a list of FQDNs which
> they will serve.  IPv4 https requests are answered by proxy software,
> which direct the IPv4 https request to the correct web server's IPv6
> address (or an RFC-1918 IPv4 address etc.) based on SNI.
> e.g. this haproxy example configuration fragment:
> use-server customer1-staging if { req.ssl_sni -m beg
> staging.customer1-example.com }
> use-server customer2-live if { req.ssl_sni -m beg
> staging.customer2-example.com }
> I believe this will become increasingly common-place during the
> transition to IPv6, and the current form of tls-sni-02 makes it hard to
> use in this sort of environment.
> The problem comes when using tls-sni-02 ACME challenges:
> "The client MUST ensure that the certificate is served to TLS
> connections specifying a Server Name Indication (SNI) value of SAN A."
> i.e. the SNI string which the proxy sees during the challenge is always
> "SAN A" (x.y.token.acme.invalid), for any server for which it acts as
> the "https switch" for.
> ... so the proxy has no way of knowing which server the challenge
> request should be directed to.  Some mechanism by which the proxy can
> direct the request would be useful.
> One which may provide an easy route for the service providers offering
> this sort of setup (many would require no changes to their existing
> configuration at all) would be to append the FQDN in the TLS SNI value
> e.g. x.y.token.acme.client2-example.com
> The client in question may have limited or no influence on the
> configuration of the SNI proxy, so the more straight-forward the proxy
> configuration, the-better.
> For another example of a similar use-case with the same issue:
> https://scriptthe.net/2015/02/08/pass-through-ssl-with-haproxy/
> HTH,
> Tim.
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
Acme mailing list

Reply via email to