[xianb]

> Why would LE send the SNI in the first place? I thought the purpose was to prove you own the domain, not cohabit an environment where the domain is hosted?

The assumption was that you controlled the domain if you could return the self-signed cert with subjectAlt=foo.bar.acme.invalid when the SNI request for foo.bar.acme.invalid is made to the server your are requesting a cert for. Unfortunately the assumption didn't hold up because hosting providers shared the same routing server across domains and subdomains and those routing servers did not have controls around the subjectAlt domains used for TLS-SNI-01.

> Also, what do host headers have to do with this? Presumably this is just a tls handshake test? They don't have anything to do with the weakness. It's mentioned to make the distinction that SNI is used for the cert retrieval to establish the connection and Host-header is used separately to route to the proper backend

[morpheuskafka]

It seems that this arose from a fundamental issue with a lot of internet specifications. The person developing hosts' SNI implementation did not consider SNI to be a form of unique identification, but rather a way to establish that the server was authorized to serve it--as long as the server makes sure to serve the right files, which is a security issue for them to deal with, the certificate can be returned to anyone who requests it, even just to get a 404 page. It's like the janitor randomly trying keys from a ring, doesn't matter whose key is whose as long as it gets him in and he does what he is supposed to.

The TLS-SNI-01 developers assumed, presumably based on the implementations they knew/wrote, that SNI was an identifier. When used as originally intended, of course, SNI provides the name of a real certificate desired, not a validation string, and the returned certificate authenticates a pairing of server/IP->domain not validationstring->returned certificate. I'm not sure what the TLS standard documenting SNI actually says is the right interpretation, but unless it clearly says that this might be done in the future, it seems to me like a "hackish" solution that could reasonably be expected to cause a lot of issues. This seems to be a failure of setting clear standards for critical security protocols more than anything else.

By contrast, HTTPS-01 and DNS-01 operate using a known authoritative measure, ability to control the actual content of the website. If a bad actor has access to this, its game over. Only EV certs are intended to protect against this. Likewise, TLS-APLN-01 created a new protocol that could not possibly by implemented by accident or by anyone not intending to authorize issuance. It seems like nearly every major security issue (short of hard coding/crypto flaws) involves an assumption or edge case relied upon without consulting relevant standards.

[ohnoesjmr]

Why wouldn't it send SNI for the real domain? Also, what's preventing me from claiming some domain I don't actually own, if you are allowed to wedge in any invalid tld and nothing is checked?