7 ms·

> XMPP is as secure as Signal nowadays, it implements the same encryption scheme Signal enforces E2EE, you can't disable it. If XMPP supports E2EE depends on t

> XMPP is as secure as Signal nowadays, it implements the same encryption scheme Signal enforces E2EE, you can't disable it. If XMPP supports E2EE depends on the XMPP clients and servers, so it isn't enforced and can be disabled. Server admins can even inject XMPP messages that look like coming from the legitimate sender. This is far from "secure as Signal."

zaik 5y ago
> Server admins can even inject XMPP messages that look like coming from the legitimate sender. How should that be possible if OMEMO is enabled (which is the default in more modern clients)?
- infosechandbook 5y ago
  > How should that be possible if OMEMO is enabled (which is the default in more modern clients)? See https://infosec-handbook.eu/articles/xmpp-aitm/#t5 https://infosec-handbook.eu/articles/xmpp-aitm/#t5 TL;DR: XMPP clients can't distinguish between legitimate and injected messages, even if OMEMO is enabled. The XMPP client just displays injected messages as an unencrypted message from the sender.
  - zaik 5y ago
    In Conversations unauthenticated messages are displayed with a red background, whereas OMEMO authenticated messages are displayed in green. They do not look the same.
    - infosechandbook 5y ago
      Nobody claimed that they look the same. As mentioned in the linked article, the behavior upon receiving an injected message is client specific. In any way, the injected message is somehow presented to the (non-technical) user who might then be targeted. We all know the same problem exists in the e-mail world.
      - MattJ100 5y ago
        Signal operators can also inject messages to people. So this is a strange comparison. What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. Which is the entire point of E2EE.
        infosechandbook 5y ago
        > Signal operators can also inject messages to people. Did you check this, and can you demonstrate a server-side message injection so that the Signal clients display the injected message correctly, leaving the recipient vulnerable to spoofed messages? Would be nice to see for the security community. > What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. What also holds true: One system enforces E2EE; for the other system E2EE is optional, depends on the client, and while spoofing could be detected thanks to E2EE, all clients we checked didn't detect it (Gajim, Conversations, Psi+, Profanity).
        Andrew_nenakhov 5y ago
        If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.
        infosechandbook 5y ago
        > If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Signal wins as these security features aren't optional but enforced and more mature. Privacy: This section in OP's article addresses distinct things to then somehow claim XMPP is private. Let's compare them: XMPP is an open standard -> Doesn't this apply to Signal, too? Some developers claim not to track users -> Same applies to Signal. OMEMO adds security -> explained above, already in Signal. Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy. Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number, and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal. Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature. Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups. User is the only one deciding about/controlling their account and personal data (how can this be ensured if this data is exposed to the server and other users) -> Again a vague statement without any explanation. So Signal users can also decide about their data. Then, OP's article suddenly ends without going into any details. The article finishes with "phone numbers, centralization bad; username, decentralization good." This isn't balanced at all. > Signal admins, who control the server and ship an app to you which you can't really verify. If we write exactly the same about XMPP, people immediately state, "XMPP clients and servers are open source, everybody can look at their code." So let's apply the same logic to Signal. If you don't want to apply this logic, then yes, we can't also verify if we connect to a malicious/manipulated XMPP server even if its source code is open. The same applies to apps. And Reproducible builds don't come with this guarantee, too.
jancsika 5y ago
> Signal enforces E2EE, you can't disable it. Exactly! It seems like there is a combination of tenuous assertions being made about XMPP security here, followed by naive questions from people who apparently don't understand the basic feature set of something like Signal. Any clue why this is happening?
- topdancing 5y ago
  XMPP is about choice. I use OMEMO everywhere. However, I do know of people out there who simply do not see the point of OMEMO as, when they are the server admin, OMEMO adds no value over TLS. OMEMO also doesn't make sense in large public groups, cause you're not going to go and verify 100+ people's encryption keys one by one. OMEMO and end-to-end encryption are also incompatible with keeping a reliable server-side archive of your messages - which will be accessible to all future XMPP clients that you add to your account - which apparently some people want. You can see this at the table at https://conversations.im/omemo/ https://conversations.im/omemo/ Meanwhile, you occasionally find people on the Signal subreddit bemoaning that they lost their entire message history with a loved one because some backup file got corrupted and failed to restore or; they lost some device. Here's an example: https://www.reddit.com/r/signal/comments/rbtdtb/ https://www.reddit.com/r/signal/comments/rbtdtb/ As I said: XMPP is about choice.
Andrew_nenakhov 5y ago
Signal admins too can ship you an app version that would show injected messages like coming from legitimate sender. [1] However, while you can be your own xmpp server admin, you can't be Signal admin. [1]: And for god's sake pls don't even start on reproducible builds, nobody really verifies every app updates.
- infosechandbook 5y ago
  You just wrote it is "silly" to compare XMPP with Signal while constantly doing it yourself. > Signal admins too can ship you an app Or I could just use my own Signal client since it is open-source and there are several working forks such as https://molly.im/ https://molly.im/. How do "Signal admins" (whoever this is) manipulate these open-source forks? Instead of providing any proof or details, you just post one assumption after another to distract from obvious problems with current XMPP servers and clients. As soon as we debunk a myth, the next assumption comes up.

zaik 5y ago

> Server admins can even inject XMPP messages that look like coming from the legitimate sender. How should that be possible if OMEMO is enabled (which is the default in more modern clients)?

