Hacker News Reader

Comment by 0xbadcafebee | Hacker News Reader

This is one of several attacks that can be used to generate valid TLS certificates for domains you don't own. There are mitigations but they can all be defeated. This will persist until there is reform among internet standards groups, but they are controlled by the browser market, and they aren't responsible for generating the certs, so it's one of those "nobody is responsible so it will never be fixed" deals.

View on HN

What "reform" do you think would help?

The problem here appears to be that the victim didn't do even a halfway decent job of protecting their RIPE account.

RIPE offers TOTP. TOTP is hardly the best possible security, because it can be phished, but assuming the people using it are competent (and why are your networking team incompetent?) that ought to be adequate. It seems as though Orange didn't bother to enable TOTP and indeed didn't even set a decent password.

Nobody does this, but in theory dns-sec combined with a CAA record set to nothing would mitigate this in a way that can't be defeated, right?

In principle key pinning would be the counter measure, but that was so problematic it was removed from browsers. I think chrome still does static key pinning for their own domain, and many mobile apps do key pinning, so its not entirely dead, just mostly.

Potentially yes: Site owners could set a CAA record like…

nocerts.example.com CAA 0 issue ";"

… telling CAs that they shouldn't issue certs for `nocerts.example.com` at all.

That being said, it would make things difficult when it's time to do a cert renewal: You'd have to update the CAA record, wait for it to propagate, do the renewal, and then set it back. And that's a window that could be exploited.

What could work is CAA, along with RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding (https://datatracker.ietf.org/doc/html/rfc8657). RFC 8657 extends the CAA record to say "Only this specific CA account may request certs for this domain" and/or "Only this specific validation method may be used when requesting certs for this domain".

Well the first problem with that scenario is it doesn't work for most of the internet. It requires CAs and domain owners to use DNSSEC, and most do not. It requires strict validation of DNSSEC, and most dns resolvers do not. It requires the use of CAA records, which most domain owners do not. And it requires CAs to properly implement CAA (it was found in 2017 that many did not, and Let's Encrypt messed up 3 million certs due to CAA in 2020). So, a single person with their own domain could do all these things, but the rest of the internet won't be doing it, so most of the internet will be insecure. That's not tenable, because that means the rest of the internet can be used in attacks that appear legitimate. Even most of the top 100,000 websites on the internet don't use DNSSEC and CAA, and if you asked them to, they'd ignore you.

But the second problem is it doesn't really solve the problem. Eventually you have to renew the cert, and when that happens, an attacker can spoof the IP of the validating source and have a valid cert issued. CA validation itself is flawed by design.

Reply on news.ycombinator.com