[notatoad]

Wow.

I thought this was going to be about some sneaky exploit where they'd manage to get a gov.uk to forward links to porn or something. But no, it's really a whole subdomain just taken over by some sketchy porn site.

I'm wondering if the porn site operators even know it's happening? Seems the most likely thing is the DfT had a site at that URL, hosted on AWS. And then they shut it down without removing the DNS record and Amazon assigned that IP to somebody else.

[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/

[notatoad]

(as per the other comment, my guess is incorrect. I didn't actually look at the DNS. No porn site operator is going to accidentally pick the s3 bucket name 'charts.dft.gov.uk')

[perl4ever]

I thought this was going to be about a new government website that all UK porn viewers are required to register with. I feel like I've seen a number of threads about that being imminent.