OMEMO/chat issues in latest version?

[afriedmanGlacier]

In the latest download, I am not able to get users to talk OMEMO. In fact, no messages of any type are getting through. We are using eJabber and we rebooted the server just in case something screwy was happening there, but that didn't fix the issue. Other than rebooting, we have not touched the server, just updated the app. I will look more at server log messages tomorrow. Has anyone else seen this in the latest version?

[chrisballinger]

Is your server working with other clients?

[afriedmanGlacier]

I am having the same problem on two iPhone 7 with a fresh install of ChatSecure directly from the App store. I also tested on a different (newer) eJabber server version. I haven't tried with other clients yet, I am waiting for a co-worker who has been using a varient of Conversations on Android to make sure he can still talk OMEMO over our server. I'll update as soon as we are able to test more. They are able to login and see each other as online, just can't send messages.

[afriedmanGlacier]

Actually, after sending several messages back and forth and seeing nothing, changing settings to Plain Text and still seeing nothing, changing back to Best Available and still seeing nothing, I sent a knock and all of a sudden OMEMO started working and I can send messages. I'm so confused. Am I missing something? Is Knock required as a first step?

Tried this on two different eJabber server versions with the same basic results. After a Knock and a few attempts at sending message, OMEMO started working.

[chrisballinger]

That's very strange, the Knock button should have no effect on OMEMO working or not.

[afriedmanGlacier]

Tried more things and its very sporadic and bizarre as to whether OMEMO starts working or not. Maybe it has nothing to do with Knock. As another test, I deleted my accounts and started fresh connecting to the Dukgo server instead of our server, with ChatSecure from the App store. I am having the same problems there. Its having problems going OMEMO, but sometimes when I play with it and change settings (to plaintext instead of Best Available and back again after a few messages) it will eventually get there. Is nobody else seeing this weird behavior? Sometimes OMEMO keys don't show up in the Profile page, sometimes they do.

My coworker sent between iPhone and Android (a variant of Conversations) and when sending from iOS to Android, he was seeing weird messages such as Can't fetch OMEMO key and Unknown OTR Fingerprint.

[chrisballinger]

The initial key fetching can be a little wonky because it first needs to fetch a devicelist and then establish a session with each identity. You wont see OMEMO keys until they bundle is fetched, but you will see "Send OMEMO message" if there is a devicelist.

[afriedmanGlacier]

It says Send OMEMO message, it just doesn't work when I send it. On the Dukgo server, sometimes only one phone says Send OMEMO Message and the other says Send OTR Message. Still testing and trying to figure things out.

[chrisballinger]

Perhaps there is an issue parsing the bundle. In rare cases I've seen invalid bundles published (where a key cannot be parsed) but that is silently discarded.

[afriedmanGlacier]

The more we test this, the more confused I get. We can’t go OMEMO with fresh devices that have never talked to each other before, using the App store version of ChatSecure (to rule out our modifications), creating new accounts on Dukgo. I am trying to get a baseline of what series of events work to get it to go OMEMO, but it seems to act differently every time.

We weren't having this problem until recently. I'm not sure when it started, but we hadn't upgraded since late October soon after OMEMO came out on ChatSecure until version 4.0.4. And then we updated again with 4.0.5. I can't remember if this behavior started as soon as we updated to 4.0.4 or more recently with 4.0.5 (we were working on other things in the meantime so we may not have seen it)

[chrisballinger]

Not that much has changed in v4.0.3->v4.0.5 that would affect OMEMO working or not working. For example: https://github.com/chatsecure/chatsecure-ios/compare/v4.0.3...v4.0.5

Dukgo's server is really really bad now so I wouldn't base anything on Dukgo testing. :-\

By the way... we don't really have the resources to help debug proprietary modifications without a support contract. Although it's good you found this is reproducible upstream, just a reminder, please keep issues on this tracker about the core app.

[afriedmanGlacier]

@chrisballinger though we do have a proprietary version of ChatSecure, as soon as we ran into this, we backed out to the App store version of ChatSecure to make sure it wasn't our code. I guess I shouldn't keep referencing ChatSecure, but I'm just clarifying that we are testing the core app rather than anything with our code. All the tests we've run the last few days are on ChatSecure from the App store. We also built from github v4.0.4 just to see if it helped (couldn't go further back due to upgrade to iOS10.3, xCode 8.3, Swift 3, etc). That was a bit different from the current release, but also has issues (it said it could go OMEMO but the app kept crashing). We only tested briefly with this and then stopped.

The only reason we are using Dukgo is because that's the default when we want to create a new account through ChatSecure. We also tried it on a freshly installed eJabber (though not the latest version, 16.09) with freshly installed ChatSecure, with the same issues. I guess we could get the latest eJabber and try just to make sure. Do you have suggestions for publicly available servers to try other than Dukgo?

[ghost]

@afriedmanGlacier: https://gultsch.de/compliance_ranked.html

[afriedmanGlacier]

@participante0 thanks!

[afriedmanGlacier]

We created two accounts today with conversations.im to test also (thank you @weiss).

We tested between to iOS/ChatSecure devices and still had the same issues. Most of the time it wouldn't exchange OMEMO keys at all (or one side would receive keys and the other wouldn't). We couldn't get them to talk OMEMO. We also tried a different eJabber server of ours. One test session out of several tries it kind of randomly went OMEMO after about 10 minutes of trying different things.

