5 ms·

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message

The article describes XMPP as "secure" by highlighting TLS (protecting data in transit only) and experimental OMEMO (protecting a small part of an XMPP message only if enabled and working). What about other crucial security features, see https://www.eff.org/deeplinks/2018/03/building-secure-messenger https://www.eff.org/deeplinks/2018/03/building-secure-messen...? Then, XMPP is described as "privacy respecting" mostly because you can use a nickname instead of a phone number for your account. What about all of the cleartext data and metadata that can be accessed by parties on the XMPP server, like the XMPP server admin, see https://infosec-handbook.eu/articles/xmpp-aitm/ https://infosec-handbook.eu/articles/xmpp-aitm/? This logic implies that e-mail is also secure and privacy respecting.

tialaramex 5y ago
I await future articles "Saudi Arabia: The resource poor country with a thriving democracy", "Bears: These vegetarians are too shy to defecate outdoors" and perhaps soon, "Popes: The married women who are rarely seen in church". But maybe they've just never seen a protocol more secure than telnet or more privacy respecting than the News Of The World ? Nobody show them Signal or their head might explode.
- jmnicolas 5y ago
  Thanks for the laugh, you should write news title it would be fun! Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. As the ex boss of NSA said "We Kill People Based on Metadata".
  - infosechandbook 5y ago
    > Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"? And how about looking at more than just an isolated property of a competitor? > As the ex boss of NSA said "We Kill People Based on Metadata". XMPP servers are a gold mine when it comes to metadata.
    - zaik 5y ago
      > It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. How many of your contacts who use Signal used their real phone number? > XMPP servers are a gold mine when it comes to metadata. Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.
      - infosechandbook 5y ago
        > How many of your contacts who use Signal used their real phone number? Most of them; however, there is no obligation to provide any personal data when registering a SIM card in my country. Even if providing personal data would be mandatory and if we assume that telcom providers track us all the time, then it doesn't mean that this data is accessible to the organization behind an instant messaging service. > Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP. This ignores that Signal and XMPP don't process the same amount of metadata in the first place, and the de-facto centralization of the XMPP network (also stated in our article -> the majority of XMPP users only uses a small number of public XMPP instances, and these XMPP instances are hosted by a tiny number of companies in mainly three countries on this planet).
      - rakoo 5y ago
        > Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. I believe the real reason Signal requires a phone number is that it is a pretty good anti-spam filter
  - tialaramex 5y ago
    But I already have a phone number. My friends already know my phone number. If I instead got a "nickname" it would be tialaramex of course, which is even more identifying than my phone number. If I chose a deliberate random pseudonymous "nickname" to avoid "metadata" - then nobody can contact me, what use is that? The NSA may "kill people based on metadata" but XMPP produces far more metadata for such decisions than Signal. XMPP encourages people to build clique servers, which fail a key security requirement "Don't Stand Out". The six other users of "Bob's 100% Preparedness Militia and True Patriots Server" may be quite sure Bob is trustworthy and won't rat on them, and maybe one of them only uses it to post funny GIFs of cats, but the loose metadata association between this group and a plot to kidnap a State Senator means all seven of them are targets anyway. But if you try not to stand out by using a popular server, that server's operators have far more insight into you than Signal's server operators do. Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. I know, because I decrypted the message, but Signal does not. That's a bunch of heavy cryptographic lifting, but from their point of view it was worth it to improve privacy.
    - zaik 5y ago
      > Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. This seems wrong. How could the Signal server have relayed the message from Steve to you if it does not know the recipient?
      - MattJ100 5y ago
        They have a feature called "sealed sender"[1]. Your Signal client authenticates to a Signal service that verifies you, and then signs and issues a certificate that you can use to vouch for your identity. Then, you can encrypt this certificate as part of your message. Then ask Signal to deliver your message to the recipient. The Signal server won't be able to tell the recipient the account that the message is from, but after the recipient decrypts the message they will see the signed certificate and know it was you. The problem with this is, Signal is centralized and they see the both the IP address (and other metadata) when you contact them to obtain the certificate and they they also see the IP address you send the message from. Correlation between the two Signal-operated services would reveal your identity. Unfortunately we, as users, have no way to know that this is not happening. [1]: https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/
  - tptacek 5y ago
    You think you're making an argument against Signal, but you're in fact making the argument for it. The reason Signal deals in your phone number is precisely to keep them from managing databases of metadata about who's talking to who; the phone numbers keeps the social graph on the clientside. Go look at RFC6121 Section 2 for one example of this. The point of Signal's design is that the server can't facilitate this kind of transaction, because it's unsafe for the server to keep that data in plaintext.
