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?
Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
11–20 of 150 posts
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#12The 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.
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#13> What would a perfect attacker do? If you had physical access to the computer, some sort of bus interception to exfiltrate data from the machine.
extremely difficult to get physical access in a datacenter
The organization conducting the MitM likely has physical access to the machine already. The original post indicates the link on the network interface went down for 19 seconds, indicating a device was placed in front of the server.
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#14Earlier quoted context omitted.
I would suggest that if you are the police, you can break into a datacenter with a flash of a badge. I can't imagine many would attempt to stop you.
I would hope they at least: * Require a copy of the badge number, and verify that this officer is assigned and expected to be at this business right now. * Require them to sign into and out of the site. * Annotate which systems / compromises are in place. - That all of the above MIGHT be sealed under a court order; I would hope any such order has an automatic 'sunset' date, and possibly renewal upon review by a diffe…
Those are some very optimistic hopes!
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#15The 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…
> 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.
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#16Great 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 inside.
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#17They 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.
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#18I looked into CAA but the current dns provider doesn't support those records. Is there a reason it had to be a new type not a more common TXT record?
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#19I looked into CAA but the current dns provider doesn't support those records. Is there a reason it had to be a new type not a more common TXT record?
You can try to see if your provider supports "opaque" types in which you can submit the binary encoding of the record without them knowing what it is. Barring that you'll need to request support for it. It's an increasingly popular record type so not supporting it isn't terribly great service nowadays.
I'm not familiar with the discussion that went into the design of CAA (it was probably discussed at some point on the relevant IETF mailing list, if you want to go digging).
Re: Mitigating the Hetzner/Linode XMPP.ru MitM interception incident
#20[deleted]