ValdikSS, a Russian security and networking researcher, writes technical notes on traffic interception, Linux tuning, and censorship circumvention.
Commenters praise the jabber.ru MITM report as a masterpiece of forensics and cite it as an example of a discovered state-level attack.
The main reason we won't list it on privacyguides.org is the encryption is not always on by default.
There are two major problems, the implementations and the fact the spec isn't specific. I'm not particularly bothered by the imaginary, the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things.
As for the reply from the spec author, I had a negative opinion of that. To me it looks like they just tried to copy signal's encryption so that people could claim that XMPP has E2EE, without any real design or thought of the implementation.
One of the other things I hate about XMPP (and you mentioned it above with the jingle debacle), but there are other cases where there's multiple XEPs for the same thing. Some of them are widely used despite being marked as "experimental". The documents are not cohesive and is a mess which is probably why the implementations are also bad (unlike the Matrix spec). Encryption is just another one of those things, just like file transfer.
If I was deciding on a new project to develop a client for XMPP would be the least attractive project for me to work on. Put it that way. Without enthusiastic developers that think this thing sounds cool there simply won't be any good software.
The other thing also not mentioned is that the OMEMO encryption only applies to text messages and not all the other things, ie VOIP, status changes etc.
There is a fair bit of metadata on…
How can you check other people's certs? How do you know whether a cert issued is authorized by them or not?
The only one who can check for maliciously published certs is the entity authorized to request them. I think most companies are happy when they manage to have valid, not expired certs and do not care too much about making sure there are not too many of them.
You are right that if the state would start issuing malicious certs en mass that would be found out quickly. But I think very targeted selected operations against entities where they know the entity is unlikely to surveil for unauthorized certs are very much possible.
I'm not arguing for going into conspiratorial thinking and claiming CAs are all compromised and issuing malicious certs all the time. But I do think that it is feasible for states to use CAs under their direct or indirect control to run targeted attacks. I think that is a plausible, serious risk that we do not care enough about and that we should do something about. There is a multitude of precedence starting from LavaBit over the wiretapping of jabber.ru^1, ANOM^2 to CryptoAG^3 that supports this conclusion.
[1]https://notes.valdikss.org.ru/jabber.ru-mitm/
[2]https://en.wikipedia.org/wiki/Operation_Trojan_Shield
[3]https://en.wikipedia.org/wiki/Crypto_AG
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 18 Apr 2023, affected 100% of the connections to XMPP STARTTLS port 5222 (not 5223)
* The attacker failed to reissue TLS certificate and MiTM proxy started to serve expired certificate on port 5222 for jabber.ru domain (Hetzner)
* The MiTM attack stopped shortly after we begun our investigation and network tests on 18 Oct 2023, along with tickets to Hetzner and Linode support team, however passive wiretapping (additional routing hop) is still in place at least on a single Linode server
* Neither servers appear to be hacked
* Both Hetzner and Linode network appear to be reconfigured specifically for this kind of attack for the XMPP service IP addresses
---
Neither that page, nor the page linked from here, mention certificate pinning, maybe because XMPP doesn't support it (I don't know), but if it did, wouldn't that have prevented this kind of attack?
https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/en/
The patch prevents eviction of file cache from the RAM, which, when using with zram, makes the system very fast when it is swapping. On regular Linux, when the system is low on RAM, file cache is evicted so quickly and is re-read from the (slow) HDD relatively slowly, that's why the software "lags" (it can't reload the code and resources fast enough to stay fully responsive).
However, with this patch file cache stay in RAM until absolutely necessary to evict it. This GREATLY increases system responsiveness. Even on my old PC from 2007 from the article, swapping hundreds of megabytes to zram is almost unnoticeable process with the patch. The software is so responsive like nothing happens.
Without the patch the PC is uncomfortably slow at times. Swapping process is definitely noticeable, the system may become unresponsive for several seconds (even the mouse doesn't move).
The speedup, however, is a bit of side effect of the patch. It was designed to prevent hard thrashing when the system only evicts and reloads data from the disk for indefinite amount of time.
Watch the video in the linked article above. There's also a LiveCD ISO file to try the patch effect without installing the system/the patched kernel.
More frequent renewals pose various architectural problems, but it makes “lawful” TLS intercepts harder to execute without going unnoticed.
TLS intercepts with CA signed certificates can and been carried out. The undertone in previous reporting indicates that the execution depends on a mechanism that doesn’t have 100% reliability across renewal cycles, and shorter lifespans will make that more difficult to carry out without ostensibly visible warnings to the user.
It’s a headache, but you are supposed to be monitoring Certificate Transparency logs for rogue certificates. Barring that, shorter validity is a way to address it.
https://notes.valdikss.org.ru/jabber.ru-mitm/
These are not theoretical concerns though. For example, since SSH uses a trust on first use model as opposed to a central trust/web of trust model, they can direct the victim to a different SSH server if they're connecting to a new one, and intercept all traffic.
(Edit: Even with HTTPS, there are other ways to MITM a connection because each trusted CA is considered an equal. For example, instead of doing a full-on MITM on a service which is likely to be detected[1], a better solution may be to obtain a certificate and target the specific user.)
[1] http://notes.valdikss.org.ru/jabber.ru-mitm/