- singpolyma3 5y ago
  > Nobody show them Signal or their head might explode. Most popular XMPP encryption is literally signalprotocol, so I'm pretty sure the community is aware :)
- Andrew_nenakhov 5y ago
  Hard to believe someone compares proprietary centralised silo service like Signal to an open federated protocol.
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.
MattJ100 5y ago
I already responded to your "admin in the middle" article here: https://news.ycombinator.com/item?id=29104983 https://news.ycombinator.com/item?id=29104983 I run my own XMPP server (Snikket) for my family, and I have no fear of the metadata it (I) can theoretically see if I run tcpdump. Snikket has a short retention period (7 days by default), and it uses end-to-end encryption for message contents and files. It's much more important to me that I know where my data is - or rather, know where it isn't. I'd rather have that than be forced to entrust my metadata to a third party such as WhatsApp/Facebook, Telegram or Signal. Disclaimer: I'm an XMPP developer (as I know you know, but others may not).
- infosechandbook 5y ago
  > I already responded to your "admin in the middle" article here And we already responded here: https://news.ycombinator.com/item?id=29106376 https://news.ycombinator.com/item?id=29106376, and here: https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/ https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/, and somewhere on Reddit. > I run my own XMPP server (Snikket) for my family Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Can we agree that most non-technical XMPP users use a public XMPP server on the internet, where they might not know the individual or organization running the server? Where it remains unclear whether the XMPP server is set up and operated in a "secure" and "private" way? Where some XMPP server admins even fail to provide a privacy policy or try to hide their identity? Is this unique to XMPP? No, we never said this. Is this then a reason to ignore these issues? Also no. We should openly discuss pros and cons instead of highlighting isolated properties of a protocol that might be better in some situations than the same properties of a competitor.
  - MattJ100 5y ago
    > Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Yes. The majority of people cannot, and will not ever, run their own server. However my ideal is that the remaining "10%" of people who can, do so. Just as I do for my non-technical family members. I believe that there should be a trust relationship between service operators and their users, whatever form that takes. I work daily to try and make self-hosting XMPP easy and accessible to more people, so we can increase this "10%" fraction. For a similar perspective see: https://staltz.com/some-people-want-to-run-their-own-servers.html https://staltz.com/some-people-want-to-run-their-own-servers... Of course using public XMPP services anonymously (burner accounts, randomly-generated username, connect via Tor/VPN, etc.) is a thing that many people also do, but I think that's a minority use-case (that should still be supported). Tools such as Briar also cover many such use-cases adequately or better.
zaik 5y ago
You mention IP address, location based on IP addresses, timestamps, bytes transmitted and number of packets as metadata which is disclosed to the server admin. What alternative messenger do you suggest which does not disclose this metadata to the server operator?
- infosechandbook 5y ago
  > disclosed to the server admin Please read the article before and after these items. The first finding isn't about the server admin but about external parties such as law enforcement (not the user, not the admin). The reason for this finding: Some people claim XMPP traffic can't be censored as nobody can identify XMPP traffic from outside. This isn't true as this finding shows. You can easily detect and filter XMPP coming through network devices. This finding might be the most unsurprising one in the article from a technical perspective, and we are well aware of this.
Communitivity 5y ago
XMPP supports additional security if the server and client support it, however some of the extension proposals (XEPs) are deferred or experimental. My hope that the Special Interest Group (SIG) for encryption pulls these together into new high-security client and high-security server profiles. * https://xmpp.org/extensions/xep-0380.html https://xmpp.org/extensions/xep-0380.html - Explicit Message Encryption * https://xmpp.org/extensions/xep-0429.html https://xmpp.org/extensions/xep-0429.html - Not a XEP really, but the formation of a SIG to explore a more robust end-to-end encryption support * https://xmpp.org/extensions/xep-0420.html https://xmpp.org/extensions/xep-0420.html - Encrypting content specific to certain extensions * https://xmpp.org/extensions/xep-0290.html https://xmpp.org/extensions/xep-0290.html - Digital signatures in XMPP

