This is almost certainly related to some sort of Russian cybercrime investigation. If you ever read Krebs or peruse some of the seedier Russian forums, xmpp.ru will sound familiar to you, because it is. Not imputing anything to the operator, that's just the nature of operating an anonymous service.
Drug gangs widely use XMPP as a secure communication channel in combination with Tor. Hydra (the darknet market) has been taken down by German police in 2022 after trying to extend their "service" to the EU; something similar might or might not have happened here.
I'd like to add that MTProto is impossible to MITM because there are no trusted third parties. The handshake that happens before the user logs into their account includes a step with RSA. The public keys for that step are hardcoded into clients.
To anyone who wants to complain about Telegram not encrypting chats by default and using "homebrew crypto" I'd like to say that it's XMPP we're discussing here. Telegram offers marginally better security than XMPP over TLS. The "homebrew crypto" is still not broken in 10 years and not for the lack of trying.
> Telegram offers marginally better security than XMPP over TLS.
I think you should compare apples to apples, that is, end-to-end encrypted XMPP using OTR/OMEMO/PGP. However, I agree that many XMPP clients were UX disaster when using E2E.
End-to-end encrypted XMPP should be compared to Telegram's secret chats then. Both are opt-in and both aren't very popular among users of these services.
A lot of clients have OMEMO on by default now. You can’t enforce it for all clients & across the entire network tho as XMPP is a ‘simple’ protocol without a let of bells & whistles meant to be eXtended like OMEMO/OTR/PGP built atop it. With the newer compliance suites tho, to be considered ‘modern’ OMEMO & other e2ee options are expected to be supported. Gajim makes the UI easy, & Conversations isn’t bad. Profanity is a bit more obtuse to use since you need to trust your own keys manually too & they’re not autocompleted, but all the tools are there even for a TUI client.
XMPP over TLS is secure though. Of course that is for the transport as the name implies. The difference to e2e is the same. Although if one party of any e2e exchange is compromised, you would have similar problems.
Why don't you post yours? ;) Open up a TCP server on port 13729 for verification.
And no, your IP should not be made public in any modern chat app, that's ridiculous. The fact that Discord protects your IP from leaks is at least half of the reason it's so successful.
I actually think it depends on what your type of threat is. If secure means talking to trusted people, and no one else should know what you say or to whom, Telegram is still great and who cares if my confederate knows my IP. He doesn’t care.
If you’re using it to communicate to a hostile party who would love to unmask you, then very not so much. Personally I’m not in the second category but I’m sure some are.
Telegram is as secure as it can possibly be without the security requiring compromises and leaking into the UX. I thought that was clear to anyone who has ever used it. If you require 100% bulletproof security and are willing to compromise on convenience, it's not for you.
Since this thread is about XMPP, Telegram's security is effectively the same as XMPP over TLS, maybe a bit better because there isn't a trusted third party (the CA).
> All voice can be E2E thru servers, like Signal does.
I know that. In fact, I built the first VoIP implementation for Telegram, libtgvoip, myself from scratch. Relay servers add delay, can run out of capacity, and cost money in bandwidth. Of course relays are still used if a P2P connection can not be established (libtgvoip always started the call through the relays and only switched to P2P if pings went through and RTT was lower, that took at least several seconds before enough statistics was gathered).
Did audit help Let's Encrypt to prevent issuing fake certificates? Such audit is useless. SSL infrastructure security is in a much worse state than Telegram's yet nobody seems to notice it. If any large ISP can issue fake certificates by doing MitM then this system is compromised completely. What's the point of having SSL if basically anyone can MitM it?
To be honest, Telegram using homemade crypto instead of relying on standard approaches like CA certs turned out to be good solution in the end. Apps should stop trusting CA and should hardcode public certificates instead.
Apples and oranges? Let's Encrypt is a bandaid for a (possibly inevitable) architectural weakness, one serving browsers which must communicate with a world of unfamiliar servers. Telegram is a messaging app primarily meant for communicating among people and groups one already knows.
Regardless, using open and verified cryptographic primitives is a best practice for a reason. As are audits. The likelihood any company can start from scratch and produce a flawless solution is a number approaching zero.
I'd feel much more comfortable with something using Signal protocol. Ideally built from independently audited source.
Signal has massive usability issues: requires a phone number, requires a primary Android or iOS devices, can’t register multiple Android or iOS devices, requires Google Play services for notifications unless you get the APK which drains your battery (a fork, Molly, no supports UnifiedPush tho).
This criticism/argument was, in fact, made against domain validation (DV) when it was first introduced by earlier CAs. It's not an unreasonable criticism, but the economics of PKI mean that we would have much, much less encryption and authentication on the web today without DV.
DV represents a security trade-off, and Let's Encrypt took this and ran with it, with the net effect of much much much much less web traffic interception overall, albeit with known non-Let's-Encrypt-specific vulnerabilities to attackers who can manipulate infrastructure sufficiently.
As other people in this thread have noted, there are also other mechanisms that can help mitigate those vulnerabilities. Maybe we can come up with more over time!
So for example, if traffic to Google goes through a Huawei router somewhere, then Huawei can issue a Let's Encrypt certificate for Google, right? And any large national ISP can use MitM to issue fake certificates for any site hosted within that country?
To me it looks like SSL cert infra is completely compromised and unreliable.
Multiperspective validation, if the attacker is far enough away from the target site. :-)
I think some of the researchers who wrote about BGP spoofing attacks against Let's Encrypt may have suggested something about logging BGP changes and delaying DV issuance if a network's BGP announcements are too recent, or something? I don't think Let's Encrypt currently checks that, but it could be an interesting data source in the future.
Let's Encrypt uses "multiperspective validation" to prevent a single backbone router or backbone network from being able to do this attack in many cases.
This doesn't help much if the attacker is sufficiently close on the network to the target, or if the attacker can perform a successful wide-scale BGP spoofing attack.
I'm not sure if that will reassure you, since it's not a complete mitigation in all cases, but the multiperspective validation was explicitly created in response to exactly this kind of concern about attacks on, or by, ISPs!
> This shows that Let's Encrypt security is a joke because now any large national ISP can use same MiTM to issue a certificate for any site hosted within a country. The SSL infrastructure is completely compromised.
the information available right now are too vague to come to a conclusion this bold.
Instead, I find it something like the following more plausible:
jabber.ru and xmpp.ru seem to use "exotic" DNS servers (at least as I checked right now).
The moment you're able to write a (TXT) record for some domain name, you have proven to be eligible for getting an SSL certificate for that domain name.
Both you and the grandparent are correct in that both propose viable attacks; it is a known fact (and not news to any expert in the space) that "domain validation" certificates are vulnerable to "global" MitM in which an attacker can intercept all traffic to a domain (and therefore intercept the validation probes). A situation in which a service's hosting company is sitting on their "front door" (so to speak) and MitMing all traffic that goes their way is exactly such a situation (hence my recommended mitigation).
Hosting company is not the only one who can do MitM; any ISP through which the traffic passes can do that as well; and if there are backdoors in foreign network equipment then the manufacturer of equipment can do MitM too.
ns2.jabber.ru is hosted at Akado (ordinary Russian ISP) in Moscow, as for ns1.jabber.ru it looks like it is hosted at Linode. So maybe ns1 was compromised as well, as for ns2 I doubt that.
https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
https://blog.talosintelligence.com/picking-apart-remcos/
https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
Really interesting writeup though. I guess it's a practical example of why everyone should get a CT monitoring service!