←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: 1.043s | 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. MattJ100 ◴[21 Oct 23 07:01 UTC] No.37964717[source]▶
XMPP supports channel binding, which is not mentioned in this post but would have prevented this attack. Unfortunately jabber.ru is running server software from 2016, and that old version doesn't support it.

Pinning is problematic these days, because certificates are short-lived and renewed frequently. Users would be constantly asked to accept new certificates on a monthly basis, and they wouldn't think twice about clicking 'Accept' on an attacker's certificate then.

Channel binding works regardless of the certificate, and ensures the TLS stream is terminated by the entity you exepect.

The focus on (lack of) CT/SCT support in XMPP clients puzzles me, because it would not have detected this attack at all, which used valid CT-logged certs from Let's Encrypt. SCT verification would help detect theoretical issuance from another CA if they had a strict CAA record in place (they did not). But even then, channel binding is more privacy-friendly and does not depend on a third party.

replies(2): >>37964854 #>>37966693 #
2. knorker ◴[21 Oct 23 07:33 UTC] No.37964854[source]▶
Pinnig is based on the keypair, not the cert. You can renew and not break pinning, right?

Also you can phase in a new cert with pinning.

replies(1): >>37964971 #
3. MattJ100 ◴[21 Oct 23 08:01 UTC] No.37964971[source]▶
Yes, you can pin the public key instead, which is generally more helpful. But most ACME clients (including the "official" certbot) default to rotating the key too. That can be disabled, but it's a problematic default for this use case which means clients can't just enable pinning.
replies(1): >>37965363 #
4. rhn_mk1 ◴[21 Oct 23 09:37 UTC] No.37965363{3}[source]▶
How can it be disabled in certbot?
replies(1): >>37965421 #
5. natebc ◴[21 Oct 23 09:48 UTC] No.37965421{4}[source]▶

  --reuse-key           When renewing, use the same private key as the
                        existing certificate. (default: False)
From the docs: https://eff-certbot.readthedocs.io/en/latest/using.html#cert...
6. joelhaasnoot ◴[21 Oct 23 13:37 UTC] No.37966693[source]▶
If you care enough to pin, purchasing actual certificates isn't that hard is it?