Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

devever.net

Post reply on HN
Print view View original

21–30 of 150 posts

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#21

Post by dist-epoch »

the8472 wrote: post #12
liquidk wrote: post #8

The provider has access to the host, they can just inspect the job from the outside and you won’t be able to tell

secure boot + virtualized memory encryption is supposed to prevent that, you'll have to trust intel/amd though.

Only if secure boot was enabled by a trusted party on trusted hardware.

If you enable secure boot remotely without physical access to the machine you can't be sure it was actually setup in a non-compromised way. For example the machine could be running a custom backdoor-ed TPM, BIOS settings, ...

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#24

Post by dist-epoch »

Nextgrid wrote: post #10
LeoPanthera wrote: post #4

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…

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…

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.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#25

Post by worldofmatthew »

mike_d wrote: post #16

Great callout: > Don't use Cloudflare or similar services. See my article here for an explanation on why. If you use a service like this, you're basically already MitMing yourself. I wish more people would realize that when arguing on the internet about CAA, DNSSEC, NSA, etc. that none of it really matters. We willingly allow a government aligned entity to unwrap 20% of all TLS connections on the internet and peak in…

Cloudflare is horrible for privacy. It is also a bit of a sovereignty issue for European countries to have all their citizens web habits to be MITM by a forging power (no matter how friendly they seam).

Edit: not even going in to the sovereignty issue of having an American private company effectively decide your internet regulations.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#26

Post by tedunangst »

fanf2 wrote: post #23
tedunangst wrote: post #7

Run your own CA and choose your roots carefully didn't make the cut.

A bit difficult when providing services to third parties who can use any client software :-/

That's actually probably easier than getting a browser to work with a forbidden cert, how dare you.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#27

Post by justsomehnguy »

fanf2 wrote: post #23
tedunangst wrote: post #7

Run your own CA and choose your roots carefully didn't make the cut.

A bit difficult when providing services to third parties who can use any client software :-/

Yes, but if you can serve multiple certificates on one endpoint (think SNI) then you can add your own self-signed or private PKI certificate to be able to check if all your requests are being intercepted by a lazy adversary.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#28

Post by OmarAssadi »

the8472 wrote: post #12
liquidk wrote: post #8

The provider has access to the host, they can just inspect the job from the outside and you won’t be able to tell

secure boot + virtualized memory encryption is supposed to prevent that, you'll have to trust intel/amd though.

I'm not sure truly verifiable "Secure" Boot is actually realistic in most scenarios, though, right?

I'm not super up-to-date on what's being offered right now, but I'm not sure if there is a way to have a proper trusted execution environment on most Intel or AMD offerings; I thought Secure Boot on AMD64 platforms generally rely on TPM or something like SGX for validation, with the former having seemingly a dozen different ways to be tampered with, and the latter being discontinued and being vulnerable to several different attacks, including DOWNFALL.

I think EPYC and Sapphire Rapids have some sort of Trusted Execution Environment stuff with SEV-SNP and TDX, maybe? But I don't think either option is really feasible for people paying Hetzner-like prices for hosting; Hetzner's newest Xeon offering is seemingly Cascade Lake, and the only EPYC offered is a single-socket Rome 7502P with 128GB DDR4 for 142 euros, which seems very hard to justify, given they also offer a 7950X3D with 128GB DDR5 for ~25 euros less.

Even then, I don't think I could put my confidence in a machine I don't own, didn't setup, can't physically inspect, don't know where it came from, whether the firmware has been tampered with, etc -- especially if it is something as complex as x86, where there is seemingly at least one new horrific hardware-level vulnerability that crops up every generation or two.

EDIT: I forgot Hetzner also started offering Ampere Altra servers for 200 euros. I think those have TEE of some sort with the TrustZone stuff?

Not sure how secure that really is, though; I haven't really looked into the ARM offerings as much as I should have, mostly since, if you don't want Apple, I'm not aware of a good middle-ground between a cheap SBC and a $3,000+ Ampere server, outside of jerry-rigging some second-hand Gigabyte Cavium ThunderX2 nodes off eBay.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#29

Post by ronsor »

worldofmatthew wrote: post #25
mike_d wrote: post #16

Great callout: > Don't use Cloudflare or similar services. See my article here for an explanation on why. If you use a service like this, you're basically already MitMing yourself. I wish more people would realize that when arguing on the internet about CAA, DNSSEC, NSA, etc. that none of it really matters. We willingly allow a government aligned entity to unwrap 20% of all TLS connections on the internet and peak in…

Cloudflare is horrible for privacy. It is also a bit of a sovereignty issue for European countries to have all their citizens web habits to be MITM by a forging power (no matter how friendly they seam). Edit: not even going in to the sovereignty issue of having an American private company effectively decide your internet regulations.

The EU regularly de-facto tries to decide regulations for other countries. All is fair in a globally connected world.

Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident

#30

Post by jeroenhd »

hlandau wrote: post #17
johncolanduoni wrote: post #11

They point out that "CT is optional", but isn't that ultimately a decision by the XMPP clients? What stops them from requiring CT now that browsers effectively do? What trust store would they be relying on that issues certificates that don't work in the browser?

Right, they could do this and this seems like a good idea to me. The problem this require-CT behaviour isn't switched on by default for basically any TLS library, so an XMPP client developer would have to go out of their way to switch this on, and I assume most or all (currently) don't. That can change of course.

How problematic is that in real life? All CAs worth their salt are already publishing all certificates to CT logs because most TLS servers are browsers and most clients are browsers.

Maybe there's a CA somewhere that has opt-in CT logging enabled, but I don't think they're very popular. For example, even the rogue CA certificates were published onto the CT log (because Let's Encrypt does so by default).

I think a CT check shouldn't be a very problematic change in practice, as long as there are reasonable exemptions (i.e. don't require CT for certificates imported into the CA store, allow the user to disable the check, etc.). For serverserver communication things become more difficult, but the entire network would be better off if a major server like ejabberd were to require CT.

Post reply on HN