Comment by vb-8448
3 years ago
> The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023
> We tend to assume this is lawful interception Hetzner and Linode were forced to setup based on German police request.
> Another possible, although much more unlikely scenario is an intrusion on the internal networks of both Hetzner and Linode targeting specifically jabber.ru — much harder to believe but not entirely impossible.
And what if the attacker tricked somehow the letsencrypt challenges?
Or this is supposed to be impossible?
Even after obtaining certificates allowing you to MITM, you have to actually find TM you can be a MI. In a targeted attack, this could be as easy and discreet as spoofing the target’s hotel WiFi. In a country without plentiful cross-border connections or a diverse backbone, a tap in the right IX could also work. (Famously, the NSA exploited the oligopoly the major consumer ISPs have in the US. Somewhat less famously, Roskomnadzor had to embark on a multi-year boiling of the frog to make Internet censorship in Russia even remotely workable, due to the diversity of the market and of the interconnects left over from the late nineties and early oughts, culminating in a requirement for every ISP in the country to patch MITM hardware into their network.)
But for this kind of thing to happen on every connection to the server being impersonated, you either have to bring a very big and publicly noisy hammer like a BGP hijack, or have the Internet upstream of the server cooperate. If the traceroute info in the post is to be trusted, in this particular case Linode and Hetzner themselves—or perhaps their datacenter operators—seem to be performing the intercept.
> If the traceroute info in the post is to be trusted, in this particular case Linode and Hetzner themselves—or perhaps their datacenter operators—seem to be performing the intercept.
Ok, now I get it. Thanks.
The attacker effectively controlled the IP the domain was pointed to. If you have this, getting a cert issued from any CA is trivial - you've proved to them you control the domain in question.
As mentioned elsewhere in the thread, RFC 8657 can prevent this.
https://news.ycombinator.com/item?id=37958831
They don't need to, they controlled the domain IP and trivially got the certificates. This is not a novel technique, see this Twitter thread:
https://twitter.com/billmarczak/status/1710348549794185279
We need to go back to snail mail or something, this whole .well-known thing just stinks. We added layers on top like CT and while sound ideas, they don't tend to do anything unless you are Google or FB.
> Yes, the fraudulent certificate is memorialized in Certificate Transparency (CT) databases (the indelible, publicly accessible records of ~all issued TLS certs). But, most website owners don't know what CT is, have no idea how to check it, and wouldn’t know what the results meant
CAA account binding is the response to this.
If that were the case, they wouldn't have seen weird connectivity issues/behaviors.
why not? They discover the issue only because the attacker failed to renew the certificates.
Yeah, but just getting a hold of a valid certificate doesn't automatically mean a MITM. For that the network connections need to be intercepted too.