Implement skip of encrypted XMPP messages

[g00g1]

End-to-end encrypted XMPP messages can't be decrypted by the matterbridge yet - they get relayed to other chats as their plaintext fallback body such as "I sent you an OMEMO encrypted message but your client doesn't support that".

This change adds a boolean option SkipEncrypted for XMPP gateway with a default value false to keep current behavior unchanged.

[selfhoster1312]

That's a very good catch, thanks!

I'm wondering what should be a good default here. Most MUC chatrooms are not encrypted so is it useful to implement OMEMO at all?

I think i'm partial to no OMEMO support with:

• a one-off message about not supporting OMEMO in all chatrooms across the gateway
• log warn every time a new encrypted message is received without relaying it at all

What do you think? Is that reasonable for you to make that the default behavior, but still relay a public warning once about a probable misconfiguration?

[g00g1]

I am sure about most, but if I am correct, Matrix handler supports encryption, so it would be consistent to implement it for XMPP one day.

If I understood your idea correctly, I am in favour of "a one-off message about not supporting OMEMO in all chatrooms across the gateway" on first encrypted message occurrence and skip all further ones to avoid spamming.

However, the way I made this particular change is because goal was to preserve existing behaviour (blindly relay everything) while being able to opt-in to skip encrypted messages if some members of MUC accidentally or purposefully enabled it to share some confidential thing that should not be stored in plaintext. I do agree that it is not something common and probably weird, but in private MUC where everyone knows everyone else it could make sense.

[selfhoster1312]

So if i understand there's three different questions:

• should we support OMEMO?
• should we allow disabling OMEMO so that people can send a one-off message explicitly encrypted not to be relayed/logged?
• what to do when we receive a message that we can't decrypt?

I think we should support OMEMO. I'm not sure there's value in skipping specific messages if we support OMEMO: do you know anyone who would enable encryption for a single message then turn it off? (i've never heard of this before)

[g00g1]

I would like to point out that in scenario when XMPP gets bridged to Telegram (or Discord), OMEMO becomes useless because plaintext is leaked to a third party (Telegram/Discord) if decryption is implemented by the bridge. Hence if you have same MUC where both encrypted and plaintext messages are stored but only plaintext get relayed to unencrypted chats, this per-message difference makes sense to me to avoid leaking some sensitive content that must be E2EE'd.

[selfhoster1312]

Yes, i understand that usecase in theory. But do you know people who would actually use this? Bridging their super sensitive chatroom except for a few messages every now and then? Does that even work well across XMPP clients to just start and stop encryption randomly?

My personal feeling is that public chatrooms should not be encrypted and that private chatrooms should not be bridged to random 3rd parties (eg. Telegram). Does that make sense to you?

[g00g1]

I agree with you on public chatrooms, but as for private ones I am the one who runs a bridge with such constraint for a private group - unfortunately, a few people not yet willing to use XMPP and stuck with Telegram. I would also like to highlight that it is true that there is a risk that someone could quote sensitive message without OMEMO enabled and accidentally leak it.

[selfhoster1312]

OK so you want a chatroom with your friends from Telegram, but you don't want them to receive 100% of the messages. Is that correct? Would it maybe make sense to have a separate "more" private chatroom which is not relayed to 3rd party networks?

Sorry i hope i'm not condescending. I'm not trying to deny your usecase, i just find it really weird and i'm guessing it may produce unexpected results in clients due to how OMEMO (TOFU + key rotation via double ratchet) works. If you say it works and that's definitely what you want to be doing, then i case we could accomodate this usecase indeed.

[g00g1]

Having more groups is less convenient due to necessity to switch between them, selectively (and rarely) enabling OMEMO looks a good tradeoffs to me, with a safeguard to not flood the unencrypted end with "this message was encrypted with OMEMO" if someone forgot to disable it.

I do agree that the use case is weird, no worries :)

I can't elaborate on how this is reliable because this setup runs only for a few days in a not very active chat. So far no issues with Gajim and Conversations across multiple devices.

[selfhoster1312]

I don't think i truly appreciate the usecase, but that sounds reasonable as an optional setting. It would be helpful for the check in skipMessage, the matterbridge.toml.sample, the changelog, and the docs/protocols/xmpp/settings.md to explicitly mention this is an unusual setting, linking to this PR for explanations about the usecase.

(changelog.md and settings.md need to be updated btw, otherwise that looks good, thanks!)

[g00g1]

Sorry about two commits, did not notice I am editing wrong file first. Could you please confirm if this is enough or should the description be more detailed?

[natalie0x42]

I'm in favor of implementing OMEMO support and enabling it as a default, with encryption capabilities noted in gateway/bridgemap for each bridge that supports some type of encryption. For example, see how UserTypingSupport gets indicated for the Discord bridge there. That way, a warning could be logged when encryptionless out-bridges are set to receive from encryptable in-bridges.

Enabling OMEMO for only some messages in the same channel seems like a wrong approach. Better to have multiple channels (bridges) on different gateways, even if each channel is using the same XMPP account, allowing some with OMEMO enabled and others without.

[poVoq]

Maybe an option to send a fallback message would be better instead of silently dropping it?

Like "This message was encrypted with OMEMO and could not be relayed"?