tialaramex 5y ago

I await future articles "Saudi Arabia: The resource poor country with a thriving democracy", "Bears: These vegetarians are too shy to defecate outdoors" and perhaps soon, "Popes: The married women who are rarely seen in church". But maybe they've just never seen a protocol more secure than telnet or more privacy respecting than the News Of The World ? Nobody show them Signal or their head might explode.

jmnicolas 5y ago
Thanks for the laugh, you should write news title it would be fun! Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. As the ex boss of NSA said "We Kill People Based on Metadata".
- infosechandbook 5y ago
  > Anyway the problem of Signal is that you have to use your phone number and a phone number is a much stronger link to you than an ip for example. Signal requires access to a valid phone number during registration, not "your phone number." It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. How is this a "much stronger link to you than an ip"? And how about looking at more than just an isolated property of a competitor? > As the ex boss of NSA said "We Kill People Based on Metadata". XMPP servers are a gold mine when it comes to metadata.
  - zaik 5y ago
    > It can even be a virtual/landline/temporary phone number without any SIM cards or cell phones involved. Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. How many of your contacts who use Signal used their real phone number? > XMPP servers are a gold mine when it comes to metadata. Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP.
    - infosechandbook 5y ago
      > How many of your contacts who use Signal used their real phone number? Most of them; however, there is no obligation to provide any personal data when registering a SIM card in my country. Even if providing personal data would be mandatory and if we assume that telcom providers track us all the time, then it doesn't mean that this data is accessible to the organization behind an instant messaging service. > Then even more so for Signal, since metadata for all users can be collected by a single entity. This is not possible in a federated network like XMPP. This ignores that Signal and XMPP don't process the same amount of metadata in the first place, and the de-facto centralization of the XMPP network (also stated in our article -> the majority of XMPP users only uses a small number of public XMPP instances, and these XMPP instances are hosted by a tiny number of companies in mainly three countries on this planet).
    - rakoo 5y ago
      > Then contact discovery would not work, which is the main advantage of collecting the phone number in the first place. I believe the real reason Signal requires a phone number is that it is a pretty good anti-spam filter
- tialaramex 5y ago
  But I already have a phone number. My friends already know my phone number. If I instead got a "nickname" it would be tialaramex of course, which is even more identifying than my phone number. If I chose a deliberate random pseudonymous "nickname" to avoid "metadata" - then nobody can contact me, what use is that? The NSA may "kill people based on metadata" but XMPP produces far more metadata for such decisions than Signal. XMPP encourages people to build clique servers, which fail a key security requirement "Don't Stand Out". The six other users of "Bob's 100% Preparedness Militia and True Patriots Server" may be quite sure Bob is trustworthy and won't rat on them, and maybe one of them only uses it to post funny GIFs of cats, but the loose metadata association between this group and a plot to kidnap a State Senator means all seven of them are targets anyway. But if you try not to stand out by using a popular server, that server's operators have far more insight into you than Signal's server operators do. Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. I know, because I decrypted the message, but Signal does not. That's a bunch of heavy cryptographic lifting, but from their point of view it was worth it to improve privacy.
  - zaik 5y ago
    > Remember, when my friend Steve sent me a Signal message last week, Signal does not know who sent that. This seems wrong. How could the Signal server have relayed the message from Steve to you if it does not know the recipient?
    - MattJ100 5y ago
      They have a feature called "sealed sender"[1]. Your Signal client authenticates to a Signal service that verifies you, and then signs and issues a certificate that you can use to vouch for your identity. Then, you can encrypt this certificate as part of your message. Then ask Signal to deliver your message to the recipient. The Signal server won't be able to tell the recipient the account that the message is from, but after the recipient decrypts the message they will see the signed certificate and know it was you. The problem with this is, Signal is centralized and they see the both the IP address (and other metadata) when you contact them to obtain the certificate and they they also see the IP address you send the message from. Correlation between the two Signal-operated services would reveal your identity. Unfortunately we, as users, have no way to know that this is not happening. [1]: https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/
- tptacek 5y ago
  You think you're making an argument against Signal, but you're in fact making the argument for it. The reason Signal deals in your phone number is precisely to keep them from managing databases of metadata about who's talking to who; the phone numbers keeps the social graph on the clientside. Go look at RFC6121 Section 2 for one example of this. The point of Signal's design is that the server can't facilitate this kind of transaction, because it's unsafe for the server to keep that data in plaintext.
