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)
mathieui
in reply to Ge0rG • • •Ge0rG
in reply to mathieui • • •Jonas Schäfer
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?
Nicoco
in reply to Jonas Schäfer • • •Ge0rG
in reply to Nicoco • • •Opening registrations will convert your family server into a spam relay in just a few weeks.
@jssfr @mathieui