Confusing and *insecure* behaviour when 2nd device tries to start session, when contact has not closed old session

[infinity0]

I think my contact did not close a previous session where I spoke to them on a different device. I am using pidgin 4.0.0, they are using chatsecure 14.0.3

TL;DR: I was unable to start an OTR session with them until they manually shut down theirs. I could not read most messages they sent me, but could read some. Their messages that I could read, showed up without a lock on their side; their messages that I couldn't read, showed up with a lock.

All of my unencrypted messages showed as encrypted on their side.

ChatSecure needs to support multiple keys per contact, that can be validated separately. New keys should be warned about, the first time they are seen. My contact didn't see any of this for my 2nd device.

Attempting to start a private conversation with them@x...
them/chatsecure: Resend?
Attempting to start a private conversation with them@x/x...
Error setting up private conversation: Malformed message received
me/other-device: huh
me/other-device: refresh on your side?
The encrypted message received from them@x is unreadable, as you are not currently communicating privately.
Attempting to start a private conversation with them@x/x...
Error setting up private conversation: Malformed message received
them/chatsecure: On my phone now
me/other-device: on chatsecure?
The encrypted message received from them@x is unreadable, as you are not currently communicating privately.
The encrypted message received from them@x is unreadable, as you are not currently communicating privately.
me/other-device: lol
me/other-device: i think it's because i am on my [second device]
me/other-device: i guess the new version of chatsecure doesn't support 2 keys
The encrypted message received from them@x is unreadable, as you are not currently communicating privately.
me/other-device: i can't read what you're writing to me
me/other-device: can you "stop encrypting" and try again?
The encrypted message received from them@x is unreadable, as you are not currently communicating privately.
them/chatsecure: Hmm
Private conversation with them@x/x started.  Your client is logging this conversation.
me/other-device: there we go
them/chatsecure: You should a said that you couldn't understand me earlier :p
me/other-device: oh right yeah sorry ¬.¬
me/other-device: sigh, usable encryption
[..]
me/other-device: did you see any error messages on your end when i tried to talk to you?
them/chatsecure: Nope
me/other-device: the unencrypted messages i sent to you, did they show up differently?
them/chatsecure: I wasn't aware of you sending unencrypted messages
me/other-device: oh man. everything i sent between "huh" and "can you stop encrypting" was not encrypted
them/chatsecure: all those msgs have locks on them for me :p
them/chatsecure: Some of mine randomly didn't
me/other-device: yes, "on my phone now" and "hmm" came through unencrypted
me/other-device: i guess this was because you had an old encrypted session still active?
them/chatsecure: I mean I usually just leave my chats open in clients like this
me/other-device: right yeah
me/other-device: probably old session
[..]
them/chatsecure: The messages you could read showed as unencrypted from my end
them/chatsecure: All the others were marked as encrypted
me/other-device: of your messages you mean?
them/chatsecure: Yes

[n8fr8]

Thanks. We are actively working on this now. Somehow sessions we being created without the jabber resource, leading to the keying issues you noticed. In addition, we've made sure to tag unencrypted messages with an appropriate label/indicator.

[n8fr8]

If we could interleave multiple encrypted sessions into one conversation view (by maintaining unique OTR states for each remote jabberid), is that something you think we should do?

[devrandom]

Per-remote presence OTR state was already implemented, 2+ years ago. Was there a regression?

[infinity0]

@devrandom i think that was in libotr, I get the feeling this issue was based on the interaction between that and chatsecure.

@n8fr8 That could work, but it brings up some UI issues, especially if the sessions have keys with different validity status. Perhaps you could have a resource selector that grays out / hides the other messages from other sessions?

What actually happened in this case was, my original device was still online and automatically refreshed the old session. Their chatsecure then apparently ignored my other device's requests to start a conversation. (This could be libotr though; I'm not sure. pidgin-otr has a selector to choose between the "most recent" or "most secure", but I'm not sure if automatically-refreshed sessions count as "most recent".)

An extra reasonable behaviour would be to automatically close old sessions, if a new session is started and a manual message is received on it. Perhaps this could be tested at first, via a default-on setting "force 1 device per conversation".

[devrandom]

To clarify, I implemented per-remote OTR state in chatsecure about two years ago. The UI/UX issues you mention are a concern. The question is whether there was a regression in the chatsecure OTR functionality.

On September 24, 2014 1:31:23 PM PDT, Ximin Luo [email protected] wrote:

@devrandom i think that was in libotr, I get the feeling this issue was based on the interaction between that and chatsecure.

@n8fr8 That could work, but it brings up some UI issues, especially if the sessions have keys with different validity status. Perhaps you could have a resource selector that grays out / hides the other messages from other sessions?

What actually happened in this case was, my original device was still online and automatically refreshed the old session. Their chatsecure then apparently ignored my other device's requests to start a conversation. (This could be libotr though; I'm not sure. pidgin-otr has a selector to choose between the "most recent" or "most secure", but I'm not sure if automatically-refreshed sessions count as "most recent".)

An extra reasonable behaviour would be to automatically close old sessions, if a new session is started and a manual message is received on it. Perhaps this could be tested at first, via a default-on setting "force 1 device per conversation".

---

Reply to this email directly or view it on GitHub: https://github.com/guardianproject/ChatSecureAndroid/issues/531#issuecomment-56733779