Detailed and credible looking report of #LawfulInterception #MitM on an #xmpp server hosted at #Hetzner in Germany: notes.valdikss.org.ru/jabber.r…

Looks like a transparent bridge was deployed in front of the actual server, obtained dedicated certificates from #LetsEncrypt and MitMed all incoming client connections since July. It was discovered because the LE certificate expired 🤦

This entry was edited (1 year ago)
in reply to Ge0rG

@mathieui It's not that simple, is it? At least in this scenario.

Here, the MitM was placed on the server side. If I'm not missing something, owning a DNSSEC-protected TLSA record is much more effort than sitting on the path to a single (or in this case, pair of) server(s).

You need to ensure that *all* DANE-validating clients (either s2s or c2s connections) are getting a result which makes them believe your forged TLSA records are authentic (or absent).

For that, you need to either be on the path between the clients and the DNS servers they use or in front (or inside) of all authoritative servers responsible for the domain, *in addition* to being able to forge DS record responses in the parent zone and *in addition* to whatever hoops they had to jump through in this case already.

And this type of attack is much easier to detect, because it'll be hard for the attacker to distinguish between traffic attempting to detect an attack (your monitoring comparing TLSA records against expected values via public recursors and/or for instance infrastructure like RIPE Atlas) and the target client traffic.

Or am I missing a more simple way which is not immediately obvious to anything monitoring your DNS?

This entry was edited (1 year ago)