4 ms·

The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are uniqu

The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP. Half the article is dedicated to obsessing that the server can see your IP address. This is true of every internet service, and is how the internet works. Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use. Common alternatives to XMPP that people may recommend include Signal and Matrix, but both certainly see your IP address just as easily. XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication. Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use. Again, not a problem with XMPP specifically. Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering. Full disclosure: I'm actively involved in various XMPP projects, including the XMPP Standards Foundation, Prosody and Snikket. Obviously I have a very keen interest in protocol design, secure online communication and the various available platforms/tools.

southerntofu 5y ago
> Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use. So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP, but i didn't try to reproduce yet. This would be worth investigating with wireshark and a couple of volunteers. > not a problem with XMPP specifically. There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. So your own server/admin will know when a client-to-server (c2s) connection is active, but in the XMPP ecosystem it's rather common for clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. Maybe something to investigate in the future.
- LogonType10 5y ago
  Would these leaks be solved by implementing a VPN at the router instead of the host?
- MattJ100 5y ago
  > There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. [...] clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join). With the rise of mobile clients, statuses other than 'online' are far less common than they used to be, because they are growing irrelevant. Advertising online status to the whole world is what WhatsApp does ( https://news.ycombinator.com/item?id=26809770 https://news.ycombinator.com/item?id=26809770 ).
  - southerntofu 5y ago
    > and typically groups that you join So more or less to the entire world if you join public chats. Even if you use different nicknames, occupant-id (used for message edits) may be used to track your presence across rooms. > Advertising online status to the whole world is what WhatsApp does If we're pointing the finger, i'd recommend reading this document about what Signal does wrong in terms of privacy and security. It's overall a good read of what not to do in private messenger UX: https://north-shore.info/wp-content/uploads/2019/06/signalfails-imposed.pdf https://north-shore.info/wp-content/uploads/2019/06/signalfa...
  - GTP 5y ago
    >They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join) But in the article they showed how the server administrator can easily add contacts to a user's contact list. So my understanding is that the user isn't really in control of who can see this information, as the server admin could add a new contact that can then see the presence status. Correct? Edit: formatting
    - 5y ago
rhn_mk1 5y ago
> XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication. There are plenty of authentication protocols that don't send passwords in cleartext. WPA would be rather useless if that happened, for example. Granted, the server operator can impersonate anyone they want already, but password leaks are a thing. Server-side contact handling is independent of end-to-end ecryption, and doesn't need to be plaintext either. Pretty much the only excusable things here are what's related to IP.
- MattJ100 5y ago
  I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged. Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user selects their own password. This step is where the password is sent (once) to the server, upon which it is hashed and stored. That step doesn't happen in WPA, however the owner of the access point does have to securely transmit the password to the clients somehow.
  - yosamino 5y ago
    > All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged. Huh, I didn't realize that SCRAM is this widely supported https://xmpp.net/reports.php https://xmpp.net/reports.php Thanks for the hint!
  - rhn_mk1 5y ago
    I see the distinction, but when I use public key cryptography, the keys are not symmetrical, and the server never sees my secret. Indeed it was my mistake when I searched for authentication mechanisms, which aren't concerned with the initial exchange. Still, as a non-cryptographer, I have to wonder if it's possible to make a password work while using public key crptography. Perhaps the way SSH does it: use password to unlock the private key, but only send the public key?
infosechandbook 5y ago
Hi, authors here (Again, as we already have had the pleasure a while ago). > The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP. The article never states that these issues exclusively apply to XMPP. In our opinion, users should be aware of these downsides that might be obvious to technical people, but aren't obvious to others. And no, not all the points apply equally to other services. Even if this would be the case, then should we just withhold downsides of XMPP because these downsides might also apply to unrelated communication protocols? This article is about XMPP, not about something else. > Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use. No, as stated in the article, you can't solve most problems with XMPP by enforcing E2EE in XMPP. This article is about XMPP, not about unrelated communication protocols that might have similar problems. > Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering. Ehm, no, again, this article lists verifiable downsides of XMPP. People should be aware of these downsides and decide on their own what they want to do. There is no need to call it "biased scaremongering." > Full disclosure Full disclosure: We aren't involved in any XMPP projects or any other projects related to instant messaging. No party paid for our article.

