1536108 - OTR Interoperability issue with coyim: Cannot initiate private conversation with the "query message"

Status: RESOLVED FIXED

(Chat Core :: Security: OTR, defect)

Description

[Kai Engert [:KaiE:]]

Alice uses Thunderbird.
Bob uses a different chat client.

If Alice and Bob both use an OTR capable chat client, and they want to initiate an encrypted conversation, there are exactly four ways to do so:

(1)
Alice sends an unencrypted chat message to Bob.
Alice's OTR client adds special whitespace tag to the message, which indicates that Alice's chat client supports OTR.
Bob's client receives and displays the message.
In addition, Bob's client detects the special whitespace tag.
Bob's client automatically starts the handshake with Alice.
If successful, both clients displays the equivalent of "private conversation started".

(2)
The same as (1), but with switched roles.
(Bob starts by sending an encrypted chat message to Alice.)

(3)
Alice doesn't send an unencrypted message, instead, she uses a command that requests to start a private conversation with Bob.
To do so, Alice clicks Bob's entry in her buddy list, opens a conversation window, and then clicks the command "start encrypted conversation".
This starts the handshake protocol.
Alice's window should show the text "attempting to start private conversation", and if successful, will show the text "private conversation started".

(4)
The same as (3), but with switched roles.
(Bob clicks the menu command to start a private conversation.)

With the initial code from bug 1518172 that is being ported to Thunderbird, there's a bug with step 3.

Alice clicks the menu command to request a private conversation, but the handshake never succeeds, no progress is shown.

This initial failure causes the session between Alice and Bob to be permanently broken, and repairing the state on the Thunderbird side is impossible.

Regardless of the attempted actions:

• Alice or Bob send unencrypted messages
• Alice or Bob use the menu command to end and start the private conversation again
  the handshake never succeeds, and the private conversation is never started.

The only fix is to restart Thunderbird, and use one of the other mechanisms to start a private conversation. (Either 1, 2 or 4.)

See also bug 1536101.

This bug here is a reproducible scenario to create the broken state described in bug 1536101.

There might be additional scenarios that result in the same broken state.

Comment 1

[Kai Engert [:KaiE:]]

This bug happens if only the OTR v2 protocol version is enabled.

If support for OTR v3 is enabled, the bug doesn't show.

Comment 2

[Kai Engert [:KaiE:]]

After more testing (see also bug 1518172 comment 5 to 9), this appears to be an interoperability issue with the coyim messenger.

If Thunderbird has only v2 enabled, but the remote side is either pidgin-otr or the old Tor Messenger Beta, this bug cannot be reproduced.

I looked at the otr message console output in Thunderbird, and after TB sends the initial ?OTRv2? message, we do receive a response from the other side. However, then the handshake stops.

TODO: Investigate what's contained in the message from coyim, and why Thunderbird stops the handshake.

Comment 4

[arlolra]

I looked at the otr message console output in Thunderbird, and after TB sends the initial ?OTRv2? message, we do receive a response from the other side. However, then the handshake stops.

What's in the response? Turn on verbose logging.

Also, try clearing any old instance tags that may have been generated when you enabled v3 of the protocol.

TODO: Investigate what's contained in the message from coyim, and why Thunderbird stops the handshake.

It seems like it should work,
https://github.com/coyim/coyim/blob/master/config/account.go#L121

Comment 5

[Kai Engert [:KaiE:]]

I debugged this. We send out ?OTRv2?

coyim sends us ?OTR:AAMC...
which is interpreted as an version 3 message.

Then we ignore it, because our policy doesn't allow v3.

This seems to be a bug in the coyim version I'm using (will have to try if there's a newer version).

Comment 6

[Kai Engert [:KaiE:]]

I see some unexpected results.

I tried to modify some tests used by coyim, but couldn't reproduce the failure, with the self-test, and sending ?OTRv2? apparently it self-receives a message version 2 dhCommit message...

Then I disabled OTR in Thunderbird. I manually sent the string "?OTRv2?" to coyim. It responded with ?OTR:AAIC which is the expected v2 response!

However, when enabling OTR in Thunderbird, and looking at the messages shown in console.log, it claims TB sends ?OTRv2? but then receives ?OTR:AAMC (v3).

Apparently our OTR assumes that we're sending out ?OTRv2? (and shows that on console.log), but maybe we send out something to the wire that signals to coyim that we indeed support v3?

Comment 7

[Kai Engert [:KaiE:]]

lol. I found the reason.

The query message we're sending looks like this:

?OTRv2?
MY-USERNAME has requested an Off-the-Record (OTR) private conversation. However, you do not have a plugin to support that. See http://otr.cypherpunks.ca/ for more information.

In my situation, my test username is 3, which contains the letter 3.

Apparently the test for support protocol versions in coyim is a simple substring search for the number 3...

If I change Thunderbird to exclude my username, everything works fine...

I'll report a bug with coyim.

Comment 8

[Kai Engert [:KaiE:]]

Reported as https://github.com/coyim/coyim/issues/529

Comment 9

[Kai Engert [:KaiE:]]

Attachment: 1536108-v1.patch

workaround

Comment 10

[Magnus Melin [:mkmelin]]

Comment on attachment 9064517 [details] [diff] [review]
1536108-v1.patch

Review of attachment 9064517 [details] [diff] [review]:
-----------------------------------------------------------------

::: chat/modules/OTR.jsm
@@ +503,5 @@
>      }
>      // Use the default msg to format the version.
>      // We don't supprt v1 of the protocol so this should be fine.
>      let queryMsg = /^\?OTR.*?\?/.exec(query.readString())[0] + "\n";
> +    let noNumbersName = conv.account.normalizedName.replace(/[0-9]/g, ".");

Maybe # instead of . and please add a comment, maybe even link to the bug.

Comment 11

[Kai Engert [:KaiE:]]

Attachment: 1536108-ready.patch

Patch that is ready to land.

Applies on top of the patch from bug 1552004.

Comment 12

[Kai Engert [:KaiE:]]

Comment on attachment 9069601 [details] [diff] [review]
1536108-ready.patch

needed for OTR feature

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b12420c26104
Avoid sending secondary numbers in OTR query message. r=mkmelin

Comment 14

[Jorg K (CEST = GMT+2)]

TB 68 beta:
https://hg.mozilla.org/releases/comm-beta/rev/f203618cecfd4ee363358f493c86c2ea9f66ace1