Hacker News Reader

Comment by jmhodges | Hacker News Reader

There are equivalent attacks on both the DNS and HTTP challenges as described in the Baseline Requirements and ACME, and those are expected to be mitigated (and are) by hosting providers. Let's Encrypt isn't bound by the Baseline Requirements to mitigate this for these hosting providers, but is doing so out of a esprit-de-corps while the web figures out how it wants to handle this.

Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that.

View on HN

I don't think they are really equivalent. We are talking about Domain Validated Certificates, and for DNS and HTTP "attacks" you need to be able to serve content in the name/as part of that domain.

In this attack you need to be able to serve content in the "name of" a made up TLS name under an IP you share with the domain you attack (which is very common).

My "Hosting providers haven't, previously, thought of TLS serving as an individual user service before (though the Baseline Requirements do) and are having to work out the kinks of that." covers what you're trying to get at here.

I agree completely with that sentence factually and as an explanation why we have such issues, but still think HTTP and DNS are fundamentally different to this issue with the TLS-SNI challenge.

The domain under attack is not part of the actual challenge process here. As a hosting provider I never see it and it plays no role in the decision of what information I reply with. At no point do I serve content under the "wrong" domain. At no point does the attacker show any control over the domain being validated.

Well, no, the DNS resolved to these endpoints, just like in an HTTP attack, and then this is as if the Host header wasn't checked by the HTTP provider. You and these few specific hosting providers didn't think they had to look at the SANs, but, in fact, the Baseline Requirements expected them to verify that the SANs in the certs are controlled by the same user.

There's a reasonable disagreement but I (and others[1]) liken this the "postmaster@" attacks. At some point, for every protocol the hosting provider handles, we always end up having them do a bit more work then they thought they had to do but them's the breaks when dealing with the modern internet.

[1] https://twitter.com/sleevi_/status/951041801368035328

I don't advocate for such hosting providers to not mitigate that attack. It's a real problem and needs a real solution, no matter the technical or political reasons that lead to this. Those hosting providers might not ever want to use LE for their customers and might arguably not be "at fault", but still their customers are at risk and they should take steps to protect them.

But I still think it's a different problem in this case. In the end I suppose my argument is that this is a design flaw in this challenge and we ideally should not use it in it's current form, just as we no longer should use postmaster@ for domain validation (but the technical argument against postmaster@ is again a fundamentally different one).

Edit: I realized I was wrong and removed one part of my response regarding IP lookup as a positive sign of domain ownership.

Very curious what the DNS attack would look like: as far as I use it you need to be able to create arbitrary TXT records for the domain in question. Given that you won't be able to create TXT records for a domain you don't have control over (e.g. example.com) I can't quite figure out what the attack would look like?

Reply on news.ycombinator.com