otr problem

[marix11]

If one side exits xabber ( exit xabber from menu, reboot phone, etc) without stop encryption, you cant get otr chat no more. To reproduce this problem both sides need to use newer xabber versions ( from 0.10.. ). If one side using 0.90 there no problem

Used versions 10.45, 10.62, beta 1.02

[marix11]

Same issue on 1.05

[marix11]

Easy to reproduce it with Conversations. Start otr chat. Then on conversations you do stop encryption. No more possible actions on xabber possible. Stop restart encryption doesnt help

[grigoryfedorov]

Reproduced it with Conversations. got "Multiple instances detected on SessionID" message twice, when trying to start encryption again.
Will think, how to fix. Also wish @aelmahmoudy could help.

[aelmahmoudy]

Conversations is also using the new otr4j implementation

[aelmahmoudy]

I don't think the "Multiple instances detected on SessionID" is related, this probably happened because one of the chat parties used 2 different XMPP clients (either simultaneously or one after the other)

[aelmahmoudy]

When I closed Xabber before ending an OTR session, I get this error on logcat:

E/AndroidRuntime( 8931): FATAL EXCEPTION: main
E/AndroidRuntime( 8931): Process: com.xabber.androiddev, PID: 8931
E/AndroidRuntime( 8931): java.lang.RuntimeException: Unable to stop service com.xabber.android.service.XabberService@41d4f1b8: java.lang.NullPointerException
E/AndroidRuntime( 8931):        at android.app.ActivityThread.handleStopService(ActivityThread.java:2735)
E/AndroidRuntime( 8931):        at android.app.ActivityThread.access$2200(ActivityThread.java:135)
E/AndroidRuntime( 8931):        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1298)
E/AndroidRuntime( 8931):        at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime( 8931):        at android.os.Looper.loop(Looper.java:136)
E/AndroidRuntime( 8931):        at android.app.ActivityThread.main(ActivityThread.java:5001)
E/AndroidRuntime( 8931):        at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 8931):        at java.lang.reflect.Method.invoke(Method.java:515)
E/AndroidRuntime( 8931):        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
E/AndroidRuntime( 8931):        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
E/AndroidRuntime( 8931):        at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime( 8931): Caused by: java.lang.NullPointerException
E/AndroidRuntime( 8931):        at com.xabber.android.data.extension.otr.OTRManager.injectMessage(OTRManager.java:235)
E/AndroidRuntime( 8931):        at com.xabber.android.data.extension.otr.OTRManager.injectMessage(OTRManager.java:254)
E/AndroidRuntime( 8931):        at net.java.otr4j.session.Session.endSession(Session.java:996)
E/AndroidRuntime( 8931):        at com.xabber.android.data.extension.otr.OTRManager.endSession(OTRManager.java:218)
E/AndroidRuntime( 8931):        at com.xabber.android.data.extension.otr.OTRManager.endAllSessions(OTRManager.java:696)
E/AndroidRuntime( 8931):        at com.xabber.android.data.extension.otr.OTRManager.onClose(OTRManager.java:704)
E/AndroidRuntime( 8931):        at com.xabber.android.data.Application.onClose(Application.java:156)
E/AndroidRuntime( 8931):        at com.xabber.android.data.Application.onServiceDestroy(Application.java:294)
E/AndroidRuntime( 8931):        at com.xabber.android.service.XabberService.onDestroy(XabberService.java:69)
E/AndroidRuntime( 8931):        at android.app.ActivityThread.handleStopService(ActivityThread.java:2718)
E/AndroidRuntime( 8931):        ... 10 more

[aelmahmoudy]

Then when I restarted Xabber, and the other party tried to restart OTR session, I got this in logcat:

I/com.xabber.android.data.extension.otr.OTRManager@41bf9948(10068): Message from another instance received on SessionID me@myserver.com/android2uV73Hcp_xmpp_otherparty@otherserver.com. Restarting OTR session for this user. 

[eighthave]

Did Xabber have support for OTR InstanceTags before updating otr4j? I think the new Instance Tags feature might have something to do with this, since Instance Tags mean that certain OTR sessions will be ignored (i.e. OTR sessions on the same XMPP account but from a different client).

[eighthave]

maybe the original authors of the Instance Tag code can shed some light on this @mdzhigarov @cobratbq

[eighthave]

looks like Conversations is using the jitsi otr4j 0.22 jar, which is substantially behind otr4j/otr4j, so it seems it is an old bug

[aelmahmoudy]

According to 29f9ec3: InstanceTags wasn't really used, it was just in the 'askForSecret' override method declaration, but not used in the method body.

