MUC OMEMO: Error No record for device

stevenroose commented 5 years ago

It seems that somehow my encrypted messages are not showing the "[This message is OMEMO-encrypted.]" placeholder, but just empty. Is this a Converse.js bug?

Chobbes commented 5 years ago

This happens to me too, but not all the time. In fact the only context that I have seen this in is MUCs.

focus121 commented 5 years ago

Looks like a similar Problem that I experience in group chats with omemo: 2nd 1). First message send from conversejs 2). 2nd instantly received in conversejs (Isn't showing up in conversations) 3). Send from conversations // until here it was only me writing 4). Other person wrote from conversations In conversations all looks fine. Just in converse.js it looks for me there is some problem eventually with the key exchange. I enabled the debug log an see for example: libsignal-protocol.min.js:1 Uncaught (in promise) Error: No record for device group@muc.myserver.org/user2.294489646

Here is my complete debug log: log

jcbrand commented 5 years ago

Thanks, I'll try to look into this at the upcoming Berlin sprint.

orbitz commented 5 years ago

In debugging this I've found that the path this breaks on is:

https://github.com/conversejs/converse.js/blob/v4.2.0/src/converse-omemo.js#L256

It looks like prekey is false in this case and it blows up on:

https://github.com/conversejs/converse.js/blob/v4.2.0/src/converse-omemo.js#L275

licaon-kter commented 5 years ago

Seen this too, basically I test with a user, reopen Converse....blanks.

orbitz commented 5 years ago

Looking at how Conversations does it, I wonder if the decrypt function in Converse is supposed to iterate all possible keys and test them:

https://github.com/siacs/Conversations/blob/dac088428c57c698d78896addef3f5c04fac37e7/src/main/java/eu/siacs/conversations/crypto/axolotl/XmppAxolotlSession.java#L87

orbitz commented 5 years ago

Maybe not, after some experimentation it looks like there is only one key for this.

orbitz commented 5 years ago

Ok, so I've been poking around this a bunch and here is what I have so far: it looks like that one side of the connection (Conversations, in this case) is sending a message and not using a prekey because it believes there is an established session. In Converse, however, there is no session for this device in the store (I checked in Chrome debugger). Converse doesn't seem to handle this situation. I'm not sure what the correct thing to do is, though. In poking around the Conversations code, it seems like it has code to create a session if one is expected but not present (but I'm not sure).

In this case, at least, there doesn't seem to be any way to get out of this state because Converse doesn't send a message back telling Conversations something is wrong.

A bit more context:

Am testing from a test account a real account. The test account is logged in via Converse and the real account has two logins: one on Converse and one on Conversations.
Conversations can read all messages sent from test.
Sending messages from Conversations results in the error described in this ticket on both the real account on Converse and the test account on Converse.
Sending a message from my real account on Converse is successfully read by Conversations on the real account and test on Converse.
Looking in the omemo store, I can see that on the real account on Converse and test account on Converse, have sessions for the MUC for each other, but both are missing my Conversations account.

@jcbrand any suggestions on where to look next?

jcbrand commented 5 years ago

@orbitz

Thanks for all your research so far. I don't have time currently to look into this in detail, so I'm just going to throw some questions and ideas out there without checking them first.

Looking in the omemo store, I can see that on the real account on Converse and test account on Converse, have sessions for the MUC for each other, but both are missing my Conversations account.

So does this only happen in MUCs, or also one-on-one chats?

however, there is no session for this device in the store

I wonder whether sessions are restored from localStorage when you reload the page. Perhaps that's the problem here? In other words, when you reload the page previous sessions are gone and then this error happens. Could the solution be as simple as simply calling buildSession again for the device we received the message from?

orbitz commented 5 years ago

So does this only happen in MUCs, or also one-on-one chats?

1-on-1 chats appear to work fine for me, this is just in the MUC.

I wonder whether sessions are restored from localStorage when you reload the page.

I believe they are, however a wrinkle here is that I am using an Incognito window for the test account so all stored session are lost. But I don't think that matters too much for this scenario since I am experiencing the same behaviour on my non-incognito login.

Maybe a broader question is: does Converse support healing? I see code in Conversations for this but haven't checked Converse yet. I assume this is what healing is meant to solve, however the XEP does not have anything about healing in it from my quick skim.

orbitz commented 5 years ago

An additional thing, which I don't know if it matters because the XEP doesn't cover MUCs and I cannot find documentation on how MUCs are supposed to work:

