I would prefer to use TLS-SNI, but I’m not using a “major provider”. I know I’m safe from the issue, as I’m hosting on my own IP. Could LE consider supporting a CAA entry like CAA 0 issue "letsencrypt.org; tlssni=yes" to specify that tls-sni is allowed for this domain?
8 Likes
This is an interesting idea! I’ll share it with the team and see what people think.
2 Likes
I believe that there is already RFC draft for that 
https://github.com/ietf-wg-acme/acme-caa
https://tools.ietf.org/html/draft-ietf-acme-caa-03
Now it only needs more traction 
Which is nice, but I’m proposing something like a stopgap, cause frankly, the decision to only allow “major providers” to use TLS-SNI feels like LE is saying “we don’t care about all the little people that want to use it”. I understand the difficulty in trying to whitelist/blacklist all of the internet, but this would be “middle point” between the 2 that I feel would fix lots of use cases, without forcing a wait for the RFC to finish and get deployed and all. I’m currently sitting on a bunch of certs that are valid, that I can’t renew without redeploying servers.
The trouble I see with this proposal is that the CAA is bound to the authorization domain name hierarchy, which is entirely unrelated to the hosting infrastructure on which the domain is hosted.
The vulnerability occurs per hosting infrastructure. It does not occur per domain to be validated. In other words, if this mechanism is allowed, a user could just add such a DNS record to his domain in order to allow the TLS-SNI validation, even if the domain is presently pointed to a vulnerable hosting infrastructure.
Generally speaking, a user will just do whatever they can to get back to working. In this case, that may mean ignoring the security risk.
Does this still apply if you combine validation-methods and account-uri?
e.g. CA policy could be that account-uri must be present for validatiion-methods=tls-sni-01 to take effect.
Perhaps not .. getting complicated.
1 Like
Nothing is secure against a user that's trying to make themselves vulnerable...
2 Likes
That… might be workable, actually… I’d have to give it some thought. Maybe the LE guys would consider something like that.
Of course you’re right regarding the user’s security, strictly speaking.
Having said that, the standards to which a CA are judged do not generally permit the CA to decide to allow the user to decide to intentionally reduce security – with respect to the certificate validation and issuance process at least. The CA is called upon to protect the people who visit abc.com’s website, not to protect the publisher of abc.com’s website.
Wouldn’t it be fairly easy to reconfigure your infrastructure for the http-01 challenge?
Hopefully our latest update improves the outlook for you somewhat: 2018.01.11 Update Regarding ACME TLS-SNI and Shared Hosting Infrastructure.
Right now our feeling is that “opting in” to TLS-SNI via CAA is still interesting, but is not the highest-impact mitigation we can do right now. In particular, many DNS providers still don’t allow setting of CAA records, which limits the number of people who could use this option. Also, it seems like the long-term outlook for TLS-SNI is quite poor, so this would be just one more angle to keep TLS-SNI on life support.
No, it wouldn’t be “reconfigure”, for the use case I’m using TLS-SNI for, it’s “rebuild the whole thing from basically the ground up”. Temporary ability to at least renew going forward prevents it from being a mad scramble, but this is still frustrating.
It’s amazing that the Let’s Encrypt and Certbot teams have come together to so quickly write new nginx and apache plugins for HTTP-01.
Excellent work. I imagine that will be the most straightforward migration path for most who were relying upon TLS-SNI-01.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.