[cobratbq]

I can shed some light on the recent fix. I'm not sure if that is the cause of this.
Basically, instance tags are used whenever OTRv3 is in use. In the original otr4j, instance tags were accidentally limited to a subset of the original valid range in the OTRv3 specification, namely [0x00000100, 0x11111111].
Now it turns out that the spec does not give an upper limit, and 0x11111111 is an accidental too low upper limit. It was meant to be 0xffffffff. (I also checked this with @mdzhigarov.) The recent commit in otr4j/otr4j fixes that, however, that would mean that some of the generated instance tags would be considered invalid in older versions of otr4j. And I would not be surprised if that would cause otr4j session to be considered invalid. (I still have to check, I'm not sure yet.)

So, any client that uses an older version of otr4j (either jitsi/otr4j or any other) would be a little bit too restrictive in which tags it accepts. However, any tag it generates will certainly be accepted by current version of otr4j/otr4j.

I hope this helps your understanding. I think it might be related.

[mdzhigarov]

Hi all,

+1 to what cobratbq said.

Instance tags are used only in OTRv3. There was a bug with the upper bound
being 0x11111111 that was fixed recently because this is not according to
the specification.
I also confirm that with the latest fix the HIGHEST_TAG variable is not
used for anything throughout the otr4j code. It was, however, incorrectly
used for validation and generation in the older version of the library so
it is possible that this causes problems in the communication between old
and a new client

Best regards,
Marin

On Wed, Jun 3, 2015 at 9:59 PM, cobratbq notifications@github.com wrote:

I can shed some light on the recent fix. I'm not sure if that is the cause
of this.
Basically, instance tags are used whenever OTRv3 is in use. In the
original otr4j, instance tags were accidentally limited to a subset of the
original valid range in the OTRv3 specification, namely [0x00000100,
0x11111111].
Now it turns out that the spec does not give an upper limit, and
0x11111111 is an accidental too low upper limit. It was meant to be
0xffffffff. (I also checked this with @mdzhigarov
https://github.com/mdzhigarov.) The recent commit in otr4j/otr4j fixes
that, however, that would mean that some of the generated instance tags
would be considered invalid in older versions of otr4j. And I would not be
surprised if that would cause otr4j session to be considered invalid. (I
still have to check, I'm not sure yet.)

So, any client that uses an older version of otr4j (either jitsi/otr4j or
any other) would be a little bit too restrictive in which tags it accepts.
However, any tag it generates will certainly be accepted by current version
of otr4j/otr4j.

I hope this helps your understanding. I think it might be related.

—
Reply to this email directly or view it on GitHub
#413 (comment)
.

[aelmahmoudy]

@mdzhigarov @cobratbq Actually the problem being reported here is even between two same clients (Xabber in this case) using latest otr4j/otr4j implementation.

Also, as far as I understand, that InstanceTag should cause the OTR session not to start, yet the issue here happens when/after an OTR session is being ended.

[cobratbq]

In that case, I'm not sure what would cause the problem. I'll need to check this for myself and get back to you.

[cobratbq]

I've just tried to reproduce the issue with otr4j/otr4j master. I have not been able to. The only thing I can think of - this happened once for me at least - is that a second otr session gets to be established. Then you need to have an ability to select the second session, as the first one - the old session - is likely not encrypted anymore. Or if it is, then it cannot be decrypted, because the old session's secret got lost with the phone reboot. If you then select the second session, it will be encrypted and all works as expected.

I also see the correct behaviour in:

• select established otr session: message arrives encrypted.
• select plaintext otr session: message arrives in plain text with warning.

I have tried this using Jitsi as the chat client and XMPP transport and self-built otr4j/otr4j master, so I can't tell you anything about the xabber client. Hope this information helps you in debugging.

[grigoryfedorov]

Thank you all
Seems, that I fixed the problem in ec27bb5
Version 1.0.19 contains this patch and will be available soon.
As @cobratbq said, I recreate session after it gone to "plain text" or "finished" state. It looks like work ok, but I'm not sure, so please test)

[marix11]

Thanks a lot. I will test. That dropbox link is empty. Where i could download latest build

[grigoryfedorov]

@marix11 it should not be empty.. anyway
https://www.dropbox.com/sh/gdhk6jyd8wk61vz/AAD_I6guIR2evuW4w9YW73a3a?dl=0

[marix11]

Thanks a lot. Now it works. Just small bug. After another side stop encryption. You cant stop. Stop encryption does nothing and if you write text is unenceypted even on options encryptuon required. Just before writing you need to do restart envryption and everything is perfect again

[marix11]

Now again same priblem as in first post. To reproducd it start encrypted chat. Then one side close connection and exit/restart xabber offline. Now other side didnt notice stoped encryption and again like in first post otr chat not possible. Restart encryption doesnt help. Need both sides stop encryption same time but how other side know that

[marix11]

Still same on 1.0.21. Only can chat if both sides do stop encryption and start new session. But its hard to know cause your messages are delivered and other side only see 'The encrypted message recieved is unreadable'

[eighthave]

This kind of thing is tricky to troubleshoot since there are many possible causes. I think the current state, where you get 'The encrypted message recieved is unreadable', could be caused by something different. If this is caused by other side still using the old OTR session, then the fix is to "refresh" the OTR session. We've had good luck in ChatSecure automatically triggering OTR refreshes when one side gets those messages.

[marix11]

Both stop encryption and restart doesnt help. Even if you do stop encryption other side doesnt notice it

[cobratbq]

Has anyone checked if this is related to having multiple active OTR sessions?

If a new OTR session (based on a different instance ID) is established, but that session is not selected, then you still don't have an encrypted OTR session since it isn't selected yet. Depending on how the UI handles the events of "OTR encrypted session established" and subsequently querying for status of selected OTR session (which is still unencrypted) a similar fenomenon may occur.

[marix11]

Maybe i wasn't clear enough, i made screenshots.

Otr session established. Then side 'aa' going offline and and restarting xabber. Side1'oo2' doesn't notice it. side 'aa' receiving unreadable messages and starting new otr session. Still unreadable. Side 'ooh' restarting encryption, then it receiving unreadable messages And impossible to chat until both sides stop encryption

[cobratbq]

Do you have an ability to select another OTR session? (Sorry, not intimately familiar with Xabber) This looks similar to some tests we did with another client.

If side aa goes offline, indeed it is not always noticed by side oo2. Then oo2 uses old encryption key (from first session) that side aa does not have anymore. Side aa should be able to set up a new OTR session, however that would likely be with a different Instance ID (because of restart), so on side oo2 a second OTR session is started, but oo2 is still using the first OTR session (with lost secret) - as this session still is not invalidated. Only after oo2 starts using the second session (either with or without finishing the first) will side aa be able to decrypt again.

Again, are you able to select another OTR session and if so have you selected the other (newer) OTR session?

[marix11]

If after restart aa starting new session like i did in screenshots then for oo2 impossible to chat. Stop or restart doesnt help. I dont understand what is another otr session but i opened many with another contacts and they are ok. Just with aa is not working

[grigoryfedorov]

@marix11 please check version 1.0.22

[marix11]

Thanks. A lot it works. Great work

[eighthave]

nice one :) do you think it could make sense to include some kind of "unavailable" callback in otr4j? It is likely that each otr4j app is going to need something like this, so we should make it part of the standard implementation.

[marix11]

I was testing some time. Some servers close connection offline but doesnt restart new one on both sides. So problem still exists with that server. Will try to test more to reproduce.
Also this causing new problems. If during conv one side losing connections temp, it restart fast and if yoy were sending messages that time you send enreadable again. From 1.0.22 i getting errors with old xabber clients 0.9f. Maybe depends on servers too need test more

[grigoryfedorov]

@eighthave not sure. I think it would be good for sender to know if his messages are unreadable for receiver.

[aelmahmoudy]

This fix results in the problem mentioned in #413 (comment), I think this issue needs to be re-opened.

[marix11]

Updated from 1.0.25 to 1.0.30 and sometimes getting those unreadable messages errors

[marix11]

Smth was changed in latest versions. Again much otr problems. You can stop/restart still unreadable messages errors
Update: i cant reproduce it now. Tried some days with no luck, but sometimes those unreadable messages arive until both sides stop encryption

[marix11]

After some weeks testing. Me getting much unreadable messages. Only between new xabber versions. When those messages arrive, You cant do anything. If you stop encryption you recieve 'unreadable', if you side stop they recieve 'unreadable'. The only way to fix that both sides need to restart xabber or both do stop encryption. But you can send 'unreadable' messages for weeks, you cant know, other side doesnt notice them cause no notification from ’unreadable'. I hope you understand what i mean. That happens after many times changing connection between mobile/wifi/other wifi, but i cant reproduce it

[marix11]

Sorry, but xabber now is unusable. The more people upgraded to v1.0.. No more Otr chat is possible.
And why this issue is closed since Otr is main feature

[marix11]

Some update of this problem. Between 1.39 seems all ok. Between 1.39 and 1.30 from play store otr problems