When Converse sends a message in a MUC, it builds a session using the JID.DEVICEID. Receiving, however, the session it looks for is: MUC_ID/USER.DEVICEID (which is what the from is in the stanza. I don't know if Converse is supposed to transform that into JID.DEVICEID or something, or whether that notation is just custom and not specified. But that means there are two sessions, right? The sending session on JID.DEVICDID and the receiving session MUC_ID/USER.DEVICEID. Is this how things are supposed to work?

jcbrand commented 5 years ago

Maybe a broader question is: does Converse support healing?

No, I don't think so, and that seems to be the issue here...

I don't know if Converse is supposed to transform that into JID.DEVICEID or something, or whether that notation is just custom and not specified.

Not sure, but I think the former

orbitz commented 5 years ago

Is there some document that describes how healing is supposed to work? Or how OMEMO MUC is supposed to work? The XEP seem insufficient to actually implement it...

jcbrand commented 5 years ago

Not that I'm aware of. Unfortunately a lot of this information is not captured formally and exists only in implementations :(

orbitz commented 5 years ago

Great news!

I've got this working! I need to make the change more robust and handle MAM, but the basic thing is working. It also fixes a few other issues around message carbons (before those would show up as an error).

orbitz commented 5 years ago

Just to let anyone following this know, I am still working on it.

MamasLT commented 5 years ago

Hello! Is anyone still working on this issue? This problem seems to be the only one that doesn't allow Converse to be established as the ONLY desktop client that fully supports OMEMO for all platforms... orbitz, how are you doing? Thanks.

orbitz commented 5 years ago

@MamasLT I'm still chugging at it but at a reduced speed. Given the interest it sounds like I should focus on it a bit more!

If anyone is interested in contributing, we can get together in a chat and I can provide insight as to my status and what I think needs to be done to resolve the existing bugs that I am aware of (there are a few issues I see that I think what I want to do resolves but I don't have proof yet).

jcbrand commented 5 years ago

@orbitz: If you want we can have a video call to discuss what you're doing to fix this.

focus121 commented 5 years ago

Is there any progress on that issue?

licaon-kter commented 4 years ago

Seeing this too now. on HEAD Conversations user message appear in Converse as Unencryptable OMEMO message

Log says:

15:33:40.100Z DEBUG: _dataRecv called log.js:70:19
15:33:40.100Z DEBUG: <message xmlns="jabber:client" xml:lang="en" to="converseuser@mydomain.tld/converse.js-19647021" from="asavora@conference.mydomain.tld/convuser" type="groupchat"><active xmlns="http://jabber.org/protocol/chatstates"/><no-store xmlns="urn:xmpp:hints"/><no-storage xmlns="urn:xmpp:hints"/></message> log.js:70:19
15:33:40.600Z DEBUG: _dataRecv called log.js:70:19
15:33:40.600Z DEBUG: <r xmlns="urn:xmpp:sm:3"/> log.js:70:19
15:33:40.600Z DEBUG: <a xmlns="urn:xmpp:sm:3" h="193"/> log.js:70:19
15:33:40.600Z DEBUG: _dataRecv called log.js:70:19
15:33:40.600Z DEBUG: <message xmlns="jabber:client" xml:lang="en" to="converseuser@mydomain.tld/converse.js-19647021" from="asavora@conference.mydomain.tld/convuser" type="groupchat" id="afba4b53-3484-4ba8-b833-ac0897fdad44"><archived by="asavora@conference.mydomain.tld" id="1579188786883039" xmlns="urn:xmpp:mam:tmp"/><stanza-id by="asavora@conference.mydomain.tld" id="1579188786883039" xmlns="urn:xmpp:sid:0"/><encrypted xmlns="eu.siacs.conversations.axolotl"><header sid="1558123825"><key prekey="true" rid="987"></key><key rid="13018"></key><key rid="2069354861">M</key><key rid="855469932"></key><key rid="135588949"></key><iv></iv></header><payload>xdK/qg==</payload></encrypted><markable xmlns="urn:xmpp:chat-markers:0"/><origin-id xmlns="urn:xmpp:sid:0" id="afba4b53-3484-4ba8-b833-ac0897fdad44"/><store xmlns="urn:xmpp:hints"/><encryption xmlns="urn:xmpp:eme:0" name="OMEMO" namespace="eu.siacs.conversations.axolotl"/><body>I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo</body></message> log.js:70:19
ERROR: Error No record for device asavora@conference.mydomain.tld/convuser.1558123825 log.js:64:19
Error: No record for device asavora@conference.mydomain.tld/convuser.1558123825 libsignal-protocol.js:1972:406
15:33:40.600Z DEBUG: _dataRecv called log.js:70:19
15:33:40.600Z DEBUG: <r xmlns="urn:xmpp:sm:3"/> log.js:70:19
15:33:40.600Z DEBUG: <a xmlns="urn:xmpp:sm:3" h="194"/> log.js:70:19

onefang commented 4 years ago

I am seeing this problem as well, and not just with Conversations at the other end. Devuan Linux ASCII trying Gajim and Psi-Plus, as well as Conversations on Android 8. Anything sent to Converse.js in an OMEMO encrypted MUC shows as an empty message, anything sent from Converse.js shows up locally, shows in the other client's but is immediately followed by "This is an OMEMO encrypted message which your client doesn’t seem to support. Find more information on https://conversations.im/omemo" on the Converse.js client.

One to one OMEMO encrypted chats work fine.

An extra clue I didn't see above, on Conversations the Converse.js user is now showing "webuser is typing..", though they did nothing after sending the message.

This is a fresh install of Converse.js Version 6.0.0 from your release tarball, with libsignal-protocol-javascript v1.3.0 from their release tarball.

stevenroose commented 4 years ago

Just a heads-up that we're still affected by this issue in v6.0.0.

zuglufttier commented 4 years ago

Still the same on v6.0.1, it's exactly like @onefang described it.

This would be really helpful, apart from that converse.js is a really nice and usable client!

licaon-kter commented 4 years ago

@zuglufttier Is this about MUC OMEMO (which is not yet available) or 1:1?

zuglufttier commented 4 years ago

MUC OMEMO, 1:1 seems to be fine.

jcbrand commented 4 years ago

@orbitz is the work you did on this available somewhere, so that I can take a look at it?

conversejs / converse.js

MUC OMEMO: Error No record for device #1481