southerntofu 5y ago

> Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use. So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP, but i didn't try to reproduce yet. This would be worth investigating with wireshark and a couple of volunteers. > not a problem with XMPP specifically. There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. So your own server/admin will know when a client-to-server (c2s) connection is active, but in the XMPP ecosystem it's rather common for clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. Maybe something to investigate in the future.

LogonType10 5y ago
Would these leaks be solved by implementing a VPN at the router instead of the host?
MattJ100 5y ago
> There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. [...] clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join). With the rise of mobile clients, statuses other than 'online' are far less common than they used to be, because they are growing irrelevant. Advertising online status to the whole world is what WhatsApp does ( https://news.ycombinator.com/item?id=26809770 https://news.ycombinator.com/item?id=26809770 ).
- southerntofu 5y ago
  > and typically groups that you join So more or less to the entire world if you join public chats. Even if you use different nicknames, occupant-id (used for message edits) may be used to track your presence across rooms. > Advertising online status to the whole world is what WhatsApp does If we're pointing the finger, i'd recommend reading this document about what Signal does wrong in terms of privacy and security. It's overall a good read of what not to do in private messenger UX: https://north-shore.info/wp-content/uploads/2019/06/signalfails-imposed.pdf https://north-shore.info/wp-content/uploads/2019/06/signalfa...
- GTP 5y ago
  >They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join) But in the article they showed how the server administrator can easily add contacts to a user's contact list. So my understanding is that the user isn't really in control of who can see this information, as the server admin could add a new contact that can then see the presence status. Correct? Edit: formatting
  - 5y ago

rhn_mk1 5y ago

> XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication. There are plenty of authentication protocols that don't send passwords in cleartext. WPA would be rather useless if that happened, for example. Granted, the server operator can impersonate anyone they want already, but password leaks are a thing. Server-side contact handling is independent of end-to-end ecryption, and doesn't need to be plaintext either. Pretty much the only excusable things here are what's related to IP.

MattJ100 5y ago
I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged. Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user selects their own password. This step is where the password is sent (once) to the server, upon which it is hashed and stored. That step doesn't happen in WPA, however the owner of the access point does have to securely transmit the password to the clients somehow.
- yosamino 5y ago
  > All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged. Huh, I didn't realize that SCRAM is this widely supported https://xmpp.net/reports.php https://xmpp.net/reports.php Thanks for the hint!
- rhn_mk1 5y ago
  I see the distinction, but when I use public key cryptography, the keys are not symmetrical, and the server never sees my secret. Indeed it was my mistake when I searched for authentication mechanisms, which aren't concerned with the initial exchange. Still, as a non-cryptographer, I have to wonder if it's possible to make a password work while using public key crptography. Perhaps the way SSH does it: use password to unlock the private key, but only send the public key?

infosechandbook 5y ago

Hi, authors here (Again, as we already have had the pleasure a while ago). > The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP. The article never states that these issues exclusively apply to XMPP. In our opinion, users should be aware of these downsides that might be obvious to technical people, but aren't obvious to others. And no, not all the points apply equally to other services. Even if this would be the case, then should we just withhold downsides of XMPP because these downsides might also apply to unrelated communication protocols? This article is about XMPP, not about something else. > Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use. No, as stated in the article, you can't solve most problems with XMPP by enforcing E2EE in XMPP. This article is about XMPP, not about unrelated communication protocols that might have similar problems. > Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering. Ehm, no, again, this article lists verifiable downsides of XMPP. People should be aware of these downsides and decide on their own what they want to do. There is no need to call it "biased scaremongering." > Full disclosure Full disclosure: We aren't involved in any XMPP projects or any other projects related to instant messaging. No party paid for our article.