Breaking that on purpose is actually why I most believe that the SNI should be required to reflect the exact SNI of the domain label being validated.
The threat model I was concerned about evaporates if the SNI is the actual domain label and the decisioning of which TLS certificate to present to the validator versus the normal far-end browser or other endpoint is then dependent on the combination of the ALPN marker AND the SNI. (i.e. use most recent real certificate/key for connection with real endpoints indicating SNI of the real domain label, but use the validation certificate/key when the real SNI + “acme” ALPN tag is received.) Imagine that the HAProxy you describe is run not by the website administrator, but by the shared hosting provider. Imagine that their infrastructure was vulnerable to the TLS-SNI-01 and -02 problems because their outside facing HAProxy matched SNI of any number of customer configured unique labels with customer provided certificates… If you keep letting that model be manipulated by customers of the hosting provider, and keep the SNI as the .acme.invalid pattern, the path of least resistance to return the web hosts’s prior level of function is simply to create a fake “acme” ALPN signal and proceed with old behavior. That’s a danger. The concerns I raised would more or less be fully resolved by standardizing on having the SNI label be required to be the domain label being validated and then the TLS termination endpoint on the server side has to look to the “acme” ALPN tag to know to switch to presenting the validation challenge-response cerfificate/keypair. > On Jan 12, 2018, at 9:29 AM, Patrick Figel <patrick@figel.email> 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 > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