We then tested between ChatSecure and Android/Conversations, and we were able to get them to talk OMEMO after about a minute. We did this on both conversations.im server and one of our eJabber servers.

Finally, we tested Android/Conversations to Android/Conversations on our server and on conversations.im and it had no trouble going OMEMO quickly.

Although we have not seen the exact same behavior every time, which makes it hard to give you an exact set of steps to reproduce the issue, we have seen enough that I think we can say there is a significant issue.

I haven't looked into the OMEMO code on ChatSecure yet, though I think I'm about to dive in to try to understand it. When exactly are keys supposed to be exchanged? Is it when a Buddy accepts a friend request? Or on first message between the two? Or on some other event?

[chrisballinger]

Key exchange is supposed to happen "automatically" after buddy approval by PEP, but PEP is shitty and doesn't work reliably, so we also manually query it whenever you enter a conversation. I am open to a more reliable solution.

[afriedmanGlacier]

FYI, at the suggestion of @weiss, I just tested on talker.to which is a Prosody server and OMEMO worked immediately. Sooooooo, I had issues with ChatSecure on eJabber and on conversations.im (and Dukgo), but if Prosody works, now I know why you weren't seeing the issue.

Anyone have an ideas what might be different on Prosody that allows it to work but other servers not to work with ChatSecure and OMEMO? Again, Conversations doesn't seem to have any problem on eJabber or conversations.im, and OMEMO even works between Conversations and ChatSecure on those servers.

[chrisballinger]

The issue is the PEP implementation. All of them seem a bit buggy, so we need to do a better job working around the edge cases. Btw Dukgo runs Prosody to my knowledge, but has performance problems caused by lack of maintenance.

@iNPUTmice I remember that Conversations has hacks to work around "broken" PEP implementations, but I'm not really sure what that does, and if it would help in this case.

[weiss]

The issue is the PEP implementation. All of them seem a bit buggy

PEP was buggy in old ejabberd releases, but should be fine in the versions @afriedmanGlacier tested against. So if there's issues ChatSecure is stumbling over, I'd be highly interested in the details.

[afriedmanGlacier]

Still testing. Right now, sometimes it fails for us in fetching the bundle for a device id.

But other times it fails in getting a chain_key (I'm not sure what that is) in session_cipher.c, which causes SignalSessionCipher.encryptData to return nil and OTROMEMOSignalCoordinator.encryptAndSendMessage to return nil.

When this happens, the message is never sent from the client. However, it often works if we log out and log back in with one of the devices and then resend. I'm wondering if this is related to an invalid bundle, as in https://github.com/ChatSecure/ChatSecure-iOS/issues/725? Once the devices are talking with OMEMO, they seem to be fine from that point on.

[chrisballinger]

I caught this while debugging today and starting down the rabbit hole.

I've noticed that for some reason invalid bundles seem to be created occasionally. I'm not really sure what to do about this other than adding some code to validate your own bundle before publishing it, scrapping it if it's invalid, and republishing a new one.

Kind of a stretch but perhaps it's simply related to base64 enc/dec. libsignal-protocol-c says "invalid signature on device key!" and when inspecting the bundle xml it appears the signedPreKeySignature has == that might not be handled properly?

<bundle xmlns="eu.siacs.conversations.axolotl">
          <signedPreKeyPublic signedPreKeyId="1934732210">Bc9TOYv2lM63DQrSeLZUSe1M6JduulYIAnfLF0DZJI5V</signedPreKeyPublic>
          <signedPreKeySignature>eeW/q6ZVdF+uIfEMT/VnEEHmqc9zp9lfS7OST8q+C6gjSF5Vd/5tTPfvwPQsBgEFSj+Vy2+bu4Hmw3mJtSAniw==</signedPreKeySignature>
          <identityKey>Bd/9tSfIPPZiHYXfxYFfvuDNLZiu3F+/ZG7C8iOJoIxE</identityKey>
          <prekeys>
            <preKeyPublic preKeyId="17">BVgol2k9D89w1KX+3La4t45/pZFq+T2jJLmihj+MU+cY</preKeyPublic>

        result = curve_verify_signature(identity_key,
                signal_buffer_data(serialized_signed_pre_key),
                signal_buffer_len(serialized_signed_pre_key),
                signal_buffer_data(signature),
                signal_buffer_len(signature));

        signal_buffer_free(serialized_signed_pre_key);

        if(result == 0) {
            signal_log(builder->global_context, SG_LOG_WARNING, "invalid signature on device key!");
            result = SG_ERR_INVALID_KEY;
        }

[chrisballinger]

This is probably fixed in bfcdb74

[chrisballinger]

Great! I was finally able to reproduce the Bad MAC error when receiving malformed PreKeyMessages. Not sure how to fix it yet.

Tracking in #743