Hacker News Reader

Comment by ls612 | Hacker News Reader

I thought certificate transparency was the thing that was supposed to prevent exactly what this article is describing. What if anything is incorrect about my model of the world in this respect?

View on HN

Basically, CT did indeed worked as designed, but there was no monitoring by the domain authors (which to be fair there are a dearth of solutions of the time).

On a related note, Let's Encrypt also issued the presumably-interception certificates. This can be possibly something that requires interception at the VPS level (otherwise we already detected the BGP leaks). Presumably, Hetzner was forced to do a raw interception and then redirecting all relevant ports to a middlebox for inspection and CA issuance (and since that the ACME spec is well-defined, they can simply check if the handshake contains the TLS ALPN challenge and then redirect them to special code that will reply with the correct things).

Certificate transparency worked exactly as designed in this case. Monitoring public certificate transparency logs for anomalies is a different story entirely.

By breaking the software facilitating https via ACME itself, no anomalous certificate transparency logs would have needed to have been created at all.

The front door is locked quite tightly with a watchful security camera, but the window has been left unlocked. Also no one is watching the camera feed.

Nothing, although it's more mitigate than prevent per se. They simply did not have alerting set up against the CT logs. It is one of the lessons they highlighted in their own postmortem.

Yeah I suppose the prevent part came from the Browser/CA forum giving the CA that did it the death penalty like they did for Kazakhstan's CA in 2015 but if the men with guns point them at executives of browser providers and say "trust this CA or else" then CT is more of a cosmetic system than anything else.

What I more meant is that it's a reactive arrangement rather than a proactive one, so it cannot be preventative outright. Domain owners are expected to actively monitor the CT logs for abuse, and take action if they see any. This necessarily means that abuse can still happen, at least for a little while.

Do the executives implement program features?

The most striking thing about these types of conspiracy theories is people seem to completely forget that whoever you imagine you can threaten generally doesn't have the ability to do the thing you want them to do: they'd have to delegate it.

So given that this is widely accepted to have actually happened why has the CA involved not received the death penalty like the Kazakh one did?

Because unlike in that case, the CA in this story is not suspected to have done anything wrong, despite what the post's wording might suggest. See my other comment: https://news.ycombinator.com/item?id=48340259

If you're a CA you can just issue a cert and not publish it in the CT logs. You're not supposed to do that, but there is nothing stopping it. And the attack isn't stopped even if they do publish in CT. And you have to monitor for it anyway.

Every single mitigation for known Web PKI vulns can be worked around (if people use them, which virtually nobody does).

> If you're a CA you can just issue a cert and not publish it in the CT logs. You're not supposed to do that, but there is nothing stopping it.

Browsers have mandated CT logging for years and will not accept such a certificate.

Why is it so common to incorrectly assume that the people who came up with CT were stupid?

> Browsers have mandated CT logging for years

They did, yes. Any CA caught issuing a non-logged cert would be in big trouble.

> ... and will not accept such a certificate

Do they not?

According to RFC 9162 including CT information inside the cert itself is optional, and the extension is noncritical. Clients are not required to support CT, and they MAY fetch inclusion proofs. Servers are supposed to send CT info via one of various methods - but they aren't required to supply a complete proof of inclusion. Considering how OCSP was implemented in practice, I highly doubt any browser is willing to completely block the connection until it has managed to fetch an inclusion proof - both from a speed perspective and a privacy perspective.

CT's main value is in giving the browser vendors a stick to hit the CA with in case of non-logging, which is indication that something fishy is going on. Send the cert itself to a mailing list and anyone can check with the logs. Log getting DDoSed? Just try again tomorrow, the CAs judgement can wait another day. This is completely different from having a browser verify the proof in realtime while setting up the connection, and having it fail hard if it can't be 100% sure.

https://googlechrome.github.io/CertificateTransparency/ct_po...

If a cert doesn't contain the requisite number of valid SCTs from logs that are specifically usable in the browser - it will not work.

CT indeed worked out pretty well. At least until bots started hammering crt.sh making it unreliable, and those that want to be alerted to newly issued certificated appeared in the logs need to pay for some purpose-built service instead of just adding a relevant query to their feed reader.

The wrong part is that Let's Encrypt was willing to issue a valid cert to anyone who can temporarily redirect traffic. The authorization should have been done better, for example, sending a certificate to operator's email.

There is no such thing as an "operator's email". Over time there has been a wild growth of webmaster@, admin[istrator]@, root@, postmaster@ and so on, but having access to them proves very little. Some email operators just aren't very restrictive with their allowed usernames, and that's before we get into the corporate world where the first-line helpdesk person weeding out the email received on that address probably isn't supposed to issue certificates!

This method has been (mostly?) banned for a reason, see for example CA/B's ballot SC080v3.

Reply on news.ycombinator.com