So the original source of the TLS-SNI-01 in-the-field vulnerability that caused Let’s Encrypt to disable TLS-SNI-01 has just openly published details of the exploit he demonstrated:
https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/ In this case, he used AWS CloudFront and Heroku to achieve the issue. And it pertains to a TLS load balancer being programmatically bound to whatever newly unique to the platform name they want. Just like the threat I had mentioned. Now, imagine if there was a web host configured like AWS CloudFront and/or Heroku. Then imagine that they’re sleazier, less well funded, and looking for quick resolution to a new customer complaint… Customer complaint: My code used to be able to do X,Y,Z and achieve TLS-SNI-01 validation. Now, because your TLS balancer doesn’t send this “acme” ALPN signal, I can’t anymore. Fix it! The cheap quick fix to this — the one that makes the customer’s complaint go away while spending the least time and money possible — is to just patch in a fake echo of the “acme” ALPN signal. Note: this is fully resolved if the TLS SNI name in the protocol is changed to specify that it must be the actual domain label being validated. But if you don’t require that, you’ll create an opportunity for the web host to most expeditiously return to the prior status quo by making a minimal fake “acme” ALPN tag. > On Jan 12, 2018, at 10:04 AM, Matthew D. Hardeman <[email protected]> > wrote: > > 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 <[email protected]> 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 >> [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
