Nice comprehensive and prompt response!<p><a href="https://www.devever.net/~hl/xmpp-incident" rel="nofollow noreferrer">https://www.devever.net/~hl/xmpp-incident</a> advises "Add support for enforcing the presence of CT proofs (known as Signed Certificate Timestamps (SCTs)) in TLS certificates, and enable this support by default.".<p>Does Snikket do this?
One thing this article doesn't mention is monitoring your CAA record too. Unless your DNS is hosted and administrated by yourself, which is unlikely if you are using a hosting service for your jabber service, a targeted attack coordinated by a state/police could also affect your DNS zone records.<p>Another thing this article doesn't mention is given the nature of the protocol, any user should make sure he communicates to recipients using servers who have set a decent level of security standards. That is the hardest part to do.
TL;DR: Let's Encrypt certificates.. super convenient, right? Convenient for adversaries, too.<p>Key segment of TFA:<p><i>> Specifically, they were decrypting and re-encrypting traffic as it passed through a network device (the “machine in the middle”) that had been placed between the jabber.ru server and the rest of the internet.<p>> Usually TLS prevents such an attack from succeeding, as long as you verify certificates. However in this case the attacker was able to obtain valid certificates for the targeted domains, making all connections look like they were genuine.<p>> With the advent of ACME-based certificate authorities such as Let’s Encrypt, obtaining certificates is not at all hard for someone able to intercept and respond to traffic that is sent to your server, and in this case that’s exactly what happened.</i><p>Edit: I'm not saying there's anything wrong with Let's Encrypt. It's just interesting how it made things easier in this instance.