There are a few attack scenarios that "acme.invalid" attempts to account for. It protects sites like blogs that may allow users to select subdomains and upload certificates (x.y.token.blog.com would be potentially vulnerable).
Multiple virtual hosts on shared hosting environments are also a concern. Using "acme.invalid" gives a clear indicator to the provider that the certificate is intended for a challenge. "invalid" is a reserved TLD. https://tools.ietf.org/html/rfc2606#section-2 In response to Tim. I agree that including the domain within the challenge would be beneficial for many deployments. The format of "x.y.token.domain.acme.invalid" has come up in the past. The idea was raised to the group at IETF 94, but was rejected for concern of enterprise deployments going over the DNS byte limit. (DNS names are restricted to a length of 253) *https://github.com/ietf-wg-acme/acme/issues/23 <https://github.com/ietf-wg-acme/acme/issues/23>* http://ietf.org/proceedings/94/minutes/minutes-94-acme To be fair, the DNS challenge suffers from the same problem with the length of the DNS entry, though to a lesser degree. One of my colleagues, Nick Felt, recently ran a censys.io query to see how many of the existing domains contained within certificates would be unable to solve SNI challenges formatted like "x.y.token.domain.acme.invalid". He found that the length restriction would have virtually no impact on the existing publicly visible ecosystem. There were only 10 domains over 170 characters long. Perhaps including the domain should be reconsidered. Best, James On Thu, Oct 13, 2016 at 9:39 AM, Ben Irving <[email protected]> wrote: > Hello, > > I have ran into a very similar use case. In my case I'm using Haproxy to > route tcp requests based on the server name indication to upstream web > servers where the TLS request is terminated. The ACME client is also > running on these upstream web servers. I'm forced to use HTTP-01 challenges > and am forced to open up port 80 as well on these upstream servers, which I > don't want to do. I don't expect the protocol to solve my particular use > case, but I'm also curious as to why acme.invalid was used as the suffix > for all TLS-SNI based challenges? > > - Ben > > > On Thu, Oct 13, 2016 at 8:00 AM Daniel McCarney <[email protected]> > wrote: > >> Hi Tim, >> >> Thanks for sharing your thoughts. This was the first time I've heard >> about this >> 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 >> decision >> 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 it >> 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 >> TLS >> 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
