Closed Bug 1536108 Opened 2 years ago Closed 1 year ago

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

Categories

(Chat Core :: Security: OTR, defect)

defect
Not set
normal

Tracking

(thunderbird68 fixed, thunderbird69 fixed)

RESOLVED FIXED
Instantbird 69
Tracking Status
thunderbird68 --- fixed
thunderbird69 --- fixed

People

(Reporter: KaiE, Assigned: KaiE)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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.

Blocks: 954310

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

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

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.

Summary: OTR: TB cannot initiate a private conversation without sending an unencrypted message first → OTR Interoperability issue with coyim: Cannot initiate private conversation with the "query message"
Type: enhancement → defect
See Also: 1536101
Duplicate of this bug: 1536101

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

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).

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?

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.

Attached patch 1536108-v1.patchSplinter Review

workaround

Assignee: nobody → kaie
Attachment #9064517 - Flags: review?(mkmelin+mozilla)
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.
Attachment #9064517 - Flags: review?(mkmelin+mozilla) → review+

Patch that is ready to land.

Applies on top of the patch from bug 1552004.

Keywords: checkin-needed
Keywords: checkin-needed
Keywords: checkin-needed
Comment on attachment 9069601 [details] [diff] [review]
1536108-ready.patch

needed for OTR feature
Attachment #9069601 - Flags: approval-comm-beta?
Attachment #9069601 - Flags: approval-comm-beta? → approval-comm-beta+

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/b12420c26104
Avoid sending secondary numbers in OTR query message. r=mkmelin

Status: NEW → RESOLVED
Closed: 1 year ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Instantbird 69
Component: General → Security: OTR
You need to log in before you can comment on or make changes to this bug.