singpolyma3 5y ago
> Nobody show them Signal or their head might explode. Most popular XMPP encryption is literally signalprotocol, so I'm pretty sure the community is aware :)
Andrew_nenakhov 5y ago
Hard to believe someone compares proprietary centralised silo service like Signal to an open federated protocol.

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.

MattJ100 5y ago

I already responded to your "admin in the middle" article here: https://news.ycombinator.com/item?id=29104983 https://news.ycombinator.com/item?id=29104983 I run my own XMPP server (Snikket) for my family, and I have no fear of the metadata it (I) can theoretically see if I run tcpdump. Snikket has a short retention period (7 days by default), and it uses end-to-end encryption for message contents and files. It's much more important to me that I know where my data is - or rather, know where it isn't. I'd rather have that than be forced to entrust my metadata to a third party such as WhatsApp/Facebook, Telegram or Signal. Disclaimer: I'm an XMPP developer (as I know you know, but others may not).

infosechandbook 5y ago
> I already responded to your "admin in the middle" article here And we already responded here: https://news.ycombinator.com/item?id=29106376 https://news.ycombinator.com/item?id=29106376, and here: https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/ https://infosec-handbook.eu/news/2021-11-06-xmpp-aitm/, and somewhere on Reddit. > I run my own XMPP server (Snikket) for my family Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Can we agree that most non-technical XMPP users use a public XMPP server on the internet, where they might not know the individual or organization running the server? Where it remains unclear whether the XMPP server is set up and operated in a "secure" and "private" way? Where some XMPP server admins even fail to provide a privacy policy or try to hide their identity? Is this unique to XMPP? No, we never said this. Is this then a reason to ignore these issues? Also no. We should openly discuss pros and cons instead of highlighting isolated properties of a protocol that might be better in some situations than the same properties of a competitor.
- MattJ100 5y ago
  > Can we agree that >90% of non-technical XMPP users likely don't run their own XMPP server? Yes. The majority of people cannot, and will not ever, run their own server. However my ideal is that the remaining "10%" of people who can, do so. Just as I do for my non-technical family members. I believe that there should be a trust relationship between service operators and their users, whatever form that takes. I work daily to try and make self-hosting XMPP easy and accessible to more people, so we can increase this "10%" fraction. For a similar perspective see: https://staltz.com/some-people-want-to-run-their-own-servers.html https://staltz.com/some-people-want-to-run-their-own-servers... Of course using public XMPP services anonymously (burner accounts, randomly-generated username, connect via Tor/VPN, etc.) is a thing that many people also do, but I think that's a minority use-case (that should still be supported). Tools such as Briar also cover many such use-cases adequately or better.

zaik 5y ago

You mention IP address, location based on IP addresses, timestamps, bytes transmitted and number of packets as metadata which is disclosed to the server admin. What alternative messenger do you suggest which does not disclose this metadata to the server operator?

infosechandbook 5y ago
> disclosed to the server admin Please read the article before and after these items. The first finding isn't about the server admin but about external parties such as law enforcement (not the user, not the admin). The reason for this finding: Some people claim XMPP traffic can't be censored as nobody can identify XMPP traffic from outside. This isn't true as this finding shows. You can easily detect and filter XMPP coming through network devices. This finding might be the most unsurprising one in the article from a technical perspective, and we are well aware of this.

Communitivity 5y ago

XMPP supports additional security if the server and client support it, however some of the extension proposals (XEPs) are deferred or experimental. My hope that the Special Interest Group (SIG) for encryption pulls these together into new high-security client and high-security server profiles. * https://xmpp.org/extensions/xep-0380.html https://xmpp.org/extensions/xep-0380.html - Explicit Message Encryption * https://xmpp.org/extensions/xep-0429.html https://xmpp.org/extensions/xep-0429.html - Not a XEP really, but the formation of a SIG to explore a more robust end-to-end encryption support * https://xmpp.org/extensions/xep-0420.html https://xmpp.org/extensions/xep-0420.html - Encrypting content specific to certain extensions * https://xmpp.org/extensions/xep-0290.html https://xmpp.org/extensions/xep-0290.html - Digital signatures in XMPP