4 ms·
What would be your alternative? I agree there's a lot to research and improve in the XMPP ecosystem ( see also https://joinjabber.org/faqs/security/ https://joi
by southerntofu 5y ago
What would be your alternative? I agree there's a lot to research and improve in the XMPP ecosystem ( see also https://joinjabber.org/faqs/security/ https://joinjabber.org/faqs/security/ ) but "admin in the middle" is not exactly a bug but a property of federated systems.
If your alternative is to use a centralized platform (which potentially requires a phone number to sign on) that's a trade-off i'm not willing to make. I'm personally very happy with my not-so-insecure pseudonymous communications (but always interested in constructive criticism).
- infosechandbook 5y ago> What would be your alternative? A good starting point would be more balanced articles also talking about downsides or not-so-secure/-private defaults; not only in case of XMPP but in case of any instant messaging protocol or ecosystem. Instead of claiming, "XYZ is secure because it supports TLS," articles should also mention what this means in terms of limitations (e.g., TLS protects data in transit, so server-side parties can still access the data) or defaults (e.g., only a subset of servers/clients support certain security features). While such things might be obvious to tech-savvy users, non-technical people don't understand this. They only read, "secure" and "private" and then assume, "Oh, it's secure and private, so I migrate to XYZ." In reality, "secure" and "private" aren't fixed states that you can identify by looking at some features.
- southerntofu 5y ago
- deleted 5y ago[deleted]
- infosechandbook 5y ago> Have you read the joinjabber.org security FAQ i linked? Not in detail as the OP linked to another article. We commented on OP's other article, not on your joinjabber.org security FAQ. > we were tired of FUD spread by articles like yours Where is the FUD? Your security FAQ mentions most, if not all, of our findings in the same or similar way. > Reality is more complex than a binary "is it secure?" Indeed. Unfortunately, the vast majority of people assume security is binary. Back to OP's article where they look at some isolated properties to then declare a protocol secure.
- southerntofu 5y ago> Where is the FUD? Your security FAQ mentions most, if not all, of our findings in the same or similar way. Yes, but there is no fearmongering involved. I'm part of the people who appreciated your article for the technical arguments, but i strongly dislike the fearmongering vibe (unless we do the same with every other protocol which could be fun). I actually started to write that FAQ precisely because i was tired of the script kiddies on both sides claiming XMPP is either the best or the worst and this or that solution is so perfect. > Back to OP's article where they look at some isolated properties to then declare a protocol secure. Yes, that's a problem. Let's try to promote more informative resources. We joinjabber.org people appreciate all feedback and criticism to turn into docs. You're always welcome by xmpp:privacy@joinjabber.org?join chatroom if you have more info and/or would like to run more experiments in regards to privacy and security in the XMPP ecosystem.
- infosechandbook 5y ago> claiming XMPP is either the best ... Unfortunately, this seems to be the starting point of most discussions on XMPP. Somebody claims that XMPP solves all problems, and is secure and private. Or they present a highly-customized, non-default XMPP setup and compare this with an out-of-the-box competitor to show the superiority of their setup. We rarely see posts like your FAQ on the internet. > ... or the worst In case you refer to our article, we don't claim this. We recommend to self-host your XMPP server (if you can), or to migrate to alternatives instead of blindly trusting unknown entities on the internet. We are also not the police on the internet. People can choose what they want, including WhatsApp, Telegram, XMPP-based messengers, Signal, or whatever messenger they use. > Let's try to promote more informative resources. We will link to your FAQ. Thanks for providing more balanced content.
- goodpoint 5y agoXMPP leaks less metadata than alternative like Matrix, but it still very vulnerable to traffic correlation attacks from an external observer, server compromise and malicious server admin. Far from ideal. Briar mitigates[1] these risks by using p2p messaging over Onion Services. [1] mitigates: it's well known that even Tor cannot protect from correlation attack from a global observer but mounting such attack requires billions (see PRISM). Correlating traffic from/to an XMPP server is trivially easy for any person that has access to logs from a network device or can run a tcpdump on an hypervisor.
- MattJ100 5y agoTraffic correlation attacks are very difficult to mitigate. Even Tor is not immune to this (see research such as [1], and the Tor project's own statements that the design is not resistant to analysis by a global network observer). Also Briar may be unsuitable for some use cases where you want to remain anonymous to people you communicate with[2]. Some research has been done into communication networks that are resistant to traffic analysis, such as Vuvuzela[3]. Unfortunately most such solutions requires permanent connectivity and bandwidth utilization, which makes them impractical for battery-powered mobile devices. I'm firmly of the belief that no communication tool is suitable for all use-cases, but that we need to build open interoperable ecosystems that fulfil a range of needs, and help educate people about them. [1]: https://nusenu.medium.com/the-growing-problem-of-malicious-relays-on-the-tor-network-2f14198af548 https://nusenu.medium.com/the-growing-problem-of-malicious-r... [2]: https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-briar-provide-anonymity https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-b... [3]: https://vuvuzela.io/ https://vuvuzela.io/
- ezst 5y agotor isn't perfect, but if that's good-enough for your use-case, you can use/host a server over it: https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729ac https://gist.github.com/dllud/a46d4a555e31dfeff6ad41dcf20729...