[tialaramex]

The thing where IP 10.20.30.40‡ is in the DNS for thing.mycorp.example and later nobody cares about thing.mycorp.example and they give up control without removing the DNS entry - is why you can't get Let's Encrypt certificates by just running a HTTPS web server and you need either plain HTTP, a custom TLS server (it can also do HTTPS but it needs to know about ACME as well) or else DNS.

Lots of bulk hosts will let you pick (or randomly be assigned) a shared IPv4 address like 10.20.30.40 and then - either by luck or often alphabetical order - your aaardvark.mydomain.example gets to be the "default" host which shouldn't exist for HTTPS but does in many popular half-arsed HTTPS web servers including Apache. So now web clients connect to 10.20.30.40, they send SNI to the bulk host's server - "I'm here to talk to thing.mycorp.example" and it ignores what they said and gives them aaardvark.mydomain.example because that's the "default" now. And if Let's Encrypt accepted that, you could buy some bulk host accounts, impersonate all these abandoned sites and get certificates for them. So, they had to knock that on the head.

The custom TLS server trick works by (ab)using ALPN, lazily made servers like Apache don't ignore ALPN at least unlike SNI, and so the client learns this server wasn't the one with the ALPN it needed to talk to after all and the certificate isn't issued.

‡ 10.20.30.40 isn't a real public address it's just for example purposes here

[q3k]

> ‡ 10.20.30.40 isn't a real public address it's just for example purposes here

There’s an RFC for that :)

https://datatracker.ietf.org/doc/html/rfc5737

[tialaramex]

I know, but I'd have to go look them up, so I keep using 10.20.30.40. But do keep badgering me, sooner or later it'll stick in my head.

[ornornor]

They’re not particularly memorable. I have already forgotten 2/3 just aftee closing the rfc.

[FiloSottile]

That’s not really what the issue with the tls-sni challenge was.

How that challenge worked was that the CA would give you a certificate for a fictitious name (say, abc123.acme-challenge.invalid) and you had to present it from the host when asked for that name by the client (the CA) though SNI.

Many hosts that share IPs between customers also let those customers upload their own certificates. The attack just involved uploading a challenge certificate for a colocated site, and letting the host serve it as expected. Even if the host _did_ check that the name on the cert was not the name of another customer (which is itself sometimes impossible), and even if the target site was not abandoned, and even if it had correctly functioning HTTPS, these are fictitious made up names, so the attack would still work.

It involved no ignoring the Host header, or really any misconfiguration, that’s why it requires rolling to tls-alpn.

[tialaramex]

Two things, firstly I wasn't (though I can see why you'd think so) talking about tls-sni-01 but about the original intent to deploy http-01 challenges for HTTPS.

Secondly it requires not merely a misconfiguration but a bug, a bug which is so widespread it was pointless to pretend it would get fixed in the foreseeable future. When you receive SNI for foo.bar.example and you understand SNI but don't have a foo.bar.example TLS provides an explicit error case for that. Servers like Apache httpd don't (or at least didn't) bother implementing this, and instead give you a default site and this enables the hijack. You should still be able to find when this was discovered in the ACME list.

[CameronNemo]

https://fly.io/blog/how-cdns-generate-certificates/