←back to thread

Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

(www.devever.net)
341 points hlandau | 6 comments | 20 Oct 23 20:31 UTC | HN request time: 0.831s | source | bottom
Show context
LeoPanthera ◴[20 Oct 23 22:54 UTC] No.37962383[source]▶
The summary of the attack from https://notes.valdikss.org.ru/jabber.ru-mitm/ is very interesting:

* The attacker managed to issue multiple SSL/TLS certificates via Let’s Encrypt for jabber.ru and xmpp.ru domains since 18 Apr 2023

* The Man-in-the-Middle attack for jabber.ru/xmpp.ru client XMPP traffic decryption confirmed to be in place since at least 21 July 2023 for up to 19 Oct 2023, possibly (not confirmed) since 18 Apr 2023, affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)

* The attacker failed to reissue TLS certificate and MiTM proxy started to serve expired certificate on port 5222 for jabber.ru domain (Hetzner)

* The MiTM attack stopped shortly after we begun our investigation and network tests on 18 Oct 2023, along with tickets to Hetzner and Linode support team, however passive wiretapping (additional routing hop) is still in place at least on a single Linode server

* Neither servers appear to be hacked

* Both Hetzner and Linode network appear to be reconfigured specifically for this kind of attack for the XMPP service IP addresses

---

Neither that page, nor the page linked from here, mention certificate pinning, maybe because XMPP doesn't support it (I don't know), but if it did, wouldn't that have prevented this kind of attack?

replies(7): >>37962604 #>>37963159 #>>37963258 #>>37963349 #>>37963431 #>>37964615 #>>37964717 #
1. Nextgrid ◴[20 Oct 23 23:24 UTC] No.37962604[source]▶
How would you do certificate pinning if you don't control the clients?

My understanding is that certificate pinning is only possible if you control the clients, in which case you can embed which certificates are allowed directly in the client and bypass the whole web PKI.

In a situation with general-purpose clients connecting, how would they know which certificates are meant to be allowed? That's what the web PKI is used for.

Of course, if you do provide your own clients, this just moves the problem further up the chain - in this case the place where customers would download the custom client software would be compromised and a malicious client served instead.

replies(3): >>37962673 #>>37962874 #>>37963604 #
2. LeoPanthera ◴[20 Oct 23 23:33 UTC] No.37962673[source]▶
> How would you do certificate pinning if you don't control the clients?

Well you cannot. If you were paranoid, you would perhaps supply a hash through some out-of-band mechanism, which would require manually updating for each new cert.

Obviously most people wouldn't ever want to do that.

3. dist-epoch ◴[21 Oct 23 00:10 UTC] No.37962874[source]▶
Isn't this what those "key hash pictures" in WhatsApp/Signal are solving?

XMPP clients could implement such a mechanism, and if any certificate/domain along the path changes, the users in a conversation would be notified.

replies(1): >>37965220 #
4. KirillPanov ◴[21 Oct 23 02:39 UTC] No.37963604[source]▶
TLS client certificates.

Use them.

Stop using domains. Stop.

replies(1): >>37964330 #
5. callalex ◴[21 Oct 23 05:28 UTC] No.37964330[source]▶
And how do you distribute those to anonymous users?
6. WhyNotHugo ◴[21 Oct 23 08:59 UTC] No.37965220[source]▶
These are usually to validate the keys used in end-to-end encryption. Both parties must confirm that they see the same details, which confirms that the same keys are being used on both ends.