infosechandbook 5y ago
> How should that be possible if OMEMO is enabled (which is the default in more modern clients)? See https://infosec-handbook.eu/articles/xmpp-aitm/#t5 https://infosec-handbook.eu/articles/xmpp-aitm/#t5 TL;DR: XMPP clients can't distinguish between legitimate and injected messages, even if OMEMO is enabled. The XMPP client just displays injected messages as an unencrypted message from the sender.
- zaik 5y ago
  In Conversations unauthenticated messages are displayed with a red background, whereas OMEMO authenticated messages are displayed in green. They do not look the same.
  - infosechandbook 5y ago
    Nobody claimed that they look the same. As mentioned in the linked article, the behavior upon receiving an injected message is client specific. In any way, the injected message is somehow presented to the (non-technical) user who might then be targeted. We all know the same problem exists in the e-mail world.
    - MattJ100 5y ago
      Signal operators can also inject messages to people. So this is a strange comparison. What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. Which is the entire point of E2EE.
      - infosechandbook 5y ago
        > Signal operators can also inject messages to people. Did you check this, and can you demonstrate a server-side message injection so that the Signal clients display the injected message correctly, leaving the recipient vulnerable to spoofed messages? Would be nice to see for the security community. > What holds true in both systems is that if someone does this, it's detectable thanks to E2EE. What also holds true: One system enforces E2EE; for the other system E2EE is optional, depends on the client, and while spoofing could be detected thanks to E2EE, all clients we checked didn't detect it (Gajim, Conversations, Psi+, Profanity).
        Andrew_nenakhov 5y ago
        If you start with an argument 'non trusted server admin can do things to my xmpp', it's strange that you don't apply same logic to Signal admins, who control the server and ship an app to you which you can't really verify.
        infosechandbook 5y ago
        > If you start with an argument ..., it's strange that you don't apply same logic to Signal admins Where is this 1-to-1 comparison you demand in the OP's original article? Security: They mainly highlight TLS and experimental OMEMO as the main security features of XMPP. TLS is also present in Signal, and OMEMO is based on the Signal Protocol, which is enforced for Signal. So comparing this 1-to-1 in OP's article, Signal wins as these security features aren't optional but enforced and more mature. Privacy: This section in OP's article addresses distinct things to then somehow claim XMPP is private. Let's compare them: XMPP is an open standard -> Doesn't this apply to Signal, too? Some developers claim not to track users -> Same applies to Signal. OMEMO adds security -> explained above, already in Signal. Decentralized -> The first difference, and here we can write another article on why decentralization doesn't magically add any security or privacy. Users can choose a username, doesn't need phone number -> Second difference, which doesn't apply to all XMPP clients as some may require your phone number, and if we assume people can choose a non-identifiable username, then we can also assume people can choose a non-identifiable phone number. User may not be identifiable -> Another vague statement without any explanation that we can just assume the same way for Signal. Presence status shared with others (without mentioning that server admins can see this, too) -> Signal comes without this feature. Only nicknames exposed in MUCs (again without mentioning what MUC admins and server admins see) -> Signal lets users decide if they want to share their phone number and username with groups. User is the only one deciding about/controlling their account and personal data (how can this be ensured if this data is exposed to the server and other users) -> Again a vague statement without any explanation. So Signal users can also decide about their data. Then, OP's article suddenly ends without going into any details. The article finishes with "phone numbers, centralization bad; username, decentralization good." This isn't balanced at all. > Signal admins, who control the server and ship an app to you which you can't really verify. If we write exactly the same about XMPP, people immediately state, "XMPP clients and servers are open source, everybody can look at their code." So let's apply the same logic to Signal. If you don't want to apply this logic, then yes, we can't also verify if we connect to a malicious/manipulated XMPP server even if its source code is open. The same applies to apps. And Reproducible builds don't come with this guarantee, too.

jancsika 5y ago

> Signal enforces E2EE, you can't disable it. Exactly! It seems like there is a combination of tenuous assertions being made about XMPP security here, followed by naive questions from people who apparently don't understand the basic feature set of something like Signal. Any clue why this is happening?

topdancing 5y ago
XMPP is about choice. I use OMEMO everywhere. However, I do know of people out there who simply do not see the point of OMEMO as, when they are the server admin, OMEMO adds no value over TLS. OMEMO also doesn't make sense in large public groups, cause you're not going to go and verify 100+ people's encryption keys one by one. OMEMO and end-to-end encryption are also incompatible with keeping a reliable server-side archive of your messages - which will be accessible to all future XMPP clients that you add to your account - which apparently some people want. You can see this at the table at https://conversations.im/omemo/ https://conversations.im/omemo/ Meanwhile, you occasionally find people on the Signal subreddit bemoaning that they lost their entire message history with a loved one because some backup file got corrupted and failed to restore or; they lost some device. Here's an example: https://www.reddit.com/r/signal/comments/rbtdtb/ https://www.reddit.com/r/signal/comments/rbtdtb/ As I said: XMPP is about choice.

Andrew_nenakhov 5y ago

Signal admins too can ship you an app version that would show injected messages like coming from legitimate sender. [1] However, while you can be your own xmpp server admin, you can't be Signal admin. [1]: And for god's sake pls don't even start on reproducible builds, nobody really verifies every app updates.

infosechandbook 5y ago
You just wrote it is "silly" to compare XMPP with Signal while constantly doing it yourself. > Signal admins too can ship you an app Or I could just use my own Signal client since it is open-source and there are several working forks such as https://molly.im/ https://molly.im/. How do "Signal admins" (whoever this is) manipulate these open-source forks? Instead of providing any proof or details, you just post one assumption after another to distract from obvious problems with current XMPP servers and clients. As soon as we debunk a myth, the next assumption comes up.