3 ms·

The main reason we won't list it on privacyguides.org is the encryption is not always on by default. There are two major problems, the implementations and the

by dngray 2y ago

The main reason we won't list it on privacyguides.org is the encryption is not always on by default. There are two major problems, the implementations and the fact the spec isn't specific. I'm not particularly bothered by the imaginary, the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things. As for the reply from the spec author, I had a negative opinion of that. To me it looks like they just tried to copy signal's encryption so that people could claim that XMPP has E2EE, without any real design or thought of the implementation. One of the other things I hate about XMPP (and you mentioned it above with the jingle debacle), but there are other cases where there's multiple XEPs for the same thing. Some of them are widely used despite being marked as "experimental". The documents are not cohesive and is a mess which is probably why the implementations are also bad (unlike the Matrix spec). Encryption is just another one of those things, just like file transfer. If I was deciding on a new project to develop a client for XMPP would be the least attractive project for me to work on. Put it that way. Without enthusiastic developers that think this thing sounds cool there simply won't be any good software. The other thing also not mentioned is that the OMEMO encryption only applies to text messages and not all the other things, ie VOIP, status changes etc. There is a fair bit of metadata on the server side https://web.archive.org/web/20211215132539/https://infosec-handbook.eu/articles/xmpp-aitm/ https://web.archive.org/web/20211215132539/https://infosec-h... and attacks like this are just downright scary https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/ I used to use XMPP but haven't in about a decade. Nobody I know uses it either. (Even the couple of evangelists I knew moved to Matrix long ago)

AshamedCaptain 2y ago
> the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things. Lighten things? Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion? Don't try to make this into thinking I'm criticizing furriness -- it's definitely not about that. > There is a fair bit of metadata on the server side This is much less critical when the protocol is federated. Even E2EE itself may become second priority rather than first in such an environment. > Without enthusiastic developers that think this thing sounds cool there simply won't be any good software. This is a ridiculous statement.
- dngray 2y ago
  > This is much less critical when the protocol is federated False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix. The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.
  - AshamedCaptain 2y ago
    Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.
    - dngray 2y ago
      > Routing data between servers and networks you literally control This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting. TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population. > Leaking metadata to a centralized service is simply inevitable by pure physics Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Signal has a lot less metadata than XMPP.
      - AshamedCaptain 2y ago
        XMPP largest deployments are in enterprises. I do not disagree with this. To go from there to "it is not designed to be a private protocol" is a stretch. And does that invalidate any of my points? > Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Yeah, no. Timing alone is enough to clearly distinguish a sender, and any attempts like these is pure astronaut engineering to obfuscate something that is trivial to recover by a million side channels. There is just No. Way. to eliminate the problem of metadata leaks to a centralized server, other than making it practically distributed/P2P. The more time it takes for people to realize this, the worse society becomes.
upofadown 2y ago
>and attacks like this are just downright scary https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/ That attack strikes me as generic. As in not anything to do with XMPP specifically.
- dngray 2y ago
  > As in not anything to do with XMPP specifically. The fact that STARTTLS is even possible with that protocol is bad.
  - upofadown 2y ago
    What does STARTTLS have to do with a MITM attack based on certificate substitution? What XMPP servers still allow unencrypted client connections by default?
inputmice 2y ago
> and attacks like this are just downright scary > https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/ With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.
pluto_modadic 2y ago
solid points!
singpolyma3 2y ago
While it's true OMEMO isn't used for voice and video, that's because voice and video are already e2ee with the more appropriate srtp

by dngray 2y ago

AshamedCaptain 2y ago

> the dude is a furry what do you expect? Some furry bloggers do have pictures throughout their blog posts to split things up and lighten things. Lighten things? Are you saying that putting images of cartoon characters puking at the logos of your product lightens things and provokes healthy discussion? Don't try to make this into thinking I'm criticizing furriness -- it's definitely not about that. > There is a fair bit of metadata on the server side This is much less critical when the protocol is federated. Even E2EE itself may become second priority rather than first in such an environment. > Without enthusiastic developers that think this thing sounds cool there simply won't be any good software. This is a ridiculous statement.

dngray 2y ago
> This is much less critical when the protocol is federated False. Federated protocols typically have a lot more, as there is routing data between servers. The same goes for things like Matrix. The only thing that Matrix servers can see however realistically is the room id, and other participants. Unlike XMPP where they can copy your roster. In the case of ejabberd debug logs can include your password lol (or at least could in November 2021). I doubt that's changed.
- AshamedCaptain 2y ago
  Routing data between servers and networks you literally control. There is simply no possible discussion on this point. A centralized service doesn't allow that choice. Leaking metadata to a centralized service is simply inevitable by pure physics.
  - dngray 2y ago
    > Routing data between servers and networks you literally control This isn't always the case, not every user is a server admin. Also for group chats other server admins will certainly know what data your requesting. TLDR is that XMPP is not a private protocol, and that was never its intention. It was actually very centralized in it's original usage and the designers clearly envisaged similar usage to email ie $companyA.com employees talking to $companyB.com not some sort of "private messenger" competitor to Matrix or Signal which were meant to be used by the wider general population. > Leaking metadata to a centralized service is simply inevitable by pure physics Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Signal has a lot less metadata than XMPP.
    - AshamedCaptain 2y ago
      XMPP largest deployments are in enterprises. I do not disagree with this. To go from there to "it is not designed to be a private protocol" is a stretch. And does that invalidate any of my points? > Not necessarily true https://signal.org/blog/sealed-sender/ https://signal.org/blog/sealed-sender/ Yeah, no. Timing alone is enough to clearly distinguish a sender, and any attempts like these is pure astronaut engineering to obfuscate something that is trivial to recover by a million side channels. There is just No. Way. to eliminate the problem of metadata leaks to a centralized server, other than making it practically distributed/P2P. The more time it takes for people to realize this, the worse society becomes.

upofadown 2y ago

>and attacks like this are just downright scary https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/ That attack strikes me as generic. As in not anything to do with XMPP specifically.

dngray 2y ago
> As in not anything to do with XMPP specifically. The fact that STARTTLS is even possible with that protocol is bad.
- upofadown 2y ago
  What does STARTTLS have to do with a MITM attack based on certificate substitution? What XMPP servers still allow unencrypted client connections by default?

inputmice 2y ago

> and attacks like this are just downright scary > https://notes.valdikss.org.ru/jabber.ru-mitm/ https://notes.valdikss.org.ru/jabber.ru-mitm/ With an up to date Conversations on a modern server we have a pretty good chance to detect or prevent that style of attack due to a mechanism called SASL Channel Binding.

pluto_modadic 2y ago

solid points!

singpolyma3 2y ago

While it's true OMEMO isn't used for voice and video, that's because voice and video are already e2ee with the more appropriate srtp