Comment by niftich | Hacker News Reader

Comment by niftich | Hacker News Reader

The tls-sni challenges rest on the assumption that a hosting provider will somehow ensure that a self-signed cert uploaded by the user contains "truthful" information, even though the second half of the cert is blatantly fake and is being abused to carry data. This is a bold assumption to make, considering the entire point of CAs is to say that the information being presented in a cert has been vetted, so why presume that anyone will vet any claims in a self-signed cert?

That aside, Let's Encrypt had an exemplary response to this issue throughout, and has made the right call here. A best-effort whitelist will enable a smoother transition for those on some known-good hosts, while mitigating this vulnerability and keeping their cert ecosystem uncompromised.

The work will now begin to add support to the other validation methods in ACME software that's lacking them, and to engage with the other custodians of the ACME protocol to rectify this particular flaw in design.

While the http-01 challenge is the recommended migration path, and likely the easiest to automate with greenfield software, the dns-01 challenge is the one with the fewest amount of intermediate assumptions -- such as the ones made when designing tls-sni-*, which in this case turned out to be faulty -- and represents the one most likely to be futureproof. After all, what better way to prove you own a domain itself than being able to add arbitrary records to it that all nameservers then echo back?

I completely agree on the dns-01 challenge. Those who are migrating off of TLS-SNI-01 and have a capability to standardize on dns-01 will be better off in the long run.

As you point out, domain control validation is best performed by having the application demonstrate control of the domain.

The problem with dns-01 is that it much of the time, it requires granting far too much privilege to the system that requests the certificate.

This is because the great majority of DNS hosts do not provide sufficiently granular permissions to only allow changes to _acme-challenge RRs.

e.g. Cloudflare, as far as I can tell, only gives you one API key which grants all access to all zones.

e.g. Most domain registrars who offer DNS hosting who provide an API grant access to all sorts of management functions, not just DNS zone changes.

e.g. Route53 IAM doesn't let you restrict to a single RR, you expose modifications to the entire zone.

I am really not comfortable giving my web application these kinds of powers.

TLS-SNI was useful because it was relatively protocol agnostic, so some of that flexibility is now gone.

The DNS providers need to up their API game.

The ISC BIND DNS server allows cryptographic authentication for updates with ACLs that let you get as granular as only being able to add/delete TXT records within this branch of zone X.

In the alternative, you can place static CNAME records in your real DNS zone that would refer out the _acme_validation queries to another zone entirely. Run that zone with entirely different credentials.

You are exactly correct. It's honestly pathetic that we've let cloud DNS providers (not to mention most alternative resolvers) get away with providing such inadequate interfaces compared to BIND. It's not actually difficult to admin, it's incredibly capable, and it fucking accepts AXFR/IXFR. It's insane to me that anyone puts up with such standards-hostile software.

> The problem with dns-01 is that it much of the time, it requires granting far too much privilege to the system that requests the certificate. This is because the great majority of DNS hosts do not provide sufficiently granular permissions to only allow changes to _acme-challenge RRs.

There's a cool solution to this that I learned from someone else on the Let's Encrypt forums (where I often help do support). The Let's Encrypt DNS-01 validator will follow CNAMEs. Therefore, you can make _acme-challenge be a CNAME to an arbitrary text record which can be in another zone (including a zone dedicated for this purpose). For example, you could say

_acme-challenge.example.com. IN CNAME foo.acmevalidation.example.net.

Now an application can just have API keys to update RRs under acmevalidation.example.net, which does not need to be used for any other purpose (or even necessarily hosted on the same infrastructure as example.com's own DNS). The CNAME can be created manually at the outset and does not need to be updated for renewals.

This has been possible for a long time, but if it becomes more widely known and more widely supported by client applications and DNS providers, it should make use of DNS-01 authentication much more practical, and safer, for a pretty wide range of people.

Another similar option would presumably be to delegate _acme-challenge.example.com to different nameservers with an NS record, then give your application the required privileges to control solely that nameserver.

Yes. Or even to the same name server, breaking out each whole label starting with _acme-challenge as its own independent zone, with its own access policies.

Yes, but there’s no need to have separate zones; you can grant update access to subdomains and have the CNAMES point into one zone with a subdomain dedicated to each separate actor which needs access.

Like so: Assume that Actor 1 has example.com and example.net. You then add this to the example.com and example.net zones, respectively:

  _acme_challenge.example.com.  CNAME  example.com._.actor1._.your-special-domain.com.

  _acme_challenge.example.net.  CNAME  example.net._.actor1._.your-special-domain.com.

Then you give update access to Actor 1, but not to the whole “your-special-domain.com” zone, but to the “_.actor1._.your-special-domain.com” subdomain. The ACME system would then be configured to send updates to the correct subdomains of that subdomain. Or “your-special-domain.com” could even be a subdomain itself of another domain; it doesn’t matter.

Reply on news.ycombinator.com