[jitsi-dev] Jitsi + OTR: some quirks, doing some investigation


#1

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

All should be fairly easy to fix. (Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Danny


#2

Thanks a lot for dealing with these important issues!

PGP.sig (489 Bytes)

···

On 1/23/15 9:34 PM, Danny van Heumen wrote:

* PGP Signed by an unknown key

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

All should be fairly easy to fix. (Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Danny

* Unknown Key
* 0x5ED42CC4

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hi all,

Quick follow-up. I haven't had as much time as I would've liked. I have
found out the following things. (in line ...)

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that
the 2nd session "listening in" (not in the malicious way) does not have
an OTR session established. So, as a consequence this session receives
encrypted messages as if they were normal messages.

This is likely not an issue in the OTR4J library, but rather in Jitsi
not including OTR4J, since it isn't enabled. I believe that if OTR4J was
"in the loop" it would have handled this message. Maybe by dropping a
system message saying what is happening. Need to look into that further.

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

This one's a bit tricky. We receive a text message which is encrypted.
Once decrypted, we need to discover whether it is intended as HTML or
plain text. I'm not sure how another OTR-capable chat client makes this
distinction, though looking at Pidgin's behaviour, I suspect they may
simply have assumed HTML. (Otherwise it wouldn't have been as simple to
inject styling in the message sent to Pidgin client.)

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

Same as above.

All should be fairly easy to fix.

I should've known better ... saying things like that :stuck_out_tongue:

(Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows
otherwise, plz let me know.

As an added bonus I found out that plain text messages aren't correctly
escaped in the notification popup, so at least that's fixed now :slight_smile:

Danny

···

On 23-01-15 21:34, Danny van Heumen wrote:

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hi all,

Quick follow-up. I haven't had as much time as I would've liked. I have
found out the following things. (in line ...)

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that
the 2nd session "listening in" (not in the malicious way) does not have
an OTR session established. So, as a consequence this session receives
encrypted messages as if they were normal messages.

This is likely not an issue in the OTR4J library, but rather in Jitsi
not including OTR4J, since it isn't enabled. I believe that if OTR4J was
"in the loop" it would have handled this message. Maybe by dropping a
system message saying what is happening. Need to look into that further.

There seems to be an issue here. You're talking about OtrTransformLayer:149, right? Where this code fragment is executed:

f (!policy.getEnableManual()
             && sessionStatus != ScSessionStatus.ENCRYPTED
             && sessionStatus != ScSessionStatus.FINISHED)
             return evt;

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

This one's a bit tricky. We receive a text message which is encrypted.
Once decrypted, we need to discover whether it is intended as HTML or
plain text. I'm not sure how another OTR-capable chat client makes this
distinction, though looking at Pidgin's behaviour, I suspect they may
simply have assumed HTML. (Otherwise it wouldn't have been as simple to
inject styling in the message sent to Pidgin client.)

Other clients, like Miranda, have the exact same problem when they communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I suppose the messages that Pidgin is sending don't have their contentType set correctly, right? In that case, one way to fix it would be to assume HTML if the remote client is Pidgin.

···

On 25 Jan 2015, at 23:14, Danny van Heumen wrote:

On 23-01-15 21:34, Danny van Heumen wrote:

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

Same as above.

All should be fairly easy to fix.

I should've known better ... saying things like that :stuck_out_tongue:

(Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows
otherwise, plz let me know.

As an added bonus I found out that plain text messages aren't correctly
escaped in the notification popup, so at least that's fixed now :slight_smile:

Danny

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hi,

Response in-line ...

Hi all,

Quick follow-up. I haven't had as much time as I would've liked. I have
found out the following things. (in line ...)

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that
the 2nd session "listening in" (not in the malicious way) does not have
an OTR session established. So, as a consequence this session receives
encrypted messages as if they were normal messages.

This is likely not an issue in the OTR4J library, but rather in Jitsi
not including OTR4J, since it isn't enabled. I believe that if OTR4J was
"in the loop" it would have handled this message. Maybe by dropping a
system message saying what is happening. Need to look into that further.

There seems to be an issue here. You're talking about
OtrTransformLayer:149, right? Where this code fragment is executed:

f (!policy.getEnableManual()
            && sessionStatus != ScSessionStatus.ENCRYPTED
            && sessionStatus != ScSessionStatus.FINISHED)
            return evt;

Hmm... that could be it. Although I am not sure how OTR4J would react to
the request. But, yes, (assuming context here) now OTR4J doesn't even get
called.

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

This one's a bit tricky. We receive a text message which is encrypted.
Once decrypted, we need to discover whether it is intended as HTML or
plain text. I'm not sure how another OTR-capable chat client makes this
distinction, though looking at Pidgin's behaviour, I suspect they may
simply have assumed HTML. (Otherwise it wouldn't have been as simple to
inject styling in the message sent to Pidgin client.)

Other clients, like Miranda, have the exact same problem when they
communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I
suppose the messages that Pidgin is sending don't have their contentType
set correctly, right? In that case, one way to fix it would be to assume
HTML if the remote client is Pidgin.

Well, this is where I was left. I checked the XMPP IM specs and it seems
that there should be a body including a HTML identifier to signal HTML
content. What I am unsure of is how much of this XML format is interpreted
by the XMPP library before we get to see it. If the only header available
is the one signaling plain text - because OTR encrypted content is plain
text - and we only get the content *inside* the <body> tag, then it could
be that there is no way to define HTML content (for the inner -
OTR-encrypted - message).

I haven't found the appropriate "extensions" (I think they're called) in
the in-memory message object. So either they forgot to include, or it isn't
possible to include, or the object I'm looking at is actually the outer
message "envelope".

Danny

···

On Mon, Jan 26, 2015 at 10:50 AM, George Politis <gp@jitsi.org> wrote:

On 25 Jan 2015, at 23:14, Danny van Heumen wrote:

On 23-01-15 21:34, Danny van Heumen wrote:

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

Same as above.

All should be fairly easy to fix.

I should've known better ... saying things like that :stuck_out_tongue:

(Assuming Pidgin is the one behaving

as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows
otherwise, plz let me know.

As an added bonus I found out that plain text messages aren't correctly
escaped in the notification popup, so at least that's fixed now :slight_smile:

Danny

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Okay, so it's time for an update on this topic ...

@George: In case of TL;DR, could you check my commit, just to be sure?
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
It's about removing the conditionals so any message reaches the otr4j
library, even if a secure session is not established yet. Basically what
you suggested before.
Also, can you explain why at SessionImpl:479 (call to
setSessionStatus(ENCRYPTED)) the called method resets auth (AuthContext)
to setIsSecure(false), while the passed parameter is
SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
contradictory.)

I've been playing around with the whole OTR UI and plugin to see what I
could discover apart from the stuff we already know. I have been playing
around for a few hours and this is a quick report of what I've been able
to discover.

1. The raw OTR-encrypted message I received as described below, is due
to XMPP Carbons being enabled. We receive the message sent from another
client (same account) and we subscribed to carbon copies, so we receive
a carbon of the raw message. This particular message flow is not hooked
into otr4j, so it gets shown as a plain old message. (@fippo: Thanks for
pointing out the carbons!)

  a) I'm thinking of whether or not we *can* hook that into otr4j. Maybe
we can process this as a "received" message. I have not done that yet,
though, because I'm not a 100% sure that there aren't any other
consequences. (It would be nice to see a notification of a message
encrypted for another session, and have the ability to drop the message
itself, since that has no value to us.)

2. I have seen a mismatching padlock icon, compared to the actual
session and the sessions in the "Secure chat" menu. The sessions listed
in "Secure chat" menu have always been accurate AFAICT. I have not been
able to reproduce it reliably though -- and I'm starting to doubt
whether session selection isn't the culprit.

3. About encryption-state mismatches ...

  a) I have NOT been able to get a session that was not actually
encrypted even though Jitsi says it IS encrypted. This in itself does
not prove that there isn't an issue, but it's not so easy to get into
that state by just clicking buttons (with or without thinking about it).

  b) I have been able to send unencrypted messages while an encrypted
session was set up. HOWEVER, Jitsi accurately showed an open padlock
when sending the message. The reason for this is that I had selected the
"root" XMPP session and sent the message via there. If you select this
session, Jitsi accurately shows an open padlock and messages are sent to
all session (I think). The chat client on the other side accurately
warns of an unencrypted message being received. If you then select one
specific XMPP session in the chat window, the padlock updates and indeed
messages are sent in encrypted form.

As far as I have been able to determine this is all expected behaviour.
The root session cannot be OTR-encrypted, since it sends to (multiple?)
sessions and you would need to encrypt differently for every session. So
you need to select one specific session to send encrypted messages. (OTR
also stores a new session instance for each XMPP session.)

4. Given the behaviour above, it would be good to somehow warn or
prevent users from selecting the "root" session if multiple sessions are
known/active. This should prevent mistakes from being made.

  a) We may need to change the UI so that the "active" session (last
message) is selected automatically and users would always need to select
a specific session to switch. (And maybe we should not allow selecting
this top-most session.)

... after some more hours of fiddling around and lots of confusing
moments ...

5. I have now determined that XMPP message carbons can interfere with
correctly establishing an encrypted OTR sessions at one of two sides. I
am not clear on the details yet (and I am starting to believe that this
is a bug in the implementation), but this issue seems to arise at the
side where 2 sessions are active and carbons are enabled. (I see the
occasional OTR debug log entry about messages meant for another session.)

  a) The result is an encrypted OTR session that IS established for the
non-problematic side (account with only a single XMPP session). The
sessions is established fully, and it can send encrypted messages. The
other side (2 active XMPP sessions) eventually decides to go with
plaintext and does not expose the encrypted session, even though it is
established. It is established because it can decrypt any received
encrypted messages, however ask the OTR Session-instance for its
SessionStatus and it will return PLAINTEXT. Send a message from that
side and it will send a plain text message (not encrypted). NOTE that
the padlock icon consistently shows an accurate state.

6. Further more, a small issue which may not actually be a problem. I
note this here for reference as it may only ever occur if you delay the
process by debugging (stepping through code): In the OTR plugin, if the
timeout-scheduler isn't cancelled in time, it will set a "timeout" state
which is then used and hides the true state of the OTR Session instance.

Reproduction recipe for 5.:
1. Start some other chat client. Log in the account with server support
message carbons, e.g. @jit.si. This is going to be the shared account.
2. Start Jitsi. Log in with same account as in 1. Make sure message
carbons are enabled.
    Using Jitsi, log in with another XMPP account.

-- So now 2 XMPP accounts are active, 1 shared by Jitsi and other client
- with message carbons, 1 solely for Jitsi.

3. Use client from 1. initiate OTR-encrypted session with 2. using
@jit.si account
4. Using client from 1. send message to other XMPP account.
5. Jitsi popup shows that it received a message. Click popup to view
message. Notice that OTR session is established.
6. In Jitsi, select the other session for this account (@jit.si) that is
available (which accidentally is the Jitsi client's XMPP session)
7. Initiate OTR-encrypted session between the 2 accounts, both in Jitsi.

-- Notice that session correctly establishes at initiating side, which
is the 1-session XMPP account solely in use by Jitsi.

9. Send a message over this newly instantiated OTR session.
10. Popup shows for newly received message, click and it opens a second
tab showing the message received on the shared @jit.si account.

-- Notice now that *that* account's OTR-encrypted session was not
recognized. The padlock is open. Sending messages now will send them as
plain text. However, it did just receive the encrypted message and
decrypted it successfully.

When enabling debug logging in OTR one notices that the messages are
indeed encrypted from the side showing the OTR-encrypted session, and
plain text for the other side.

Disabling message carbons fixes the problem described above. (At least,
it does for me.)

Sorry for making this such a long post. To conclude: I have been trying
to get a feel for the state of OTR support in Jitsi. We already knew of
some issues with state mangement. I believe these findings may have
fine-tuned this issue a bit. For now I do not see any big problems,
especially since the UI always showed an accurate state. Confusion is
mostly caused by XMPP's message carbons together with multiple active
sessions, which also makes the issues local to the XMPP protocol. The
confusion is focused on using the UI, as OTR seems to do the right thing
in the background. EXCEPT for this one issue described above where the
OTR-encrypted session should have been established at both sides. But
even then, Jitsi showed the correct state as the results were accordingly.

So, if you rely on OTR, make sure that your XMPP accounts have message
carbons disabled. Then you should have a pretty smooth ride. (As far as
I can tell from these tests.)

Danny

···

On 26-01-15 10:50, George Politis wrote:

On 25 Jan 2015, at 23:14, Danny van Heumen wrote:

Hi all,

Quick follow-up. I haven't had as much time as I would've liked. I have
found out the following things. (in line ...)

On 23-01-15 21:34, Danny van Heumen wrote:

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were
all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that
the 2nd session "listening in" (not in the malicious way) does not have
an OTR session established. So, as a consequence this session receives
encrypted messages as if they were normal messages.

This is likely not an issue in the OTR4J library, but rather in Jitsi
not including OTR4J, since it isn't enabled. I believe that if OTR4J was
"in the loop" it would have handled this message. Maybe by dropping a
system message saying what is happening. Need to look into that further.

There seems to be an issue here. You're talking about
OtrTransformLayer:149, right? Where this code fragment is executed:

f (!policy.getEnableManual()
            && sessionStatus != ScSessionStatus.ENCRYPTED
            && sessionStatus != ScSessionStatus.FINISHED)
            return evt;

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

This one's a bit tricky. We receive a text message which is encrypted.
Once decrypted, we need to discover whether it is intended as HTML or
plain text. I'm not sure how another OTR-capable chat client makes this
distinction, though looking at Pidgin's behaviour, I suspect they may
simply have assumed HTML. (Otherwise it wouldn't have been as simple to
inject styling in the message sent to Pidgin client.)

Other clients, like Miranda, have the exact same problem when they
communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I
suppose the messages that Pidgin is sending don't have their
contentType set correctly, right? In that case, one way to fix it
would be to assume HTML if the remote client is Pidgin.

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

Same as above.

All should be fairly easy to fix.

I should've known better ... saying things like that :stuck_out_tongue:

(Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows
otherwise, plz let me know.

As an added bonus I found out that plain text messages aren't correctly
escaped in the notification popup, so at least that's fixed now :slight_smile:

Danny

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Hey Danny!

Okay, so it's time for an update on this topic ...

@George: In case of TL;DR, could you check my commit, just to be sure?
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
It's about removing the conditionals so any message reaches the otr4j
library, even if a secure session is not established yet. Basically what
you suggested before.

I checked the commit and I agree with it. Thanks very much for fixing the issue!

Also, can you explain why at SessionImpl:479 (call to
setSessionStatus(ENCRYPTED)) the called method resets auth (AuthContext)
to setIsSecure(false), while the passed parameter is
SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
contradictory.)

The idea is that once the session goes to encrypted we forget everything about the authentication context.

I've been playing around with the whole OTR UI and plugin to see what I
could discover apart from the stuff we already know. I have been playing
around for a few hours and this is a quick report of what I've been able
to discover.

This is hard work and lots of time, thank you very much Danny for doing it! I'll have a much closer look at all the issues you describe tonight.

In the meantime I believe we should open a few issues about the OTR plugin in our trac. I'd actually prefer GH but I think we have disabled the issues module for the Jitsi project. I'm going to do that tonight.

···

On 22 Feb 2015, at 21:18, Danny van Heumen wrote:

1. The raw OTR-encrypted message I received as described below, is due
to XMPP Carbons being enabled. We receive the message sent from another
client (same account) and we subscribed to carbon copies, so we receive
a carbon of the raw message. This particular message flow is not hooked
into otr4j, so it gets shown as a plain old message. (@fippo: Thanks for
pointing out the carbons!)

a) I'm thinking of whether or not we *can* hook that into otr4j. Maybe
we can process this as a "received" message. I have not done that yet,
though, because I'm not a 100% sure that there aren't any other
consequences. (It would be nice to see a notification of a message
encrypted for another session, and have the ability to drop the message
itself, since that has no value to us.)

2. I have seen a mismatching padlock icon, compared to the actual
session and the sessions in the "Secure chat" menu. The sessions listed
in "Secure chat" menu have always been accurate AFAICT. I have not been
able to reproduce it reliably though -- and I'm starting to doubt
whether session selection isn't the culprit.

3. About encryption-state mismatches ...

a) I have NOT been able to get a session that was not actually
encrypted even though Jitsi says it IS encrypted. This in itself does
not prove that there isn't an issue, but it's not so easy to get into
that state by just clicking buttons (with or without thinking about it).

b) I have been able to send unencrypted messages while an encrypted
session was set up. HOWEVER, Jitsi accurately showed an open padlock
when sending the message. The reason for this is that I had selected the
"root" XMPP session and sent the message via there. If you select this
session, Jitsi accurately shows an open padlock and messages are sent to
all session (I think). The chat client on the other side accurately
warns of an unencrypted message being received. If you then select one
specific XMPP session in the chat window, the padlock updates and indeed
messages are sent in encrypted form.

As far as I have been able to determine this is all expected behaviour.
The root session cannot be OTR-encrypted, since it sends to (multiple?)
sessions and you would need to encrypt differently for every session. So
you need to select one specific session to send encrypted messages. (OTR
also stores a new session instance for each XMPP session.)

4. Given the behaviour above, it would be good to somehow warn or
prevent users from selecting the "root" session if multiple sessions are
known/active. This should prevent mistakes from being made.

a) We may need to change the UI so that the "active" session (last
message) is selected automatically and users would always need to select
a specific session to switch. (And maybe we should not allow selecting
this top-most session.)

... after some more hours of fiddling around and lots of confusing
moments ...

5. I have now determined that XMPP message carbons can interfere with
correctly establishing an encrypted OTR sessions at one of two sides. I
am not clear on the details yet (and I am starting to believe that this
is a bug in the implementation), but this issue seems to arise at the
side where 2 sessions are active and carbons are enabled. (I see the
occasional OTR debug log entry about messages meant for another session.)

a) The result is an encrypted OTR session that IS established for the
non-problematic side (account with only a single XMPP session). The
sessions is established fully, and it can send encrypted messages. The
other side (2 active XMPP sessions) eventually decides to go with
plaintext and does not expose the encrypted session, even though it is
established. It is established because it can decrypt any received
encrypted messages, however ask the OTR Session-instance for its
SessionStatus and it will return PLAINTEXT. Send a message from that
side and it will send a plain text message (not encrypted). NOTE that
the padlock icon consistently shows an accurate state.

6. Further more, a small issue which may not actually be a problem. I
note this here for reference as it may only ever occur if you delay the
process by debugging (stepping through code): In the OTR plugin, if the
timeout-scheduler isn't cancelled in time, it will set a "timeout" state
which is then used and hides the true state of the OTR Session instance.

Reproduction recipe for 5.:
1. Start some other chat client. Log in the account with server support
message carbons, e.g. @jit.si. This is going to be the shared account.
2. Start Jitsi. Log in with same account as in 1. Make sure message
carbons are enabled.
Using Jitsi, log in with another XMPP account.

-- So now 2 XMPP accounts are active, 1 shared by Jitsi and other client
- with message carbons, 1 solely for Jitsi.

3. Use client from 1. initiate OTR-encrypted session with 2. using
@jit.si account
4. Using client from 1. send message to other XMPP account.
5. Jitsi popup shows that it received a message. Click popup to view
message. Notice that OTR session is established.
6. In Jitsi, select the other session for this account (@jit.si) that is
available (which accidentally is the Jitsi client's XMPP session)
7. Initiate OTR-encrypted session between the 2 accounts, both in Jitsi.

-- Notice that session correctly establishes at initiating side, which
is the 1-session XMPP account solely in use by Jitsi.

9. Send a message over this newly instantiated OTR session.
10. Popup shows for newly received message, click and it opens a second
tab showing the message received on the shared @jit.si account.

-- Notice now that *that* account's OTR-encrypted session was not
recognized. The padlock is open. Sending messages now will send them as
plain text. However, it did just receive the encrypted message and
decrypted it successfully.

When enabling debug logging in OTR one notices that the messages are
indeed encrypted from the side showing the OTR-encrypted session, and
plain text for the other side.

Disabling message carbons fixes the problem described above. (At least,
it does for me.)

Sorry for making this such a long post. To conclude: I have been trying
to get a feel for the state of OTR support in Jitsi. We already knew of
some issues with state mangement. I believe these findings may have
fine-tuned this issue a bit. For now I do not see any big problems,
especially since the UI always showed an accurate state. Confusion is
mostly caused by XMPP's message carbons together with multiple active
sessions, which also makes the issues local to the XMPP protocol. The
confusion is focused on using the UI, as OTR seems to do the right thing
in the background. EXCEPT for this one issue described above where the
OTR-encrypted session should have been established at both sides. But
even then, Jitsi showed the correct state as the results were accordingly.

So, if you rely on OTR, make sure that your XMPP accounts have message
carbons disabled. Then you should have a pretty smooth ride. (As far as
I can tell from these tests.)

Danny

On 26-01-15 10:50, George Politis wrote:

On 25 Jan 2015, at 23:14, Danny van Heumen wrote:

Hi all,

Quick follow-up. I haven't had as much time as I would've liked. I have
found out the following things. (in line ...)

On 23-01-15 21:34, Danny van Heumen wrote:

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were
all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that
the 2nd session "listening in" (not in the malicious way) does not have
an OTR session established. So, as a consequence this session receives
encrypted messages as if they were normal messages.

This is likely not an issue in the OTR4J library, but rather in Jitsi
not including OTR4J, since it isn't enabled. I believe that if OTR4J was
"in the loop" it would have handled this message. Maybe by dropping a
system message saying what is happening. Need to look into that further.

There seems to be an issue here. You're talking about
OtrTransformLayer:149, right? Where this code fragment is executed:

f (!policy.getEnableManual()
         && sessionStatus != ScSessionStatus.ENCRYPTED
         && sessionStatus != ScSessionStatus.FINISHED)
         return evt;

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

This one's a bit tricky. We receive a text message which is encrypted.
Once decrypted, we need to discover whether it is intended as HTML or
plain text. I'm not sure how another OTR-capable chat client makes this
distinction, though looking at Pidgin's behaviour, I suspect they may
simply have assumed HTML. (Otherwise it wouldn't have been as simple to
inject styling in the message sent to Pidgin client.)

Other clients, like Miranda, have the exact same problem when they
communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I
suppose the messages that Pidgin is sending don't have their
contentType set correctly, right? In that case, one way to fix it
would be to assume HTML if the remote client is Pidgin.

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

Same as above.

All should be fairly easy to fix.

I should've known better ... saying things like that :stuck_out_tongue:

(Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows
otherwise, plz let me know.

As an added bonus I found out that plain text messages aren't correctly
escaped in the notification popup, so at least that's fixed now :slight_smile:

Danny

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8
···

Hi all,

  So, here's another follow up with what I found out yesterday. I think I may have an explanation of what happens. It's pretty interesting interplay of features, I think ...

  A FEW FACTS:

  * When message carbons are activated, the messages sent by one client are repeated to the other clients as message delivered events. (I'm quite sure, but please correct me if I'm wrong here ...)

  * Jitsi's OTR implementation does not process message delivered events. (The only exception to this is to check if a message is injected such that the user is not bothered with OTR interaction inside the client.)

  * I found out that the session status gets updated in another instance of SessionImpl than where the instance where we query for the current session status. This explains both:

  1. Why the statuses deviate - between session establishment (in log messages) and session status querying, and

  2. Why messages till get decrypted when received even though the status is PLAINTEXT.

  FLOW OF EVENTS: Here's where it gets interesting ...

  Say we have:

  * An account on server jit.si which supports message carbons. * An account on server gmail.com which does not support message carbons. * Client A, a Jitsi client, with account - with message carbons enabled - and account . * Client B, another client with account - without message carbons enabled. 1. We initiate an OTR session with client A to account . This means that B sends the OTR v3 query message. -- a) client A receives the request on account -- b) client A receives a carbon of the request on . This message isn't processed by otr4j, so effectively gets ignored. 2. Client A receives OTR v3 query message, answers with D-H commit message. -- a) client B receives the request on account . -- b) client A receives the message carbon and sets a master session for this sender instance id, however it does not expect the D-H commit message so does not respond. 3. Client A () and client B () finish up OTR protocol and establish a secure session. Now Client A  () wants to establish an OTR session with Client A (), so it sends initial OTR v3 query message. 4. Client A on sends message to for client A (that is, that specific session id). -- a) Client A receives this message, however it contains a different sender instance id than the message before, so a slave session is established. The received message gets passed through to slave session. Slave session handles message. 5. Client A responds and continues establishing OTR encrypted session. Now Client A has 2 sessions available: * Master session: PLAINTEXT, received some OTR messages but nothing to establish a connection with. * Slave session: ENCRYPTED, did full processing of OTR session establishment and has a full, completed ENCRYPTED session. Now that an encrypted session is established, we call listeners to inform of a sessionStatusChanged(OtrContact). However, a call of getStatus(SessionID for OtrContact) will return the session status of the MASTER session, which is plain text, since it was based upon the message carbons. RESULT: 1. Plain text Master session. Will answer calls to getStatus(SessionID). 2. Fully established ENCRYPTED slave session. Will be reachable for decrypting messages, however it is completely off-the-radar when querying the status of a session. 3. Received messages get routed by their sender instance ID and arrive at the slave session, get processed appropriately and hence get returned decrypted to Jitsi. 4. Sent messages get sent in plain text according to the Master session's status. Client at other end will received a plain text message even though it has an OTR session established. I hope this makes sense. It is a bit late, so please be critical and check if everything makes sense. I can clarify if there are any questions. (Or replay the problem and/or recheck the logging.) Assuming the above is correct, this would also explain my earlier comment regarding disabling message carbons. This would indeed prevent establishing the early Master session, hence when the OTR session is deliberately initiated, this would become the Master session and one would indeed get the correct Session Status when queried via getStatus(SessionID). So, if this correctly establishes the problem, I am quite interested in how we're going to solve this one. I haven't thought about this one yet ... :-) Regards, Danny On 22-02-15 21:18, Danny van Heumen wrote:

a@jit.si
b@gmail.com
a@jit.sib@gmail.com
a@jit.si

b@gmail.com
b@gmail.com
a@jit.si

a@jit.si
a@jit.si

a@jit.sib@gmail.com

b@gmail.coma@jit.si

b@gmail.coma@jit.si
a@jit.si

a@jit.sia@jit.si


Okay, so it's time for an update on this topic ... @George: In case of TL;DR, could you check my commit, just to be sure? It's about removing the conditionals so any message reaches the otr4j library, even if a secure session is not established yet. Basically what you suggested before. Also, can you explain why at SessionImpl:479 (call to setSessionStatus(ENCRYPTED)) the called method resets auth (AuthContext) to setIsSecure(false), while the passed parameter is SessionStatus.ENCRYPTED? (It may be completely fine, but it seems contradictory.) I've been playing around with the whole OTR UI and plugin to see what I could discover apart from the stuff we already know. I have been playing around for a few hours and this is a quick report of what I've been able to discover. 1. The raw OTR-encrypted message I received as described below, is due to XMPP Carbons being enabled. We receive the message sent from another client (same account) and we subscribed to carbon copies, so we receive a carbon of the raw message. This particular message flow is not hooked into otr4j, so it gets shown as a plain old message. (@fippo: Thanks for pointing out the carbons!) a) I'm thinking of whether or not we *can* hook that into otr4j. Maybe we can process this as a "received" message. I have not done that yet, though, because I'm not a 100% sure that there aren't any other consequences. (It would be nice to see a notification of a message encrypted for another session, and have the ability to drop the message itself, since that has no value to us.) 2. I have seen a mismatching padlock icon, compared to the actual session and the sessions in the "Secure chat" menu. The sessions listed in "Secure chat" menu have always been accurate AFAICT. I have not been able to reproduce it reliably though -- and I'm starting to doubt whether session selection isn't the culprit. 3. About encryption-state mismatches ... a) I have NOT been able to get a session that was not actually encrypted even though Jitsi says it IS encrypted. This in itself does not prove that there isn't an issue, but it's not so easy to get into that state by just clicking buttons (with or without thinking about it). b) I have been able to send unencrypted messages while an encrypted session was set up. HOWEVER, Jitsi accurately showed an open padlock when sending the message. The reason for this is that I had selected the "root" XMPP session and sent the message via there. If you select this session, Jitsi accurately shows an open padlock and messages are sent to all session (I think). The chat client on the other side accurately warns of an unencrypted message being received. If you then select one specific XMPP session in the chat window, the padlock updates and indeed messages are sent in encrypted form. As far as I have been able to determine this is all expected behaviour. The root session cannot be OTR-encrypted, since it sends to (multiple?) sessions and you would need to encrypt differently for every session. So you need to select one specific session to send encrypted messages. (OTR also stores a new session instance for each XMPP session.) 4. Given the behaviour above, it would be good to somehow warn or prevent users from selecting the "root" session if multiple sessions are known/active. This should prevent mistakes from being made. a) We may need to change the UI so that the "active" session (last message) is selected automatically and users would always need to select a specific session to switch. (And maybe we should not allow selecting this top-most session.) ... after some more hours of fiddling around and lots of confusing moments ... 5. I have now determined that XMPP message carbons can interfere with correctly establishing an encrypted OTR sessions at one of two sides. I am not clear on the details yet (and I am starting to believe that this is a bug in the implementation), but this issue seems to arise at the side where 2 sessions are active and carbons are enabled. (I see the occasional OTR debug log entry about messages meant for another session.) a) The result is an encrypted OTR session that IS established for the non-problematic side (account with only a single XMPP session). The sessions is established fully, and it can send encrypted messages. The other side (2 active XMPP sessions) eventually decides to go with plaintext and does not expose the encrypted session, even though it is established. It is established because it can decrypt any received encrypted messages, however ask the OTR Session-instance for its SessionStatus and it will return PLAINTEXT. Send a message from that side and it will send a plain text message (not encrypted). NOTE that the padlock icon consistently shows an accurate state. 6. Further more, a small issue which may not actually be a problem. I note this here for reference as it may only ever occur if you delay the process by debugging (stepping through code): In the OTR plugin, if the timeout-scheduler isn't cancelled in time, it will set a "timeout" state which is then used and hides the true state of the OTR Session instance. Reproduction recipe for 5.: 1. Start some other chat client. Log in the account with server support message carbons, e.g. @jit.si. This is going to be the shared account. 2. Start Jitsi. Log in with same account as in 1. Make sure message carbons are enabled. Using Jitsi, log in with another XMPP account. -- So now 2 XMPP accounts are active, 1 shared by Jitsi and other client - with message carbons, 1 solely for Jitsi. 3. Use client from 1. initiate OTR-encrypted session with 2. using @jit.si account 4. Using client from 1. send message to other XMPP account. 5. Jitsi popup shows that it received a message. Click popup to view message. Notice that OTR session is established. 6. In Jitsi, select the other session for this account (@jit.si) that is available (which accidentally is the Jitsi client's XMPP session) 7. Initiate OTR-encrypted session between the 2 accounts, both in Jitsi. -- Notice that session correctly establishes at initiating side, which is the 1-session XMPP account solely in use by Jitsi. 9. Send a message over this newly instantiated OTR session. 10. Popup shows for newly received message, click and it opens a second tab showing the message received on the shared @jit.si account. -- Notice now that *that* account's OTR-encrypted session was not recognized. The padlock is open. Sending messages now will send them as plain text. However, it did just receive the encrypted message and decrypted it successfully. When enabling debug logging in OTR one notices that the messages are indeed encrypted from the side showing the OTR-encrypted session, and plain text for the other side. Disabling message carbons fixes the problem described above. (At least, it does for me.) Sorry for making this such a long post. To conclude: I have been trying to get a feel for the state of OTR support in Jitsi. We already knew of some issues with state mangement. I believe these findings may have fine-tuned this issue a bit. For now I do not see any big problems, especially since the UI always showed an accurate state. Confusion is mostly caused by XMPP's message carbons together with multiple active sessions, which also makes the issues local to the XMPP protocol. The confusion is focused on using the UI, as OTR seems to do the right thing in the background. EXCEPT for this one issue described above where the OTR-encrypted session should have been established at both sides. But even then, Jitsi showed the correct state as the results were accordingly. So, if you rely on OTR, make sure that your XMPP accounts have message carbons disabled. Then you should have a pretty smooth ride. (As far as I can tell from these tests.) Danny On 26-01-15 10:50, George Politis wrote:
On 25 Jan 2015, at 23:14, Danny van Heumen wrote:

Hi all, Quick follow-up. I haven't had as much time as I would've liked. I have found out the following things. (in line ...) On 23-01-15 21:34, Danny van Heumen wrote:

Hi all, Because of recent remarks about OTR support in Jitsi, I've been trying out some cases - all using XMPP as messaging protocol. These were all in the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also logged in on Pidgin. For now, here's what I've found. 1. When using multiple sessions, Jitsi doesn't seem to correctly distinguish and discard the messages-for-another-session. I quickly looked at the otr4j source and if I read it correctly, then the message gets returned unchanged. (Only took a quick look, so may not be accurate.) In that case the Jitsi client will just show the base64(encrypted) content. ... at least in this test ... (So, send from Jitsi client to Pidgin client, while Jitsi also connected to same account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that the 2nd session "listening in" (not in the malicious way) does not have an OTR session established. So, as a consequence this session receives encrypted messages as if they were normal messages. This is likely not an issue in the OTR4J library, but rather in Jitsi not including OTR4J, since it isn't enabled. I believe that if OTR4J was "in the loop" it would have handled this message. Maybe by dropping a system message saying what is happening. Need to look into that further.

There seems to be an issue here. You're talking about OtrTransformLayer:149, right? Where this code fragment is executed: f (!policy.getEnableManual() && sessionStatus != ScSessionStatus.ENCRYPTED && sessionStatus != ScSessionStatus.FINISHED) return evt;
2. Jitsi does not escape html, so when Pidgin receives the message it gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin side. (Though javascript doesn't get executed :-P)
This one's a bit tricky. We receive a text message which is encrypted. Once decrypted, we need to discover whether it is intended as HTML or plain text. I'm not sure how another OTR-capable chat client makes this distinction, though looking at Pidgin's behaviour, I suspect they may simply have assumed HTML. (Otherwise it wouldn't have been as simple to inject styling in the message sent to Pidgin client.)
Other clients, like Miranda, have the exact same problem when they communicate with Pidgin (). I suppose the messages that Pidgin is sending don't have their contentType set correctly, right? In that case, one way to fix it would be to assume HTML if the remote client is Pidgin.
3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
Same as above.
All should be fairly easy to fix.
I should've known better ... saying things like that :-P

(Assuming Pidgin is the one behaving as expected, which I am at the moment but will try to check before fixing things in Jitsi.) I haven't found a case yet where I get to see the actual HTML that is being sent as was described in (if I understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows otherwise, plz let me know. As an added bonus I found out that plain text messages aren't correctly escaped in the notification popup, so at least that's fixed now :-) Danny



Danny _______________________________________________ dev mailing list Unsubscribe instructions and other list options:

_______________________________________________ dev mailing list Unsubscribe instructions and other list options:

_______________________________________________ dev mailing list Unsubscribe instructions and other list options:


_______________________________________________ dev mailing list Unsubscribe instructions and other list options:

https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473ahttps://developer.pidgin.im/ticket/8453http://lists.jitsi.org/pipermail/users/2015-January/008515.htmldev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/devdev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/devdev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/devdev@jitsi.orghttp://lists.jitsi.org/mailman/listinfo/dev


#9

Hi George,

My last message was mainly a record of what I've been trying to do and
what my conclusions were based on the findings then.

The reason for this is partly because of messages on the mailing list
saying that OTR doesn't work for people. For now, I have not encountered
those big "game changing" issues, but I did find some smaller ones that
could cause confusion.

There is this one obvious issue. I'm planning to dive somewhat deeper
into it, because I think I'm right on track for that one.
More below ...

Hey Danny!

Okay, so it's time for an update on this topic ...

@George: In case of TL;DR, could you check my commit, just to be sure?
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
It's about removing the conditionals so any message reaches the otr4j
library, even if a secure session is not established yet. Basically what
you suggested before.

I checked the commit and I agree with it. Thanks very much for fixing the issue!

Also, can you explain why at SessionImpl:479 (call to
setSessionStatus(ENCRYPTED)) the called method resets auth (AuthContext)
to setIsSecure(false), while the passed parameter is
SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
contradictory.)

The idea is that once the session goes to encrypted we forget everything about the authentication context.

Ah right, I figured it was either that or a bug. Glad it is intentional.

I've been playing around with the whole OTR UI and plugin to see what I
could discover apart from the stuff we already know. I have been playing
around for a few hours and this is a quick report of what I've been able
to discover.

This is hard work and lots of time, thank you very much Danny for doing it! I'll have a much closer look at all the issues you describe tonight.

In the meantime I believe we should open a few issues about the OTR plugin in our trac. I'd actually prefer GH but I think we have disabled the issues module for the Jitsi project. I'm going to do that tonight.

/me 2, +1 for GH, if possible.

1. The raw OTR-encrypted message I received as described below, is due
to XMPP Carbons being enabled. We receive the message sent from another
client (same account) and we subscribed to carbon copies, so we receive
a carbon of the raw message. This particular message flow is not hooked
into otr4j, so it gets shown as a plain old message. (@fippo: Thanks for
pointing out the carbons!)

a) I'm thinking of whether or not we *can* hook that into otr4j. Maybe
we can process this as a "received" message. I have not done that yet,
though, because I'm not a 100% sure that there aren't any other
consequences. (It would be nice to see a notification of a message
encrypted for another session, and have the ability to drop the message
itself, since that has no value to us.)

2. I have seen a mismatching padlock icon, compared to the actual
session and the sessions in the "Secure chat" menu. The sessions listed
in "Secure chat" menu have always been accurate AFAICT. I have not been
able to reproduce it reliably though -- and I'm starting to doubt
whether session selection isn't the culprit.

3. About encryption-state mismatches ...

a) I have NOT been able to get a session that was not actually
encrypted even though Jitsi says it IS encrypted. This in itself does
not prove that there isn't an issue, but it's not so easy to get into
that state by just clicking buttons (with or without thinking about it).

b) I have been able to send unencrypted messages while an encrypted
session was set up. HOWEVER, Jitsi accurately showed an open padlock
when sending the message. The reason for this is that I had selected the
"root" XMPP session and sent the message via there. If you select this
session, Jitsi accurately shows an open padlock and messages are sent to
all session (I think). The chat client on the other side accurately
warns of an unencrypted message being received. If you then select one
specific XMPP session in the chat window, the padlock updates and indeed
messages are sent in encrypted form.

As far as I have been able to determine this is all expected behaviour.
The root session cannot be OTR-encrypted, since it sends to (multiple?)
sessions and you would need to encrypt differently for every session. So
you need to select one specific session to send encrypted messages. (OTR
also stores a new session instance for each XMPP session.)

4. Given the behaviour above, it would be good to somehow warn or
prevent users from selecting the "root" session if multiple sessions are
known/active. This should prevent mistakes from being made.

a) We may need to change the UI so that the "active" session (last
message) is selected automatically and users would always need to select
a specific session to switch. (And maybe we should not allow selecting
this top-most session.)

... after some more hours of fiddling around and lots of confusing
moments ...

5. I have now determined that XMPP message carbons can interfere with
correctly establishing an encrypted OTR sessions at one of two sides. I
am not clear on the details yet (and I am starting to believe that this
is a bug in the implementation), but this issue seems to arise at the
side where 2 sessions are active and carbons are enabled. (I see the
occasional OTR debug log entry about messages meant for another session.)

Do you have a clue on why otr4j would finish in PLAINTEXT instead of
ENCRYPTED? The closest thing to an explanation I could think of was that
one of those carbons could have disrupted the process. Though, I'm not
familiar enough with the implementation to predict how otr4j would
respond to that. Also, I'm not sure why we would receive a carbon if
Jitsi is the only one sending on that channel a.t.m. (Or maybe the other
client responds to the authn. verification messages?)

a) The result is an encrypted OTR session that IS established for the
non-problematic side (account with only a single XMPP session). The
sessions is established fully, and it can send encrypted messages. The
other side (2 active XMPP sessions) eventually decides to go with
plaintext and does not expose the encrypted session, even though it is
established. It is established because it can decrypt any received
encrypted messages, however ask the OTR Session-instance for its
SessionStatus and it will return PLAINTEXT. Send a message from that
side and it will send a plain text message (not encrypted). NOTE that
the padlock icon consistently shows an accurate state.

6. Further more, a small issue which may not actually be a problem. I
note this here for reference as it may only ever occur if you delay the
process by debugging (stepping through code): In the OTR plugin, if the
timeout-scheduler isn't cancelled in time, it will set a "timeout" state
which is then used and hides the true state of the OTR Session instance.

Reproduction recipe for 5.:
1. Start some other chat client. Log in the account with server support
message carbons, e.g. @jit.si. This is going to be the shared account.
2. Start Jitsi. Log in with same account as in 1. Make sure message
carbons are enabled.
Using Jitsi, log in with another XMPP account.

-- So now 2 XMPP accounts are active, 1 shared by Jitsi and other client
- with message carbons, 1 solely for Jitsi.

3. Use client from 1. initiate OTR-encrypted session with 2. using
@jit.si account
4. Using client from 1. send message to other XMPP account.
5. Jitsi popup shows that it received a message. Click popup to view
message. Notice that OTR session is established.
6. In Jitsi, select the other session for this account (@jit.si) that is
available (which accidentally is the Jitsi client's XMPP session)
7. Initiate OTR-encrypted session between the 2 accounts, both in Jitsi.

-- Notice that session correctly establishes at initiating side, which
is the 1-session XMPP account solely in use by Jitsi.

9. Send a message over this newly instantiated OTR session.
10. Popup shows for newly received message, click and it opens a second
tab showing the message received on the shared @jit.si account.

-- Notice now that *that* account's OTR-encrypted session was not
recognized. The padlock is open. Sending messages now will send them as
plain text. However, it did just receive the encrypted message and
decrypted it successfully.

Let me know if the repro recipe is not clear enough. It's kind of a
complicated set up and this is probably not the canonical recipe for
this issue.

Danny

···

On 23-02-15 14:52, George Politis wrote:

On 22 Feb 2015, at 21:18, Danny van Heumen wrote:

When enabling debug logging in OTR one notices that the messages are
indeed encrypted from the side showing the OTR-encrypted session, and
plain text for the other side.

Disabling message carbons fixes the problem described above. (At least,
it does for me.)

Sorry for making this such a long post. To conclude: I have been trying
to get a feel for the state of OTR support in Jitsi. We already knew of
some issues with state mangement. I believe these findings may have
fine-tuned this issue a bit. For now I do not see any big problems,
especially since the UI always showed an accurate state. Confusion is
mostly caused by XMPP's message carbons together with multiple active
sessions, which also makes the issues local to the XMPP protocol. The
confusion is focused on using the UI, as OTR seems to do the right thing
in the background. EXCEPT for this one issue described above where the
OTR-encrypted session should have been established at both sides. But
even then, Jitsi showed the correct state as the results were accordingly.

So, if you rely on OTR, make sure that your XMPP accounts have message
carbons disabled. Then you should have a pretty smooth ride. (As far as
I can tell from these tests.)

Danny

On 26-01-15 10:50, George Politis wrote:

On 25 Jan 2015, at 23:14, Danny van Heumen wrote:

Hi all,

Quick follow-up. I haven't had as much time as I would've liked. I have
found out the following things. (in line ...)

On 23-01-15 21:34, Danny van Heumen wrote:

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were
all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that
the 2nd session "listening in" (not in the malicious way) does not have
an OTR session established. So, as a consequence this session receives
encrypted messages as if they were normal messages.

This is likely not an issue in the OTR4J library, but rather in Jitsi
not including OTR4J, since it isn't enabled. I believe that if OTR4J was
"in the loop" it would have handled this message. Maybe by dropping a
system message saying what is happening. Need to look into that further.

There seems to be an issue here. You're talking about
OtrTransformLayer:149, right? Where this code fragment is executed:

f (!policy.getEnableManual()
         && sessionStatus != ScSessionStatus.ENCRYPTED
         && sessionStatus != ScSessionStatus.FINISHED)
         return evt;

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

This one's a bit tricky. We receive a text message which is encrypted.
Once decrypted, we need to discover whether it is intended as HTML or
plain text. I'm not sure how another OTR-capable chat client makes this
distinction, though looking at Pidgin's behaviour, I suspect they may
simply have assumed HTML. (Otherwise it wouldn't have been as simple to
inject styling in the message sent to Pidgin client.)

Other clients, like Miranda, have the exact same problem when they
communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I
suppose the messages that Pidgin is sending don't have their
contentType set correctly, right? In that case, one way to fix it
would be to assume HTML if the remote client is Pidgin.

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

Same as above.

All should be fairly easy to fix.

I should've known better ... saying things like that :stuck_out_tongue:

(Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows
otherwise, plz let me know.

As an added bonus I found out that plain text messages aren't correctly
escaped in the notification popup, so at least that's fixed now :slight_smile:

Danny

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

A quick addition ... I was thinking about which combinations are
possible for Master - Slave session combinations.

* Master session: PLAINTEXT + Slave session: ENCRYPTED -- possible as
this is the current problem.

* Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
possible, but should not be a problem. Given that the slave sessions are
about decrypting received messages. Sending encrypted messages wouldn't
be a problem, since the master session is ENCRYPTED. Also, the session
status reflects the status of the Master sessions which also sends, so
the status is accurate.

* Both PLAINTEXT shouldn't be an issue in any case, i.e. no encrypted
sessions established.

* Both ENCRYPTED: not sure if this makes sense, but in any case we would
sent an encrypted message. It might get delivered to the wrong address,
but it wouldn't unintentionally be sent PLAINTEXT, so not an issue(?)

Danny

···

On 25-02-15 23:43, Danny van Heumen wrote:

Hi all,

So, here's another follow up with what I found out yesterday. I think
I may have an explanation of what happens. It's pretty interesting
interplay of features, I think ...

A FEW FACTS:
* When message carbons are activated, the messages sent by one client
are repeated to the other clients as message delivered events. (I'm
quite sure, but please correct me if I'm wrong here ...)
* Jitsi's OTR implementation does not process message delivered
events. (The only exception to this is to check if a message is
injected such that the user is not bothered with OTR interaction
inside the client.)
* I found out that the session status gets updated in another instance
of SessionImpl than where the instance where we query for the current
session status. This explains both:

1. Why the statuses deviate - between session establishment (in log
messages) and session status querying, and
2. Why messages till get decrypted when received even though the
status is PLAINTEXT.

FLOW OF EVENTS: Here's where it gets interesting ...

Say we have:
* An account a@jit.si on server jit.si which supports message carbons.
* An account b@gmail.com on server gmail.com which does not support
message carbons.
* Client A, a Jitsi client, with account a@jit.si - with message
carbons enabled - and account b@gmail.com.
* Client B, another client with account a@jit.si - without message
carbons enabled.

1. We initiate an OTR session with client A to account b@gmail.com.
This means that B sends the OTR v3 query message.
-- a) client A receives the request on account b@gmail.com
-- b) client A receives a carbon of the request on a@jit.si. This
message isn't processed by otr4j, so effectively gets ignored.

2. Client A receives OTR v3 query message, answers with D-H commit
message.
-- a) client B receives the request on account a@jit.si.
-- b) client A a@jit.si receives the message carbon and sets a master
session for this sender instance id, however it does not expect the
D-H commit message so does not respond.

3. Client A (a@jit.si) and client B (b@gmail.com) finish up OTR
protocol and establish a secure session.

Now Client A (b@gmail.com) wants to establish an OTR session with
Client A (a@jit.si), so it sends initial OTR v3 query message.

4. Client A on b@gmail.com sends message to a@jit.si for client A
(that is, that specific session id).
-- a) Client A a@jit.si receives this message, however it contains a
different sender instance id than the message before, so a slave
session is established. The received message gets passed through to
slave session. Slave session handles message.

5. Client A a@jit.si responds and continues establishing OTR encrypted
session. Now Client A a@jit.si has 2 sessions available:
* Master session: PLAINTEXT, received some OTR messages but nothing to
establish a connection with.
* Slave session: ENCRYPTED, did full processing of OTR session
establishment and has a full, completed ENCRYPTED session.

Now that an encrypted session is established, we call listeners to
inform of a sessionStatusChanged(OtrContact). However, a call of
getStatus(SessionID for OtrContact) will return the session status of
the MASTER session, which is plain text, since it was based upon the
message carbons.

RESULT:

1. Plain text Master session. Will answer calls to getStatus(SessionID).
2. Fully established ENCRYPTED slave session. Will be reachable for
decrypting messages, however it is completely off-the-radar when
querying the status of a session.
3. Received messages get routed by their sender instance ID and arrive
at the slave session, get processed appropriately and hence get
returned decrypted to Jitsi.
4. Sent messages get sent in plain text according to the Master
session's status. Client at other end will received a plain text
message even though it has an OTR session established.

I hope this makes sense. It is a bit late, so please be critical and
check if everything makes sense. I can clarify if there are any
questions. (Or replay the problem and/or recheck the logging.)

Assuming the above is correct, this would also explain my earlier
comment regarding disabling message carbons. This would indeed prevent
establishing the early Master session, hence when the OTR session is
deliberately initiated, this would become the Master session and one
would indeed get the correct Session Status when queried via
getStatus(SessionID).

So, if this correctly establishes the problem, I am quite interested
in how we're going to solve this one. I haven't thought about this one
yet ... :slight_smile:

Regards,
Danny

On 22-02-15 21:18, Danny van Heumen wrote:

Okay, so it's time for an update on this topic ...

@George: In case of TL;DR, could you check my commit, just to be sure?
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
It's about removing the conditionals so any message reaches the otr4j
library, even if a secure session is not established yet. Basically what
you suggested before.
Also, can you explain why at SessionImpl:479 (call to
setSessionStatus(ENCRYPTED)) the called method resets auth (AuthContext)
to setIsSecure(false), while the passed parameter is
SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
contradictory.)

I've been playing around with the whole OTR UI and plugin to see what I
could discover apart from the stuff we already know. I have been playing
around for a few hours and this is a quick report of what I've been able
to discover.

1. The raw OTR-encrypted message I received as described below, is due
to XMPP Carbons being enabled. We receive the message sent from another
client (same account) and we subscribed to carbon copies, so we receive
a carbon of the raw message. This particular message flow is not hooked
into otr4j, so it gets shown as a plain old message. (@fippo: Thanks for
pointing out the carbons!)

  a) I'm thinking of whether or not we *can* hook that into otr4j. Maybe
we can process this as a "received" message. I have not done that yet,
though, because I'm not a 100% sure that there aren't any other
consequences. (It would be nice to see a notification of a message
encrypted for another session, and have the ability to drop the message
itself, since that has no value to us.)

2. I have seen a mismatching padlock icon, compared to the actual
session and the sessions in the "Secure chat" menu. The sessions listed
in "Secure chat" menu have always been accurate AFAICT. I have not been
able to reproduce it reliably though -- and I'm starting to doubt
whether session selection isn't the culprit.

3. About encryption-state mismatches ...

  a) I have NOT been able to get a session that was not actually
encrypted even though Jitsi says it IS encrypted. This in itself does
not prove that there isn't an issue, but it's not so easy to get into
that state by just clicking buttons (with or without thinking about it).

  b) I have been able to send unencrypted messages while an encrypted
session was set up. HOWEVER, Jitsi accurately showed an open padlock
when sending the message. The reason for this is that I had selected the
"root" XMPP session and sent the message via there. If you select this
session, Jitsi accurately shows an open padlock and messages are sent to
all session (I think). The chat client on the other side accurately
warns of an unencrypted message being received. If you then select one
specific XMPP session in the chat window, the padlock updates and indeed
messages are sent in encrypted form.

As far as I have been able to determine this is all expected behaviour.
The root session cannot be OTR-encrypted, since it sends to (multiple?)
sessions and you would need to encrypt differently for every session. So
you need to select one specific session to send encrypted messages. (OTR
also stores a new session instance for each XMPP session.)

4. Given the behaviour above, it would be good to somehow warn or
prevent users from selecting the "root" session if multiple sessions are
known/active. This should prevent mistakes from being made.

  a) We may need to change the UI so that the "active" session (last
message) is selected automatically and users would always need to select
a specific session to switch. (And maybe we should not allow selecting
this top-most session.)

... after some more hours of fiddling around and lots of confusing
moments ...

5. I have now determined that XMPP message carbons can interfere with
correctly establishing an encrypted OTR sessions at one of two sides. I
am not clear on the details yet (and I am starting to believe that this
is a bug in the implementation), but this issue seems to arise at the
side where 2 sessions are active and carbons are enabled. (I see the
occasional OTR debug log entry about messages meant for another session.)

  a) The result is an encrypted OTR session that IS established for the
non-problematic side (account with only a single XMPP session). The
sessions is established fully, and it can send encrypted messages. The
other side (2 active XMPP sessions) eventually decides to go with
plaintext and does not expose the encrypted session, even though it is
established. It is established because it can decrypt any received
encrypted messages, however ask the OTR Session-instance for its
SessionStatus and it will return PLAINTEXT. Send a message from that
side and it will send a plain text message (not encrypted). NOTE that
the padlock icon consistently shows an accurate state.

6. Further more, a small issue which may not actually be a problem. I
note this here for reference as it may only ever occur if you delay the
process by debugging (stepping through code): In the OTR plugin, if the
timeout-scheduler isn't cancelled in time, it will set a "timeout" state
which is then used and hides the true state of the OTR Session instance.

Reproduction recipe for 5.:
1. Start some other chat client. Log in the account with server support
message carbons, e.g. @jit.si. This is going to be the shared account.
2. Start Jitsi. Log in with same account as in 1. Make sure message
carbons are enabled.
    Using Jitsi, log in with another XMPP account.

-- So now 2 XMPP accounts are active, 1 shared by Jitsi and other client
- with message carbons, 1 solely for Jitsi.

3. Use client from 1. initiate OTR-encrypted session with 2. using
@jit.si account
4. Using client from 1. send message to other XMPP account.
5. Jitsi popup shows that it received a message. Click popup to view
message. Notice that OTR session is established.
6. In Jitsi, select the other session for this account (@jit.si) that is
available (which accidentally is the Jitsi client's XMPP session)
7. Initiate OTR-encrypted session between the 2 accounts, both in Jitsi.

-- Notice that session correctly establishes at initiating side, which
is the 1-session XMPP account solely in use by Jitsi.

9. Send a message over this newly instantiated OTR session.
10. Popup shows for newly received message, click and it opens a second
tab showing the message received on the shared @jit.si account.

-- Notice now that *that* account's OTR-encrypted session was not
recognized. The padlock is open. Sending messages now will send them as
plain text. However, it did just receive the encrypted message and
decrypted it successfully.

When enabling debug logging in OTR one notices that the messages are
indeed encrypted from the side showing the OTR-encrypted session, and
plain text for the other side.

Disabling message carbons fixes the problem described above. (At least,
it does for me.)

Sorry for making this such a long post. To conclude: I have been trying
to get a feel for the state of OTR support in Jitsi. We already knew of
some issues with state mangement. I believe these findings may have
fine-tuned this issue a bit. For now I do not see any big problems,
especially since the UI always showed an accurate state. Confusion is
mostly caused by XMPP's message carbons together with multiple active
sessions, which also makes the issues local to the XMPP protocol. The
confusion is focused on using the UI, as OTR seems to do the right thing
in the background. EXCEPT for this one issue described above where the
OTR-encrypted session should have been established at both sides. But
even then, Jitsi showed the correct state as the results were accordingly.

So, if you rely on OTR, make sure that your XMPP accounts have message
carbons disabled. Then you should have a pretty smooth ride. (As far as
I can tell from these tests.)

Danny

On 26-01-15 10:50, George Politis wrote:

On 25 Jan 2015, at 23:14, Danny van Heumen wrote:

Hi all,

Quick follow-up. I haven't had as much time as I would've liked. I have
found out the following things. (in line ...)

On 23-01-15 21:34, Danny van Heumen wrote:

Hi all,

Because of recent remarks about OTR support in Jitsi, I've been trying
out some cases - all using XMPP as messaging protocol. These were
all in
the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts also
logged in on Pidgin.

For now, here's what I've found.

1. When using multiple sessions, Jitsi doesn't seem to correctly
distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

It is just slightly different than I've stated above. It turns out that
the 2nd session "listening in" (not in the malicious way) does not have
an OTR session established. So, as a consequence this session receives
encrypted messages as if they were normal messages.

This is likely not an issue in the OTR4J library, but rather in Jitsi
not including OTR4J, since it isn't enabled. I believe that if OTR4J was
"in the loop" it would have handled this message. Maybe by dropping a
system message saying what is happening. Need to look into that further.

There seems to be an issue here. You're talking about
OtrTransformLayer:149, right? Where this code fragment is executed:

f (!policy.getEnableManual()
            && sessionStatus != ScSessionStatus.ENCRYPTED
            && sessionStatus != ScSessionStatus.FINISHED)
            return evt;

2. Jitsi does not escape html, so when Pidgin receives the message it
gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
side. (Though javascript doesn't get executed :-P)

This one's a bit tricky. We receive a text message which is encrypted.
Once decrypted, we need to discover whether it is intended as HTML or
plain text. I'm not sure how another OTR-capable chat client makes this
distinction, though looking at Pidgin's behaviour, I suspect they may
simply have assumed HTML. (Otherwise it wouldn't have been as simple to
inject styling in the message sent to Pidgin client.)

Other clients, like Miranda, have the exact same problem when they
communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I
suppose the messages that Pidgin is sending don't have their
contentType set correctly, right? In that case, one way to fix it
would be to assume HTML if the remote client is Pidgin.

3. Jitsi does not unescape html received from Pidgin. So "<dude>" sent
at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.

Same as above.

All should be fairly easy to fix.

I should've known better ... saying things like that :stuck_out_tongue:

(Assuming Pidgin is the one behaving
as expected, which I am at the moment but will try to check before
fixing things in Jitsi.)

I haven't found a case yet where I get to see the actual HTML that is
being sent as was described in
http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
understand correctly that is ...)

Still same. I have only seen html entities up to now. If anyone knows
otherwise, plz let me know.

As an added bonus I found out that plain text messages aren't correctly
escaped in the notification popup, so at least that's fixed now :slight_smile:

Danny

Danny

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hello all,

Sorry to join so late but I've been quite busy recently :slight_smile:

1. When using multiple sessions, Jitsi doesn't seem to correctly

distinguish and discard the messages-for-another-session. I quickly
looked at the otr4j source and if I read it correctly, then the message
gets returned unchanged. (Only took a quick look, so may not be
accurate.) In that case the Jitsi client will just show the
base64(encrypted) content. ... at least in this test ... (So, send from
Jitsi client to Pidgin client, while Jitsi also connected to same
account as Pidgin's is logged on to.)

First, just to make sure that we're on the same page - what are message
carbons used for? I'm not very familiar with the XMPP protocol but I took a
look at XEP-0280 and as far as I understood it is an extension that enables
clients to send xmpp messages to the bare jid of a contact. The contact
then will receive these messages on all of his devices if the server
supports carbons. Did I get this right?

If that's the case then carbons is exactly what OTR v 3 was designed to
deal with:

   - Both fragmented and unfragmented messages contain sender and
   recipient instance tags. This avoids an issue on IM networks that always
   relay all messages to all sessions of a client who is logged in multiple
   times. In this situation, OTR clients can attempt to establish an OTR
   session indefinitely if there are interleaving messages from each of the
   sessions.

What that means is that every OTR message is marked with an Instance Tag.

So if I per say receive an OTR encrypted message on my laptop with an
instance tag that is different than I expected, then it is meant for
another device of mine - my phone probably, and I will discard it (and
print message meant for another session on my laptop). But since carbons
are enabled, my phone should've received the message too and decrypted it
successfully. So these "message for another session" logs are something
completely normal when carbons are enabled and I'm logged on multiple
devices.

I've just did a simple test on my local machine with 4 jitsi clients (2
users logged in 2 times) and tried to exchange some messages using the bare
jid. Everything seemed to work smoothly. Or are you experiencing some other
behaviour?

Best regards,
Marin

···

On Tue, Feb 24, 2015 at 1:31 AM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi George,

My last message was mainly a record of what I've been trying to do and
what my conclusions were based on the findings then.

The reason for this is partly because of messages on the mailing list
saying that OTR doesn't work for people. For now, I have not encountered
those big "game changing" issues, but I did find some smaller ones that
could cause confusion.

There is this one obvious issue. I'm planning to dive somewhat deeper
into it, because I think I'm right on track for that one.
More below ...

On 23-02-15 14:52, George Politis wrote:
> Hey Danny!
>
> On 22 Feb 2015, at 21:18, Danny van Heumen wrote:
>
>> Okay, so it's time for an update on this topic ...
>>
>> @George: In case of TL;DR, could you check my commit, just to be sure?
>>
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
>> It's about removing the conditionals so any message reaches the otr4j
>> library, even if a secure session is not established yet. Basically what
>> you suggested before.
> I checked the commit and I agree with it. Thanks very much for fixing
the issue!
>
>> Also, can you explain why at SessionImpl:479 (call to
>> setSessionStatus(ENCRYPTED)) the called method resets auth (AuthContext)
>> to setIsSecure(false), while the passed parameter is
>> SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
>> contradictory.)
>>
> The idea is that once the session goes to encrypted we forget everything
about the authentication context.
Ah right, I figured it was either that or a bug. Glad it is intentional.

>
>> I've been playing around with the whole OTR UI and plugin to see what I
>> could discover apart from the stuff we already know. I have been playing
>> around for a few hours and this is a quick report of what I've been able
>> to discover.
>>
> This is hard work and lots of time, thank you very much Danny for doing
it! I'll have a much closer look at all the issues you describe tonight.
>
> In the meantime I believe we should open a few issues about the OTR
plugin in our trac. I'd actually prefer GH but I think we have disabled the
issues module for the Jitsi project. I'm going to do that tonight.
/me 2, +1 for GH, if possible.

>
>> 1. The raw OTR-encrypted message I received as described below, is due
>> to XMPP Carbons being enabled. We receive the message sent from another
>> client (same account) and we subscribed to carbon copies, so we receive
>> a carbon of the raw message. This particular message flow is not hooked
>> into otr4j, so it gets shown as a plain old message. (@fippo: Thanks for
>> pointing out the carbons!)
>>
>> a) I'm thinking of whether or not we *can* hook that into otr4j. Maybe
>> we can process this as a "received" message. I have not done that yet,
>> though, because I'm not a 100% sure that there aren't any other
>> consequences. (It would be nice to see a notification of a message
>> encrypted for another session, and have the ability to drop the message
>> itself, since that has no value to us.)
>>
>> 2. I have seen a mismatching padlock icon, compared to the actual
>> session and the sessions in the "Secure chat" menu. The sessions listed
>> in "Secure chat" menu have always been accurate AFAICT. I have not been
>> able to reproduce it reliably though -- and I'm starting to doubt
>> whether session selection isn't the culprit.
>>
>> 3. About encryption-state mismatches ...
>>
>> a) I have NOT been able to get a session that was not actually
>> encrypted even though Jitsi says it IS encrypted. This in itself does
>> not prove that there isn't an issue, but it's not so easy to get into
>> that state by just clicking buttons (with or without thinking about it).
>>
>> b) I have been able to send unencrypted messages while an encrypted
>> session was set up. HOWEVER, Jitsi accurately showed an open padlock
>> when sending the message. The reason for this is that I had selected the
>> "root" XMPP session and sent the message via there. If you select this
>> session, Jitsi accurately shows an open padlock and messages are sent to
>> all session (I think). The chat client on the other side accurately
>> warns of an unencrypted message being received. If you then select one
>> specific XMPP session in the chat window, the padlock updates and indeed
>> messages are sent in encrypted form.
>>
>> As far as I have been able to determine this is all expected behaviour.
>> The root session cannot be OTR-encrypted, since it sends to (multiple?)
>> sessions and you would need to encrypt differently for every session. So
>> you need to select one specific session to send encrypted messages. (OTR
>> also stores a new session instance for each XMPP session.)
>>
>> 4. Given the behaviour above, it would be good to somehow warn or
>> prevent users from selecting the "root" session if multiple sessions are
>> known/active. This should prevent mistakes from being made.
>>
>> a) We may need to change the UI so that the "active" session (last
>> message) is selected automatically and users would always need to select
>> a specific session to switch. (And maybe we should not allow selecting
>> this top-most session.)
>>
>> ... after some more hours of fiddling around and lots of confusing
>> moments ...
>>
>> 5. I have now determined that XMPP message carbons can interfere with
>> correctly establishing an encrypted OTR sessions at one of two sides. I
>> am not clear on the details yet (and I am starting to believe that this
>> is a bug in the implementation), but this issue seems to arise at the
>> side where 2 sessions are active and carbons are enabled. (I see the
>> occasional OTR debug log entry about messages meant for another
session.)

Do you have a clue on why otr4j would finish in PLAINTEXT instead of
ENCRYPTED? The closest thing to an explanation I could think of was that
one of those carbons could have disrupted the process. Though, I'm not
familiar enough with the implementation to predict how otr4j would
respond to that. Also, I'm not sure why we would receive a carbon if
Jitsi is the only one sending on that channel a.t.m. (Or maybe the other
client responds to the authn. verification messages?)

>>
>> a) The result is an encrypted OTR session that IS established for the
>> non-problematic side (account with only a single XMPP session). The
>> sessions is established fully, and it can send encrypted messages. The
>> other side (2 active XMPP sessions) eventually decides to go with
>> plaintext and does not expose the encrypted session, even though it is
>> established. It is established because it can decrypt any received
>> encrypted messages, however ask the OTR Session-instance for its
>> SessionStatus and it will return PLAINTEXT. Send a message from that
>> side and it will send a plain text message (not encrypted). NOTE that
>> the padlock icon consistently shows an accurate state.
>>
>> 6. Further more, a small issue which may not actually be a problem. I
>> note this here for reference as it may only ever occur if you delay the
>> process by debugging (stepping through code): In the OTR plugin, if the
>> timeout-scheduler isn't cancelled in time, it will set a "timeout" state
>> which is then used and hides the true state of the OTR Session instance.
>>
>> Reproduction recipe for 5.:
>> 1. Start some other chat client. Log in the account with server support
>> message carbons, e.g. @jit.si. This is going to be the shared account.
>> 2. Start Jitsi. Log in with same account as in 1. Make sure message
>> carbons are enabled.
>> Using Jitsi, log in with another XMPP account.
>>
>> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and other client
>> - with message carbons, 1 solely for Jitsi.
>>
>> 3. Use client from 1. initiate OTR-encrypted session with 2. using
>> @jit.si account
>> 4. Using client from 1. send message to other XMPP account.
>> 5. Jitsi popup shows that it received a message. Click popup to view
>> message. Notice that OTR session is established.
>> 6. In Jitsi, select the other session for this account (@jit.si) that
is
>> available (which accidentally is the Jitsi client's XMPP session)
>> 7. Initiate OTR-encrypted session between the 2 accounts, both in Jitsi.
>>
>> -- Notice that session correctly establishes at initiating side, which
>> is the 1-session XMPP account solely in use by Jitsi.
>>
>> 9. Send a message over this newly instantiated OTR session.
>> 10. Popup shows for newly received message, click and it opens a second
>> tab showing the message received on the shared @jit.si account.
>>
>> -- Notice now that *that* account's OTR-encrypted session was not
>> recognized. The padlock is open. Sending messages now will send them as
>> plain text. However, it did just receive the encrypted message and
>> decrypted it successfully.

Let me know if the repro recipe is not clear enough. It's kind of a
complicated set up and this is probably not the canonical recipe for
this issue.

Danny

>>
>> When enabling debug logging in OTR one notices that the messages are
>> indeed encrypted from the side showing the OTR-encrypted session, and
>> plain text for the other side.
>>
>> Disabling message carbons fixes the problem described above. (At least,
>> it does for me.)
>>
>>
>> Sorry for making this such a long post. To conclude: I have been trying
>> to get a feel for the state of OTR support in Jitsi. We already knew of
>> some issues with state mangement. I believe these findings may have
>> fine-tuned this issue a bit. For now I do not see any big problems,
>> especially since the UI always showed an accurate state. Confusion is
>> mostly caused by XMPP's message carbons together with multiple active
>> sessions, which also makes the issues local to the XMPP protocol. The
>> confusion is focused on using the UI, as OTR seems to do the right thing
>> in the background. EXCEPT for this one issue described above where the
>> OTR-encrypted session should have been established at both sides. But
>> even then, Jitsi showed the correct state as the results were
accordingly.
>>
>> So, if you rely on OTR, make sure that your XMPP accounts have message
>> carbons disabled. Then you should have a pretty smooth ride. (As far as
>> I can tell from these tests.)
>>
>> Danny
>>
>>
>>
>>
>> On 26-01-15 10:50, George Politis wrote:
>>>
>>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
>>>
>>>> Hi all,
>>>>
>>>> Quick follow-up. I haven't had as much time as I would've liked. I
have
>>>> found out the following things. (in line ...)
>>>>
>>>> On 23-01-15 21:34, Danny van Heumen wrote:
>>>>> Hi all,
>>>>>
>>>>> Because of recent remarks about OTR support in Jitsi, I've been
trying
>>>>> out some cases - all using XMPP as messaging protocol. These were
>>>>> all in
>>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts
also
>>>>> logged in on Pidgin.
>>>>>
>>>>> For now, here's what I've found.
>>>>>
>>>>> 1. When using multiple sessions, Jitsi doesn't seem to correctly
>>>>> distinguish and discard the messages-for-another-session. I quickly
>>>>> looked at the otr4j source and if I read it correctly, then the
message
>>>>> gets returned unchanged. (Only took a quick look, so may not be
>>>>> accurate.) In that case the Jitsi client will just show the
>>>>> base64(encrypted) content. ... at least in this test ... (So, send
from
>>>>> Jitsi client to Pidgin client, while Jitsi also connected to same
>>>>> account as Pidgin's is logged on to.)
>>>> It is just slightly different than I've stated above. It turns out
that
>>>> the 2nd session "listening in" (not in the malicious way) does not
have
>>>> an OTR session established. So, as a consequence this session receives
>>>> encrypted messages as if they were normal messages.
>>>>
>>>> This is likely not an issue in the OTR4J library, but rather in Jitsi
>>>> not including OTR4J, since it isn't enabled. I believe that if OTR4J
was
>>>> "in the loop" it would have handled this message. Maybe by dropping a
>>>> system message saying what is happening. Need to look into that
further.
>>>>
>>> There seems to be an issue here. You're talking about
>>> OtrTransformLayer:149, right? Where this code fragment is executed:
>>>
>>> f (!policy.getEnableManual()
>>> && sessionStatus != ScSessionStatus.ENCRYPTED
>>> && sessionStatus != ScSessionStatus.FINISHED)
>>> return evt;
>>>
>>>>> 2. Jitsi does not escape html, so when Pidgin receives the message it
>>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
>>>>> side. (Though javascript doesn't get executed :-P)
>>>> This one's a bit tricky. We receive a text message which is encrypted.
>>>> Once decrypted, we need to discover whether it is intended as HTML or
>>>> plain text. I'm not sure how another OTR-capable chat client makes
this
>>>> distinction, though looking at Pidgin's behaviour, I suspect they may
>>>> simply have assumed HTML. (Otherwise it wouldn't have been as simple
to
>>>> inject styling in the message sent to Pidgin client.)
>>> Other clients, like Miranda, have the exact same problem when they
>>> communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I
>>> suppose the messages that Pidgin is sending don't have their
>>> contentType set correctly, right? In that case, one way to fix it
>>> would be to assume HTML if the remote client is Pidgin.
>>>
>>>>> 3. Jitsi does not unescape html received from Pidgin. So "<dude>"
sent
>>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
>>>> Same as above.
>>>>> All should be fairly easy to fix.
>>>> I should've known better ... saying things like that :stuck_out_tongue:
>>>>
>>>>> (Assuming Pidgin is the one behaving
>>>>> as expected, which I am at the moment but will try to check before
>>>>> fixing things in Jitsi.)
>>>>>
>>>>> I haven't found a case yet where I get to see the actual HTML that is
>>>>> being sent as was described in
>>>>> http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if
I
>>>>> understand correctly that is ...)
>>>> Still same. I have only seen html entities up to now. If anyone knows
>>>> otherwise, plz let me know.
>>>>
>>>> As an added bonus I found out that plain text messages aren't
correctly
>>>> escaped in the notification popup, so at least that's fixed now :slight_smile:
>>>>
>>>> Danny
>>>>
>>>>> Danny
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dev mailing list
>>>>> dev@jitsi.org
>>>>> Unsubscribe instructions and other list options:
>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#12

Hello Danny,

Thank you for your findings but...

RESULT:

1. Plain text Master session. Will answer calls to getStatus(SessionID).
2. Fully established ENCRYPTED slave session. Will be reachable for
decrypting messages, however it is completely off-the-radar when querying
the status of a session.
3. Received messages get routed by their sender instance ID and arrive at
the slave session, get processed appropriately and hence get returned
decrypted to Jitsi.
4. Sent messages get sent in plain text according to the Master session's
status. Client at other end will received a plain text message even though
it has an OTR session established.

I still don't see anything wrong with this behaviour. Actually, I
implemented it that way so I'm glad it's still working :smiley:
You can use the icon in the left-down corner in order to switch between
carbons. When you do, the "active" carbon is going to change and you will
see that the padlock is closed. (Or at least it should work that way if I
remember correctly). Addionally, you may have an icon in the right-down
corner that switches between active slave sessions but I don't remember the
details for that one. So you might end up having to choose between a
combination of [carbon - otr session] from the two down corners in order to
send proper messages. I remember that I also put some logic so that Jitsi
can automacally switch between carbons (down-left icon) depending on the
received message. The idea was that if one receives a message from a
certain jid, the default carbon and thus the active otr slave session (used
to encrypt outgoing messages) is switched.

* Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be

possible, but should not be a problem. Given that the slave sessions are
about decrypting received messages. Sending encrypted messages wouldn't
be a problem, since the master session is ENCRYPTED. Also, the session
status reflects the status of the Master sessions which also sends, so
the status is accurate.

Also, again if I remember correctly, there is no way to have an ENCRYPTED
master session because master sessions delegate session initiation requests
to slave sessions.

I hope that helps.

Best regards,
Marin

···

On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

A quick addition ... I was thinking about which combinations are
possible for Master - Slave session combinations.

* Master session: PLAINTEXT + Slave session: ENCRYPTED -- possible as
this is the current problem.

* Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
possible, but should not be a problem. Given that the slave sessions are
about decrypting received messages. Sending encrypted messages wouldn't
be a problem, since the master session is ENCRYPTED. Also, the session
status reflects the status of the Master sessions which also sends, so
the status is accurate.

* Both PLAINTEXT shouldn't be an issue in any case, i.e. no encrypted
sessions established.

* Both ENCRYPTED: not sure if this makes sense, but in any case we would
sent an encrypted message. It might get delivered to the wrong address,
but it wouldn't unintentionally be sent PLAINTEXT, so not an issue(?)

Danny

On 25-02-15 23:43, Danny van Heumen wrote:
> Hi all,
>
> So, here's another follow up with what I found out yesterday. I think
> I may have an explanation of what happens. It's pretty interesting
> interplay of features, I think ...
>
> A FEW FACTS:
> * When message carbons are activated, the messages sent by one client
> are repeated to the other clients as message delivered events. (I'm
> quite sure, but please correct me if I'm wrong here ...)
> * Jitsi's OTR implementation does not process message delivered
> events. (The only exception to this is to check if a message is
> injected such that the user is not bothered with OTR interaction
> inside the client.)
> * I found out that the session status gets updated in another instance
> of SessionImpl than where the instance where we query for the current
> session status. This explains both:
>
> 1. Why the statuses deviate - between session establishment (in log
> messages) and session status querying, and
> 2. Why messages till get decrypted when received even though the
> status is PLAINTEXT.
>
> FLOW OF EVENTS: Here's where it gets interesting ...
>
> Say we have:
> * An account a@jit.si on server jit.si which supports message carbons.
> * An account b@gmail.com on server gmail.com which does not support
> message carbons.
> * Client A, a Jitsi client, with account a@jit.si - with message
> carbons enabled - and account b@gmail.com.
> * Client B, another client with account a@jit.si - without message
> carbons enabled.
>
> 1. We initiate an OTR session with client A to account b@gmail.com.
> This means that B sends the OTR v3 query message.
> -- a) client A receives the request on account b@gmail.com
> -- b) client A receives a carbon of the request on a@jit.si. This
> message isn't processed by otr4j, so effectively gets ignored.
>
> 2. Client A receives OTR v3 query message, answers with D-H commit
> message.
> -- a) client B receives the request on account a@jit.si.
> -- b) client A a@jit.si receives the message carbon and sets a master
> session for this sender instance id, however it does not expect the
> D-H commit message so does not respond.
>
> 3. Client A (a@jit.si) and client B (b@gmail.com) finish up OTR
> protocol and establish a secure session.
>
> Now Client A (b@gmail.com) wants to establish an OTR session with
> Client A (a@jit.si), so it sends initial OTR v3 query message.
>
> 4. Client A on b@gmail.com sends message to a@jit.si for client A
> (that is, that specific session id).
> -- a) Client A a@jit.si receives this message, however it contains a
> different sender instance id than the message before, so a slave
> session is established. The received message gets passed through to
> slave session. Slave session handles message.
>
> 5. Client A a@jit.si responds and continues establishing OTR encrypted
> session. Now Client A a@jit.si has 2 sessions available:
> * Master session: PLAINTEXT, received some OTR messages but nothing to
> establish a connection with.
> * Slave session: ENCRYPTED, did full processing of OTR session
> establishment and has a full, completed ENCRYPTED session.
>
> Now that an encrypted session is established, we call listeners to
> inform of a sessionStatusChanged(OtrContact). However, a call of
> getStatus(SessionID for OtrContact) will return the session status of
> the MASTER session, which is plain text, since it was based upon the
> message carbons.
>
> RESULT:
>
> 1. Plain text Master session. Will answer calls to getStatus(SessionID).
> 2. Fully established ENCRYPTED slave session. Will be reachable for
> decrypting messages, however it is completely off-the-radar when
> querying the status of a session.
> 3. Received messages get routed by their sender instance ID and arrive
> at the slave session, get processed appropriately and hence get
> returned decrypted to Jitsi.
> 4. Sent messages get sent in plain text according to the Master
> session's status. Client at other end will received a plain text
> message even though it has an OTR session established.
>
> I hope this makes sense. It is a bit late, so please be critical and
> check if everything makes sense. I can clarify if there are any
> questions. (Or replay the problem and/or recheck the logging.)
>
> Assuming the above is correct, this would also explain my earlier
> comment regarding disabling message carbons. This would indeed prevent
> establishing the early Master session, hence when the OTR session is
> deliberately initiated, this would become the Master session and one
> would indeed get the correct Session Status when queried via
> getStatus(SessionID).
>
> So, if this correctly establishes the problem, I am quite interested
> in how we're going to solve this one. I haven't thought about this one
> yet ... :slight_smile:
>
> Regards,
> Danny
>
>
>
> On 22-02-15 21:18, Danny van Heumen wrote:
>> Okay, so it's time for an update on this topic ...
>>
>> @George: In case of TL;DR, could you check my commit, just to be sure?
>>
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
>> It's about removing the conditionals so any message reaches the otr4j
>> library, even if a secure session is not established yet. Basically what
>> you suggested before.
>> Also, can you explain why at SessionImpl:479 (call to
>> setSessionStatus(ENCRYPTED)) the called method resets auth (AuthContext)
>> to setIsSecure(false), while the passed parameter is
>> SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
>> contradictory.)
>>
>> I've been playing around with the whole OTR UI and plugin to see what I
>> could discover apart from the stuff we already know. I have been playing
>> around for a few hours and this is a quick report of what I've been able
>> to discover.
>>
>> 1. The raw OTR-encrypted message I received as described below, is due
>> to XMPP Carbons being enabled. We receive the message sent from another
>> client (same account) and we subscribed to carbon copies, so we receive
>> a carbon of the raw message. This particular message flow is not hooked
>> into otr4j, so it gets shown as a plain old message. (@fippo: Thanks for
>> pointing out the carbons!)
>>
>> a) I'm thinking of whether or not we *can* hook that into otr4j. Maybe
>> we can process this as a "received" message. I have not done that yet,
>> though, because I'm not a 100% sure that there aren't any other
>> consequences. (It would be nice to see a notification of a message
>> encrypted for another session, and have the ability to drop the message
>> itself, since that has no value to us.)
>>
>> 2. I have seen a mismatching padlock icon, compared to the actual
>> session and the sessions in the "Secure chat" menu. The sessions listed
>> in "Secure chat" menu have always been accurate AFAICT. I have not been
>> able to reproduce it reliably though -- and I'm starting to doubt
>> whether session selection isn't the culprit.
>>
>> 3. About encryption-state mismatches ...
>>
>> a) I have NOT been able to get a session that was not actually
>> encrypted even though Jitsi says it IS encrypted. This in itself does
>> not prove that there isn't an issue, but it's not so easy to get into
>> that state by just clicking buttons (with or without thinking about it).
>>
>> b) I have been able to send unencrypted messages while an encrypted
>> session was set up. HOWEVER, Jitsi accurately showed an open padlock
>> when sending the message. The reason for this is that I had selected the
>> "root" XMPP session and sent the message via there. If you select this
>> session, Jitsi accurately shows an open padlock and messages are sent to
>> all session (I think). The chat client on the other side accurately
>> warns of an unencrypted message being received. If you then select one
>> specific XMPP session in the chat window, the padlock updates and indeed
>> messages are sent in encrypted form.
>>
>> As far as I have been able to determine this is all expected behaviour.
>> The root session cannot be OTR-encrypted, since it sends to (multiple?)
>> sessions and you would need to encrypt differently for every session. So
>> you need to select one specific session to send encrypted messages. (OTR
>> also stores a new session instance for each XMPP session.)
>>
>> 4. Given the behaviour above, it would be good to somehow warn or
>> prevent users from selecting the "root" session if multiple sessions are
>> known/active. This should prevent mistakes from being made.
>>
>> a) We may need to change the UI so that the "active" session (last
>> message) is selected automatically and users would always need to select
>> a specific session to switch. (And maybe we should not allow selecting
>> this top-most session.)
>>
>> ... after some more hours of fiddling around and lots of confusing
>> moments ...
>>
>> 5. I have now determined that XMPP message carbons can interfere with
>> correctly establishing an encrypted OTR sessions at one of two sides. I
>> am not clear on the details yet (and I am starting to believe that this
>> is a bug in the implementation), but this issue seems to arise at the
>> side where 2 sessions are active and carbons are enabled. (I see the
>> occasional OTR debug log entry about messages meant for another
session.)
>>
>> a) The result is an encrypted OTR session that IS established for the
>> non-problematic side (account with only a single XMPP session). The
>> sessions is established fully, and it can send encrypted messages. The
>> other side (2 active XMPP sessions) eventually decides to go with
>> plaintext and does not expose the encrypted session, even though it is
>> established. It is established because it can decrypt any received
>> encrypted messages, however ask the OTR Session-instance for its
>> SessionStatus and it will return PLAINTEXT. Send a message from that
>> side and it will send a plain text message (not encrypted). NOTE that
>> the padlock icon consistently shows an accurate state.
>>
>> 6. Further more, a small issue which may not actually be a problem. I
>> note this here for reference as it may only ever occur if you delay the
>> process by debugging (stepping through code): In the OTR plugin, if the
>> timeout-scheduler isn't cancelled in time, it will set a "timeout" state
>> which is then used and hides the true state of the OTR Session instance.
>>
>> Reproduction recipe for 5.:
>> 1. Start some other chat client. Log in the account with server support
>> message carbons, e.g. @jit.si. This is going to be the shared account.
>> 2. Start Jitsi. Log in with same account as in 1. Make sure message
>> carbons are enabled.
>> Using Jitsi, log in with another XMPP account.
>>
>> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and other client
>> - with message carbons, 1 solely for Jitsi.
>>
>> 3. Use client from 1. initiate OTR-encrypted session with 2. using
>> @jit.si account
>> 4. Using client from 1. send message to other XMPP account.
>> 5. Jitsi popup shows that it received a message. Click popup to view
>> message. Notice that OTR session is established.
>> 6. In Jitsi, select the other session for this account (@jit.si) that
is
>> available (which accidentally is the Jitsi client's XMPP session)
>> 7. Initiate OTR-encrypted session between the 2 accounts, both in Jitsi.
>>
>> -- Notice that session correctly establishes at initiating side, which
>> is the 1-session XMPP account solely in use by Jitsi.
>>
>> 9. Send a message over this newly instantiated OTR session.
>> 10. Popup shows for newly received message, click and it opens a second
>> tab showing the message received on the shared @jit.si account.
>>
>> -- Notice now that *that* account's OTR-encrypted session was not
>> recognized. The padlock is open. Sending messages now will send them as
>> plain text. However, it did just receive the encrypted message and
>> decrypted it successfully.
>>
>> When enabling debug logging in OTR one notices that the messages are
>> indeed encrypted from the side showing the OTR-encrypted session, and
>> plain text for the other side.
>>
>> Disabling message carbons fixes the problem described above. (At least,
>> it does for me.)
>>
>>
>> Sorry for making this such a long post. To conclude: I have been trying
>> to get a feel for the state of OTR support in Jitsi. We already knew of
>> some issues with state mangement. I believe these findings may have
>> fine-tuned this issue a bit. For now I do not see any big problems,
>> especially since the UI always showed an accurate state. Confusion is
>> mostly caused by XMPP's message carbons together with multiple active
>> sessions, which also makes the issues local to the XMPP protocol. The
>> confusion is focused on using the UI, as OTR seems to do the right thing
>> in the background. EXCEPT for this one issue described above where the
>> OTR-encrypted session should have been established at both sides. But
>> even then, Jitsi showed the correct state as the results were
accordingly.
>>
>> So, if you rely on OTR, make sure that your XMPP accounts have message
>> carbons disabled. Then you should have a pretty smooth ride. (As far as
>> I can tell from these tests.)
>>
>> Danny
>>
>>
>>
>>
>> On 26-01-15 10:50, George Politis wrote:
>>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
>>>
>>>> Hi all,
>>>>
>>>> Quick follow-up. I haven't had as much time as I would've liked. I
have
>>>> found out the following things. (in line ...)
>>>>
>>>> On 23-01-15 21:34, Danny van Heumen wrote:
>>>>> Hi all,
>>>>>
>>>>> Because of recent remarks about OTR support in Jitsi, I've been
trying
>>>>> out some cases - all using XMPP as messaging protocol. These were
>>>>> all in
>>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the accounts
also
>>>>> logged in on Pidgin.
>>>>>
>>>>> For now, here's what I've found.
>>>>>
>>>>> 1. When using multiple sessions, Jitsi doesn't seem to correctly
>>>>> distinguish and discard the messages-for-another-session. I quickly
>>>>> looked at the otr4j source and if I read it correctly, then the
message
>>>>> gets returned unchanged. (Only took a quick look, so may not be
>>>>> accurate.) In that case the Jitsi client will just show the
>>>>> base64(encrypted) content. ... at least in this test ... (So, send
from
>>>>> Jitsi client to Pidgin client, while Jitsi also connected to same
>>>>> account as Pidgin's is logged on to.)
>>>> It is just slightly different than I've stated above. It turns out
that
>>>> the 2nd session "listening in" (not in the malicious way) does not
have
>>>> an OTR session established. So, as a consequence this session receives
>>>> encrypted messages as if they were normal messages.
>>>>
>>>> This is likely not an issue in the OTR4J library, but rather in Jitsi
>>>> not including OTR4J, since it isn't enabled. I believe that if OTR4J
was
>>>> "in the loop" it would have handled this message. Maybe by dropping a
>>>> system message saying what is happening. Need to look into that
further.
>>>>
>>> There seems to be an issue here. You're talking about
>>> OtrTransformLayer:149, right? Where this code fragment is executed:
>>>
>>> f (!policy.getEnableManual()
>>> && sessionStatus != ScSessionStatus.ENCRYPTED
>>> && sessionStatus != ScSessionStatus.FINISHED)
>>> return evt;
>>>
>>>>> 2. Jitsi does not escape html, so when Pidgin receives the message it
>>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold at Pidgin
>>>>> side. (Though javascript doesn't get executed :-P)
>>>> This one's a bit tricky. We receive a text message which is encrypted.
>>>> Once decrypted, we need to discover whether it is intended as HTML or
>>>> plain text. I'm not sure how another OTR-capable chat client makes
this
>>>> distinction, though looking at Pidgin's behaviour, I suspect they may
>>>> simply have assumed HTML. (Otherwise it wouldn't have been as simple
to
>>>> inject styling in the message sent to Pidgin client.)
>>> Other clients, like Miranda, have the exact same problem when they
>>> communicate with Pidgin (https://developer.pidgin.im/ticket/8453). I
>>> suppose the messages that Pidgin is sending don't have their
>>> contentType set correctly, right? In that case, one way to fix it
>>> would be to assume HTML if the remote client is Pidgin.
>>>
>>>>> 3. Jitsi does not unescape html received from Pidgin. So "<dude>"
sent
>>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
>>>> Same as above.
>>>>> All should be fairly easy to fix.
>>>> I should've known better ... saying things like that :stuck_out_tongue:
>>>>
>>>>> (Assuming Pidgin is the one behaving
>>>>> as expected, which I am at the moment but will try to check before
>>>>> fixing things in Jitsi.)
>>>>>
>>>>> I haven't found a case yet where I get to see the actual HTML that is
>>>>> being sent as was described in
>>>>> http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if
I
>>>>> understand correctly that is ...)
>>>> Still same. I have only seen html entities up to now. If anyone knows
>>>> otherwise, plz let me know.
>>>>
>>>> As an added bonus I found out that plain text messages aren't
correctly
>>>> escaped in the notification popup, so at least that's fixed now :slight_smile:
>>>>
>>>> Danny
>>>>
>>>>> Danny
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dev mailing list
>>>>> dev@jitsi.org
>>>>> Unsubscribe instructions and other list options:
>>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev@jitsi.org
>>>> Unsubscribe instructions and other list options:
>>>> http://lists.jitsi.org/mailman/listinfo/dev
>>> _______________________________________________
>>> dev mailing list
>>> dev@jitsi.org
>>> Unsubscribe instructions and other list options:
>>> http://lists.jitsi.org/mailman/listinfo/dev
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#13

Hi Marin,

Hello all,

Sorry to join so late but I've been quite busy recently :slight_smile:

    1. When using multiple sessions, Jitsi doesn't seem to correctly
    distinguish and discard the messages-for-another-session. I quickly
    looked at the otr4j source and if I read it correctly, then the
    message
    gets returned unchanged. (Only took a quick look, so may not be
    accurate.) In that case the Jitsi client will just show the
    base64(encrypted) content. ... at least in this test ... (So, send
    from
    Jitsi client to Pidgin client, while Jitsi also connected to same
    account as Pidgin's is logged on to.)

First, just to make sure that we're on the same page - what are
message carbons used for? I'm not very familiar with the XMPP protocol
but I took a look at XEP-0280 and as far as I understood it is an
extension that enables clients to send xmpp messages to the bare jid
of a contact. The contact then will receive these messages on all of
his devices if the server supports carbons. Did I get this right?

I'm not a 100% sure, as I have little understanding of XMPP internals,
but as I read it, it's basically a CC (as in email) to all other clients
connected with the same account. (If the server supports message
carbons.) So when I am having a conversation using my mobile phone and
later switch to my desktop client, I will have received the message sent
by phone too. (So, in case of OTR I will receive the messages from
another client doing OTR session establishment or SMP authentication.)

If that's the case then carbons is exactly what OTR v 3 was designed
to deal with:

      * Both fragmented and unfragmented messages contain sender and
        recipient instance tags. This avoids an issue on IM networks
        that always relay all messages to all sessions of a client who
        is logged in multiple times. In this situation, OTR clients
        can attempt to establish an OTR session indefinitely if there
        are interleaving messages from each of the sessions.

What that means is that every OTR message is marked with an Instance
Tag. So if I per say receive an OTR encrypted message on my laptop
with an instance tag that is different than I expected, then it is
meant for another device of mine - my phone probably, and I will
discard it (and print message meant for another session on my laptop).
But since carbons are enabled, my phone should've received the message
too and decrypted it successfully. So these "message for another
session" logs are something completely normal when carbons are enabled
and I'm logged on multiple devices.

We're on the same page here. I too think that this shouldn't be a
problem at all.

I've just did a simple test on my local machine with 4 jitsi clients
(2 users logged in 2 times) and tried to exchange some messages using
the bare jid. Everything seemed to work smoothly. Or are you
experiencing some other behaviour?

Basically, when I follow the recipe I described before, I end up with
OTR in the state PLAINTEXT even though the AuthContext instance has
getIsSecure() set to true for a short while, i.e. before being reset.

That's basically where I left off. It took me a while to grasp some
determinism at all, and finally found out that everything works fine
when I disable carbons. (Issues comes back when I re-enable carbons.)

Furthermore, looking at the otr4j logging, it looks like everything's
fine up to the state change and then it turns out it is still at/again
at PLAINTEXT.
As a result:
- For client that is sole user of account: OTR established + padlock
closed. (And indeed sends encrypted messages)
- For client that is one of 2 users of (other) account: OTR not
established + padlock open (and indeed sends plain text messages)

The asymmetry is a dead give-away IMO :stuck_out_tongue:

Danny

···

On 24-02-15 12:52, Marin Dzhigarov wrote:

Best regards,
Marin

On Tue, Feb 24, 2015 at 1:31 AM, Danny van Heumen > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi George,

    My last message was mainly a record of what I've been trying to do and
    what my conclusions were based on the findings then.

    The reason for this is partly because of messages on the mailing list
    saying that OTR doesn't work for people. For now, I have not
    encountered
    those big "game changing" issues, but I did find some smaller ones
    that
    could cause confusion.

    There is this one obvious issue. I'm planning to dive somewhat deeper
    into it, because I think I'm right on track for that one.
    More below ...

    On 23-02-15 14:52, George Politis wrote:
    > Hey Danny!
    >
    > On 22 Feb 2015, at 21:18, Danny van Heumen wrote:
    >
    >> Okay, so it's time for an update on this topic ...
    >>
    >> @George: In case of TL;DR, could you check my commit, just to
    be sure?
    >>
    https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
    >> It's about removing the conditionals so any message reaches the
    otr4j
    >> library, even if a secure session is not established yet.
    Basically what
    >> you suggested before.
    > I checked the commit and I agree with it. Thanks very much for
    fixing the issue!
    >
    >> Also, can you explain why at SessionImpl:479 (call to
    >> setSessionStatus(ENCRYPTED)) the called method resets auth
    (AuthContext)
    >> to setIsSecure(false), while the passed parameter is
    >> SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
    >> contradictory.)
    >>
    > The idea is that once the session goes to encrypted we forget
    everything about the authentication context.
    Ah right, I figured it was either that or a bug. Glad it is
    intentional.

    >
    >> I've been playing around with the whole OTR UI and plugin to
    see what I
    >> could discover apart from the stuff we already know. I have
    been playing
    >> around for a few hours and this is a quick report of what I've
    been able
    >> to discover.
    >>
    > This is hard work and lots of time, thank you very much Danny
    for doing it! I'll have a much closer look at all the issues you
    describe tonight.
    >
    > In the meantime I believe we should open a few issues about the
    OTR plugin in our trac. I'd actually prefer GH but I think we have
    disabled the issues module for the Jitsi project. I'm going to do
    that tonight.
    /me 2, +1 for GH, if possible.

    >
    >> 1. The raw OTR-encrypted message I received as described below,
    is due
    >> to XMPP Carbons being enabled. We receive the message sent from
    another
    >> client (same account) and we subscribed to carbon copies, so we
    receive
    >> a carbon of the raw message. This particular message flow is
    not hooked
    >> into otr4j, so it gets shown as a plain old message. (@fippo:
    Thanks for
    >> pointing out the carbons!)
    >>
    >> a) I'm thinking of whether or not we *can* hook that into
    otr4j. Maybe
    >> we can process this as a "received" message. I have not done
    that yet,
    >> though, because I'm not a 100% sure that there aren't any other
    >> consequences. (It would be nice to see a notification of a message
    >> encrypted for another session, and have the ability to drop the
    message
    >> itself, since that has no value to us.)
    >>
    >> 2. I have seen a mismatching padlock icon, compared to the actual
    >> session and the sessions in the "Secure chat" menu. The
    sessions listed
    >> in "Secure chat" menu have always been accurate AFAICT. I have
    not been
    >> able to reproduce it reliably though -- and I'm starting to doubt
    >> whether session selection isn't the culprit.
    >>
    >> 3. About encryption-state mismatches ...
    >>
    >> a) I have NOT been able to get a session that was not actually
    >> encrypted even though Jitsi says it IS encrypted. This in
    itself does
    >> not prove that there isn't an issue, but it's not so easy to
    get into
    >> that state by just clicking buttons (with or without thinking
    about it).
    >>
    >> b) I have been able to send unencrypted messages while an encrypted
    >> session was set up. HOWEVER, Jitsi accurately showed an open
    padlock
    >> when sending the message. The reason for this is that I had
    selected the
    >> "root" XMPP session and sent the message via there. If you
    select this
    >> session, Jitsi accurately shows an open padlock and messages
    are sent to
    >> all session (I think). The chat client on the other side accurately
    >> warns of an unencrypted message being received. If you then
    select one
    >> specific XMPP session in the chat window, the padlock updates
    and indeed
    >> messages are sent in encrypted form.
    >>
    >> As far as I have been able to determine this is all expected
    behaviour.
    >> The root session cannot be OTR-encrypted, since it sends to
    (multiple?)
    >> sessions and you would need to encrypt differently for every
    session. So
    >> you need to select one specific session to send encrypted
    messages. (OTR
    >> also stores a new session instance for each XMPP session.)
    >>
    >> 4. Given the behaviour above, it would be good to somehow warn or
    >> prevent users from selecting the "root" session if multiple
    sessions are
    >> known/active. This should prevent mistakes from being made.
    >>
    >> a) We may need to change the UI so that the "active" session (last
    >> message) is selected automatically and users would always need
    to select
    >> a specific session to switch. (And maybe we should not allow
    selecting
    >> this top-most session.)
    >>
    >> ... after some more hours of fiddling around and lots of confusing
    >> moments ...
    >>
    >> 5. I have now determined that XMPP message carbons can
    interfere with
    >> correctly establishing an encrypted OTR sessions at one of two
    sides. I
    >> am not clear on the details yet (and I am starting to believe
    that this
    >> is a bug in the implementation), but this issue seems to arise
    at the
    >> side where 2 sessions are active and carbons are enabled. (I
    see the
    >> occasional OTR debug log entry about messages meant for another
    session.)

    Do you have a clue on why otr4j would finish in PLAINTEXT instead of
    ENCRYPTED? The closest thing to an explanation I could think of
    was that
    one of those carbons could have disrupted the process. Though, I'm not
    familiar enough with the implementation to predict how otr4j would
    respond to that. Also, I'm not sure why we would receive a carbon if
    Jitsi is the only one sending on that channel a.t.m. (Or maybe the
    other
    client responds to the authn. verification messages?)

    >>
    >> a) The result is an encrypted OTR session that IS established
    for the
    >> non-problematic side (account with only a single XMPP session). The
    >> sessions is established fully, and it can send encrypted
    messages. The
    >> other side (2 active XMPP sessions) eventually decides to go with
    >> plaintext and does not expose the encrypted session, even
    though it is
    >> established. It is established because it can decrypt any received
    >> encrypted messages, however ask the OTR Session-instance for its
    >> SessionStatus and it will return PLAINTEXT. Send a message from
    that
    >> side and it will send a plain text message (not encrypted).
    NOTE that
    >> the padlock icon consistently shows an accurate state.
    >>
    >> 6. Further more, a small issue which may not actually be a
    problem. I
    >> note this here for reference as it may only ever occur if you
    delay the
    >> process by debugging (stepping through code): In the OTR
    plugin, if the
    >> timeout-scheduler isn't cancelled in time, it will set a
    "timeout" state
    >> which is then used and hides the true state of the OTR Session
    instance.
    >>
    >> Reproduction recipe for 5.:
    >> 1. Start some other chat client. Log in the account with server
    support
    >> message carbons, e.g. @jit.si <http://jit.si>. This is going to
    be the shared account.
    >> 2. Start Jitsi. Log in with same account as in 1. Make sure message
    >> carbons are enabled.
    >> Using Jitsi, log in with another XMPP account.
    >>
    >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
    other client
    >> - with message carbons, 1 solely for Jitsi.
    >>
    >> 3. Use client from 1. initiate OTR-encrypted session with 2. using
    >> @jit.si <http://jit.si> account
    >> 4. Using client from 1. send message to other XMPP account.
    >> 5. Jitsi popup shows that it received a message. Click popup to
    view
    >> message. Notice that OTR session is established.
    >> 6. In Jitsi, select the other session for this account (@jit.si
    <http://jit.si>) that is
    >> available (which accidentally is the Jitsi client's XMPP session)
    >> 7. Initiate OTR-encrypted session between the 2 accounts, both
    in Jitsi.
    >>
    >> -- Notice that session correctly establishes at initiating
    side, which
    >> is the 1-session XMPP account solely in use by Jitsi.
    >>
    >> 9. Send a message over this newly instantiated OTR session.
    >> 10. Popup shows for newly received message, click and it opens
    a second
    >> tab showing the message received on the shared @jit.si
    <http://jit.si> account.
    >>
    >> -- Notice now that *that* account's OTR-encrypted session was not
    >> recognized. The padlock is open. Sending messages now will send
    them as
    >> plain text. However, it did just receive the encrypted message and
    >> decrypted it successfully.

    Let me know if the repro recipe is not clear enough. It's kind of a
    complicated set up and this is probably not the canonical recipe for
    this issue.

    Danny

    >>
    >> When enabling debug logging in OTR one notices that the
    messages are
    >> indeed encrypted from the side showing the OTR-encrypted
    session, and
    >> plain text for the other side.
    >>
    >> Disabling message carbons fixes the problem described above.
    (At least,
    >> it does for me.)
    >>
    >>
    >> Sorry for making this such a long post. To conclude: I have
    been trying
    >> to get a feel for the state of OTR support in Jitsi. We already
    knew of
    >> some issues with state mangement. I believe these findings may have
    >> fine-tuned this issue a bit. For now I do not see any big problems,
    >> especially since the UI always showed an accurate state.
    Confusion is
    >> mostly caused by XMPP's message carbons together with multiple
    active
    >> sessions, which also makes the issues local to the XMPP
    protocol. The
    >> confusion is focused on using the UI, as OTR seems to do the
    right thing
    >> in the background. EXCEPT for this one issue described above
    where the
    >> OTR-encrypted session should have been established at both
    sides. But
    >> even then, Jitsi showed the correct state as the results were
    accordingly.
    >>
    >> So, if you rely on OTR, make sure that your XMPP accounts have
    message
    >> carbons disabled. Then you should have a pretty smooth ride.
    (As far as
    >> I can tell from these tests.)
    >>
    >> Danny
    >>
    >>
    >>
    >>
    >> On 26-01-15 10:50, George Politis wrote:
    >>>
    >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
    >>>
    >>>> Hi all,
    >>>>
    >>>> Quick follow-up. I haven't had as much time as I would've
    liked. I have
    >>>> found out the following things. (in line ...)
    >>>>
    >>>> On 23-01-15 21:34, Danny van Heumen wrote:
    >>>>> Hi all,
    >>>>>
    >>>>> Because of recent remarks about OTR support in Jitsi, I've
    been trying
    >>>>> out some cases - all using XMPP as messaging protocol. These
    were
    >>>>> all in
    >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
    accounts also
    >>>>> logged in on Pidgin.
    >>>>>
    >>>>> For now, here's what I've found.
    >>>>>
    >>>>> 1. When using multiple sessions, Jitsi doesn't seem to correctly
    >>>>> distinguish and discard the messages-for-another-session. I
    quickly
    >>>>> looked at the otr4j source and if I read it correctly, then
    the message
    >>>>> gets returned unchanged. (Only took a quick look, so may not be
    >>>>> accurate.) In that case the Jitsi client will just show the
    >>>>> base64(encrypted) content. ... at least in this test ...
    (So, send from
    >>>>> Jitsi client to Pidgin client, while Jitsi also connected to
    same
    >>>>> account as Pidgin's is logged on to.)
    >>>> It is just slightly different than I've stated above. It
    turns out that
    >>>> the 2nd session "listening in" (not in the malicious way)
    does not have
    >>>> an OTR session established. So, as a consequence this session
    receives
    >>>> encrypted messages as if they were normal messages.
    >>>>
    >>>> This is likely not an issue in the OTR4J library, but rather
    in Jitsi
    >>>> not including OTR4J, since it isn't enabled. I believe that
    if OTR4J was
    >>>> "in the loop" it would have handled this message. Maybe by
    dropping a
    >>>> system message saying what is happening. Need to look into
    that further.
    >>>>
    >>> There seems to be an issue here. You're talking about
    >>> OtrTransformLayer:149, right? Where this code fragment is
    executed:
    >>>
    >>> f (!policy.getEnableManual()
    >>> && sessionStatus != ScSessionStatus.ENCRYPTED
    >>> && sessionStatus != ScSessionStatus.FINISHED)
    >>> return evt;
    >>>
    >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
    message it
    >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
    at Pidgin
    >>>>> side. (Though javascript doesn't get executed :-P)
    >>>> This one's a bit tricky. We receive a text message which is
    encrypted.
    >>>> Once decrypted, we need to discover whether it is intended as
    HTML or
    >>>> plain text. I'm not sure how another OTR-capable chat client
    makes this
    >>>> distinction, though looking at Pidgin's behaviour, I suspect
    they may
    >>>> simply have assumed HTML. (Otherwise it wouldn't have been as
    simple to
    >>>> inject styling in the message sent to Pidgin client.)
    >>> Other clients, like Miranda, have the exact same problem when they
    >>> communicate with Pidgin
    (https://developer.pidgin.im/ticket/8453). I
    >>> suppose the messages that Pidgin is sending don't have their
    >>> contentType set correctly, right? In that case, one way to fix it
    >>> would be to assume HTML if the remote client is Pidgin.
    >>>
    >>>>> 3. Jitsi does not unescape html received from Pidgin. So
    "<dude>" sent
    >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
    >>>> Same as above.
    >>>>> All should be fairly easy to fix.
    >>>> I should've known better ... saying things like that :stuck_out_tongue:
    >>>>
    >>>>> (Assuming Pidgin is the one behaving
    >>>>> as expected, which I am at the moment but will try to check
    before
    >>>>> fixing things in Jitsi.)
    >>>>>
    >>>>> I haven't found a case yet where I get to see the actual
    HTML that is
    >>>>> being sent as was described in
    >>>>>
    http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
    >>>>> understand correctly that is ...)
    >>>> Still same. I have only seen html entities up to now. If
    anyone knows
    >>>> otherwise, plz let me know.
    >>>>
    >>>> As an added bonus I found out that plain text messages aren't
    correctly
    >>>> escaped in the notification popup, so at least that's fixed
    now :slight_smile:
    >>>>
    >>>> Danny
    >>>>
    >>>>> Danny
    >>>>>
    >>>>>
    >>>>>
    >>>>> _______________________________________________
    >>>>> dev mailing list
    >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
    >>>>> Unsubscribe instructions and other list options:
    >>>>> http://lists.jitsi.org/mailman/listinfo/dev
    >>>>
    >>>> _______________________________________________
    >>>> dev mailing list
    >>>> dev@jitsi.org <mailto:dev@jitsi.org>
    >>>> Unsubscribe instructions and other list options:
    >>>> http://lists.jitsi.org/mailman/listinfo/dev
    >>> _______________________________________________
    >>> dev mailing list
    >>> dev@jitsi.org <mailto:dev@jitsi.org>
    >>> Unsubscribe instructions and other list options:
    >>> http://lists.jitsi.org/mailman/listinfo/dev

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#14

Hi Marin,

Thanks for your quite detailed response. I'll add my comments in-line.
Hopefully that clarifies what I think my issue is about.

Hello Danny,

Thank you for your findings but...

    RESULT:
    1. Plain text Master session. Will answer calls to
    getStatus(SessionID).
    2. Fully established ENCRYPTED slave session. Will be reachable
    for decrypting messages, however it is completely off-the-radar
    when querying the status of a session.
    3. Received messages get routed by their sender instance ID and
    arrive at the slave session, get processed appropriately and hence
    get returned decrypted to Jitsi.
    4. Sent messages get sent in plain text according to the Master
    session's status. Client at other end will received a plain text
    message even though it has an OTR session established.

I still don't see anything wrong with this behaviour. Actually, I
implemented it that way so I'm glad it's still working :smiley:
You can use the icon in the left-down corner in order to switch
between carbons. When you do, the "active" carbon is going to change
and you will see that the padlock is closed. (Or at least it should
work that way if I remember correctly).

So, when I'm talking about carbons, I'm referring to the actual messages
themselves being replicated to other clients of the same account. I am
assuming here that you mean the various "sessions", one session for each
of the logged in clients of that account, right?

So, after the session is established, I can indeed switch these sessions
using that drop down menu. None of the menu entries has a closed
padlock. (Again, if I send a message from the other side, it correctly
gets decrypted, so the OTR-session is still "encrypted".) Additionally,
the "Secure chat" menu shows a list of session, right? Also there, every
session has an open padlock.

Addionally, you may have an icon in the right-down corner that
switches between active slave sessions but I don't remember the
details for that one. So you might end up having to choose between a
combination of [carbon - otr session] from the two down corners in
order to send proper messages.

I have not found this right-bottom menu. Never seen it as far as I can
remember.

I think this might be related to my issue. As I understand it now, that
is what I can derive from your comments about the implementation, is
that there is supposed to be a menu for selecting slave sessions, like
you said. These slave sessions are for each of the different sender
instances encountered by otr4j. Going into the implementation, do I
understand correctly that the variable 'outgoingSession' contains an
instance of the available slave sessions that is selected as the
outgoing session? So, in other words, the outgoingSession variable
always contains an instance that is also found in the slaveSessions map?

If you are supposed to switch slave sessions manually, then the user
should be able to manually switch to the encrypted slave session. I
haven't seen this menu though, so that would explain a lot. I'm guessing
it does not do this automatically, e.g. after a new encrypted session is
established? ... I guess that would make sense, since it could frustrate
users trying to send a message.

I remember that I also put some logic so that Jitsi can automacally
switch between carbons (down-left icon) depending on the received
message. The idea was that if one receives a message from a certain
jid, the default carbon and thus the active otr slave session (used to
encrypt outgoing messages) is switched.

Correct, it switches ... although I think it stops switching if I select
this "root" (bare?) session. Could that be right?

    * Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
    possible, but should not be a problem. Given that the slave
    sessions are
    about decrypting received messages. Sending encrypted messages
    wouldn't
    be a problem, since the master session is ENCRYPTED. Also, the session
    status reflects the status of the Master sessions which also sends, so
    the status is accurate.

Also, again if I remember correctly, there is no way to have an
ENCRYPTED master session because master sessions delegate session
initiation requests to slave sessions.

Okay, sure, that makes sense. I did check logging I produce and it shows
that the same session instance that had old status 'plaintext' and new
status 'encrypted' has isMasterSession == true. So it seems that this is
possible.

I think I'm getting there ... given that it is possible to select slave
sessions, that would mean that the encrypted session can be looked up
manually. So in that case it could be merely a UI issue - and a lot of
confusing messages like "Private conversation with ... lost.",
immediately after establishing an encrypted session.

I'm going to look into getting these slave sessions to the surface ...

Danny

···

On 26-02-15 14:06, Marin Dzhigarov wrote:

I hope that helps.

Best regards,
Marin

On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:

    A quick addition ... I was thinking about which combinations are
    possible for Master - Slave session combinations.

    * Master session: PLAINTEXT + Slave session: ENCRYPTED -- possible as
    this is the current problem.

    * Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
    possible, but should not be a problem. Given that the slave
    sessions are
    about decrypting received messages. Sending encrypted messages
    wouldn't
    be a problem, since the master session is ENCRYPTED. Also, the session
    status reflects the status of the Master sessions which also sends, so
    the status is accurate.

    * Both PLAINTEXT shouldn't be an issue in any case, i.e. no encrypted
    sessions established.

    * Both ENCRYPTED: not sure if this makes sense, but in any case we
    would
    sent an encrypted message. It might get delivered to the wrong
    address,
    but it wouldn't unintentionally be sent PLAINTEXT, so not an issue(?)

    Danny

    On 25-02-15 23:43, Danny van Heumen wrote:
    > Hi all,
    >
    > So, here's another follow up with what I found out yesterday. I
    think
    > I may have an explanation of what happens. It's pretty interesting
    > interplay of features, I think ...
    >
    > A FEW FACTS:
    > * When message carbons are activated, the messages sent by one
    client
    > are repeated to the other clients as message delivered events. (I'm
    > quite sure, but please correct me if I'm wrong here ...)
    > * Jitsi's OTR implementation does not process message delivered
    > events. (The only exception to this is to check if a message is
    > injected such that the user is not bothered with OTR interaction
    > inside the client.)
    > * I found out that the session status gets updated in another
    instance
    > of SessionImpl than where the instance where we query for the
    current
    > session status. This explains both:
    >
    > 1. Why the statuses deviate - between session establishment (in log
    > messages) and session status querying, and
    > 2. Why messages till get decrypted when received even though the
    > status is PLAINTEXT.
    >
    > FLOW OF EVENTS: Here's where it gets interesting ...
    >
    > Say we have:
    > * An account a@jit.si <mailto:a@jit.si> on server jit.si
    <http://jit.si> which supports message carbons.
    > * An account b@gmail.com <mailto:b@gmail.com> on server
    gmail.com <http://gmail.com> which does not support
    > message carbons.
    > * Client A, a Jitsi client, with account a@jit.si
    <mailto:a@jit.si> - with message
    > carbons enabled - and account b@gmail.com <mailto:b@gmail.com>.
    > * Client B, another client with account a@jit.si
    <mailto:a@jit.si> - without message
    > carbons enabled.
    >
    > 1. We initiate an OTR session with client A to account
    b@gmail.com <mailto:b@gmail.com>.
    > This means that B sends the OTR v3 query message.
    > -- a) client A receives the request on account b@gmail.com
    <mailto:b@gmail.com>
    > -- b) client A receives a carbon of the request on a@jit.si
    <mailto:a@jit.si>. This
    > message isn't processed by otr4j, so effectively gets ignored.
    >
    > 2. Client A receives OTR v3 query message, answers with D-H commit
    > message.
    > -- a) client B receives the request on account a@jit.si
    <mailto:a@jit.si>.
    > -- b) client A a@jit.si <mailto:a@jit.si> receives the message
    carbon and sets a master
    > session for this sender instance id, however it does not expect the
    > D-H commit message so does not respond.
    >
    > 3. Client A (a@jit.si <mailto:a@jit.si>) and client B
    (b@gmail.com <mailto:b@gmail.com>) finish up OTR
    > protocol and establish a secure session.
    >
    > Now Client A (b@gmail.com <mailto:b@gmail.com>) wants to
    establish an OTR session with
    > Client A (a@jit.si <mailto:a@jit.si>), so it sends initial OTR
    v3 query message.
    >
    > 4. Client A on b@gmail.com <mailto:b@gmail.com> sends message to
    a@jit.si <mailto:a@jit.si> for client A
    > (that is, that specific session id).
    > -- a) Client A a@jit.si <mailto:a@jit.si> receives this message,
    however it contains a
    > different sender instance id than the message before, so a slave
    > session is established. The received message gets passed through to
    > slave session. Slave session handles message.
    >
    > 5. Client A a@jit.si <mailto:a@jit.si> responds and continues
    establishing OTR encrypted
    > session. Now Client A a@jit.si <mailto:a@jit.si> has 2 sessions
    available:
    > * Master session: PLAINTEXT, received some OTR messages but
    nothing to
    > establish a connection with.
    > * Slave session: ENCRYPTED, did full processing of OTR session
    > establishment and has a full, completed ENCRYPTED session.
    >
    > Now that an encrypted session is established, we call listeners to
    > inform of a sessionStatusChanged(OtrContact). However, a call of
    > getStatus(SessionID for OtrContact) will return the session
    status of
    > the MASTER session, which is plain text, since it was based upon the
    > message carbons.
    >
    > RESULT:
    >
    > 1. Plain text Master session. Will answer calls to
    getStatus(SessionID).
    > 2. Fully established ENCRYPTED slave session. Will be reachable for
    > decrypting messages, however it is completely off-the-radar when
    > querying the status of a session.
    > 3. Received messages get routed by their sender instance ID and
    arrive
    > at the slave session, get processed appropriately and hence get
    > returned decrypted to Jitsi.
    > 4. Sent messages get sent in plain text according to the Master
    > session's status. Client at other end will received a plain text
    > message even though it has an OTR session established.
    >
    > I hope this makes sense. It is a bit late, so please be critical and
    > check if everything makes sense. I can clarify if there are any
    > questions. (Or replay the problem and/or recheck the logging.)
    >
    > Assuming the above is correct, this would also explain my earlier
    > comment regarding disabling message carbons. This would indeed
    prevent
    > establishing the early Master session, hence when the OTR session is
    > deliberately initiated, this would become the Master session and one
    > would indeed get the correct Session Status when queried via
    > getStatus(SessionID).
    >
    > So, if this correctly establishes the problem, I am quite interested
    > in how we're going to solve this one. I haven't thought about
    this one
    > yet ... :slight_smile:
    >
    > Regards,
    > Danny
    >
    >
    >
    > On 22-02-15 21:18, Danny van Heumen wrote:
    >> Okay, so it's time for an update on this topic ...
    >>
    >> @George: In case of TL;DR, could you check my commit, just to
    be sure?
    >>
    https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
    >> It's about removing the conditionals so any message reaches the
    otr4j
    >> library, even if a secure session is not established yet.
    Basically what
    >> you suggested before.
    >> Also, can you explain why at SessionImpl:479 (call to
    >> setSessionStatus(ENCRYPTED)) the called method resets auth
    (AuthContext)
    >> to setIsSecure(false), while the passed parameter is
    >> SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
    >> contradictory.)
    >>
    >> I've been playing around with the whole OTR UI and plugin to
    see what I
    >> could discover apart from the stuff we already know. I have
    been playing
    >> around for a few hours and this is a quick report of what I've
    been able
    >> to discover.
    >>
    >> 1. The raw OTR-encrypted message I received as described below,
    is due
    >> to XMPP Carbons being enabled. We receive the message sent from
    another
    >> client (same account) and we subscribed to carbon copies, so we
    receive
    >> a carbon of the raw message. This particular message flow is
    not hooked
    >> into otr4j, so it gets shown as a plain old message. (@fippo:
    Thanks for
    >> pointing out the carbons!)
    >>
    >> a) I'm thinking of whether or not we *can* hook that into
    otr4j. Maybe
    >> we can process this as a "received" message. I have not done
    that yet,
    >> though, because I'm not a 100% sure that there aren't any other
    >> consequences. (It would be nice to see a notification of a message
    >> encrypted for another session, and have the ability to drop the
    message
    >> itself, since that has no value to us.)
    >>
    >> 2. I have seen a mismatching padlock icon, compared to the actual
    >> session and the sessions in the "Secure chat" menu. The
    sessions listed
    >> in "Secure chat" menu have always been accurate AFAICT. I have
    not been
    >> able to reproduce it reliably though -- and I'm starting to doubt
    >> whether session selection isn't the culprit.
    >>
    >> 3. About encryption-state mismatches ...
    >>
    >> a) I have NOT been able to get a session that was not actually
    >> encrypted even though Jitsi says it IS encrypted. This in
    itself does
    >> not prove that there isn't an issue, but it's not so easy to
    get into
    >> that state by just clicking buttons (with or without thinking
    about it).
    >>
    >> b) I have been able to send unencrypted messages while an
    encrypted
    >> session was set up. HOWEVER, Jitsi accurately showed an open
    padlock
    >> when sending the message. The reason for this is that I had
    selected the
    >> "root" XMPP session and sent the message via there. If you
    select this
    >> session, Jitsi accurately shows an open padlock and messages
    are sent to
    >> all session (I think). The chat client on the other side accurately
    >> warns of an unencrypted message being received. If you then
    select one
    >> specific XMPP session in the chat window, the padlock updates
    and indeed
    >> messages are sent in encrypted form.
    >>
    >> As far as I have been able to determine this is all expected
    behaviour.
    >> The root session cannot be OTR-encrypted, since it sends to
    (multiple?)
    >> sessions and you would need to encrypt differently for every
    session. So
    >> you need to select one specific session to send encrypted
    messages. (OTR
    >> also stores a new session instance for each XMPP session.)
    >>
    >> 4. Given the behaviour above, it would be good to somehow warn or
    >> prevent users from selecting the "root" session if multiple
    sessions are
    >> known/active. This should prevent mistakes from being made.
    >>
    >> a) We may need to change the UI so that the "active" session
    (last
    >> message) is selected automatically and users would always need
    to select
    >> a specific session to switch. (And maybe we should not allow
    selecting
    >> this top-most session.)
    >>
    >> ... after some more hours of fiddling around and lots of confusing
    >> moments ...
    >>
    >> 5. I have now determined that XMPP message carbons can
    interfere with
    >> correctly establishing an encrypted OTR sessions at one of two
    sides. I
    >> am not clear on the details yet (and I am starting to believe
    that this
    >> is a bug in the implementation), but this issue seems to arise
    at the
    >> side where 2 sessions are active and carbons are enabled. (I
    see the
    >> occasional OTR debug log entry about messages meant for another
    session.)
    >>
    >> a) The result is an encrypted OTR session that IS established
    for the
    >> non-problematic side (account with only a single XMPP session). The
    >> sessions is established fully, and it can send encrypted
    messages. The
    >> other side (2 active XMPP sessions) eventually decides to go with
    >> plaintext and does not expose the encrypted session, even
    though it is
    >> established. It is established because it can decrypt any received
    >> encrypted messages, however ask the OTR Session-instance for its
    >> SessionStatus and it will return PLAINTEXT. Send a message from
    that
    >> side and it will send a plain text message (not encrypted).
    NOTE that
    >> the padlock icon consistently shows an accurate state.
    >>
    >> 6. Further more, a small issue which may not actually be a
    problem. I
    >> note this here for reference as it may only ever occur if you
    delay the
    >> process by debugging (stepping through code): In the OTR
    plugin, if the
    >> timeout-scheduler isn't cancelled in time, it will set a
    "timeout" state
    >> which is then used and hides the true state of the OTR Session
    instance.
    >>
    >> Reproduction recipe for 5.:
    >> 1. Start some other chat client. Log in the account with server
    support
    >> message carbons, e.g. @jit.si <http://jit.si>. This is going to
    be the shared account.
    >> 2. Start Jitsi. Log in with same account as in 1. Make sure message
    >> carbons are enabled.
    >> Using Jitsi, log in with another XMPP account.
    >>
    >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
    other client
    >> - with message carbons, 1 solely for Jitsi.
    >>
    >> 3. Use client from 1. initiate OTR-encrypted session with 2. using
    >> @jit.si <http://jit.si> account
    >> 4. Using client from 1. send message to other XMPP account.
    >> 5. Jitsi popup shows that it received a message. Click popup to
    view
    >> message. Notice that OTR session is established.
    >> 6. In Jitsi, select the other session for this account (@jit.si
    <http://jit.si>) that is
    >> available (which accidentally is the Jitsi client's XMPP session)
    >> 7. Initiate OTR-encrypted session between the 2 accounts, both
    in Jitsi.
    >>
    >> -- Notice that session correctly establishes at initiating
    side, which
    >> is the 1-session XMPP account solely in use by Jitsi.
    >>
    >> 9. Send a message over this newly instantiated OTR session.
    >> 10. Popup shows for newly received message, click and it opens
    a second
    >> tab showing the message received on the shared @jit.si
    <http://jit.si> account.
    >>
    >> -- Notice now that *that* account's OTR-encrypted session was not
    >> recognized. The padlock is open. Sending messages now will send
    them as
    >> plain text. However, it did just receive the encrypted message and
    >> decrypted it successfully.
    >>
    >> When enabling debug logging in OTR one notices that the
    messages are
    >> indeed encrypted from the side showing the OTR-encrypted
    session, and
    >> plain text for the other side.
    >>
    >> Disabling message carbons fixes the problem described above.
    (At least,
    >> it does for me.)
    >>
    >>
    >> Sorry for making this such a long post. To conclude: I have
    been trying
    >> to get a feel for the state of OTR support in Jitsi. We already
    knew of
    >> some issues with state mangement. I believe these findings may have
    >> fine-tuned this issue a bit. For now I do not see any big problems,
    >> especially since the UI always showed an accurate state.
    Confusion is
    >> mostly caused by XMPP's message carbons together with multiple
    active
    >> sessions, which also makes the issues local to the XMPP
    protocol. The
    >> confusion is focused on using the UI, as OTR seems to do the
    right thing
    >> in the background. EXCEPT for this one issue described above
    where the
    >> OTR-encrypted session should have been established at both
    sides. But
    >> even then, Jitsi showed the correct state as the results were
    accordingly.
    >>
    >> So, if you rely on OTR, make sure that your XMPP accounts have
    message
    >> carbons disabled. Then you should have a pretty smooth ride.
    (As far as
    >> I can tell from these tests.)
    >>
    >> Danny
    >>
    >>
    >>
    >>
    >> On 26-01-15 10:50, George Politis wrote:
    >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
    >>>
    >>>> Hi all,
    >>>>
    >>>> Quick follow-up. I haven't had as much time as I would've
    liked. I have
    >>>> found out the following things. (in line ...)
    >>>>
    >>>> On 23-01-15 21:34, Danny van Heumen wrote:
    >>>>> Hi all,
    >>>>>
    >>>>> Because of recent remarks about OTR support in Jitsi, I've
    been trying
    >>>>> out some cases - all using XMPP as messaging protocol. These
    were
    >>>>> all in
    >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
    accounts also
    >>>>> logged in on Pidgin.
    >>>>>
    >>>>> For now, here's what I've found.
    >>>>>
    >>>>> 1. When using multiple sessions, Jitsi doesn't seem to correctly
    >>>>> distinguish and discard the messages-for-another-session. I
    quickly
    >>>>> looked at the otr4j source and if I read it correctly, then
    the message
    >>>>> gets returned unchanged. (Only took a quick look, so may not be
    >>>>> accurate.) In that case the Jitsi client will just show the
    >>>>> base64(encrypted) content. ... at least in this test ...
    (So, send from
    >>>>> Jitsi client to Pidgin client, while Jitsi also connected to
    same
    >>>>> account as Pidgin's is logged on to.)
    >>>> It is just slightly different than I've stated above. It
    turns out that
    >>>> the 2nd session "listening in" (not in the malicious way)
    does not have
    >>>> an OTR session established. So, as a consequence this session
    receives
    >>>> encrypted messages as if they were normal messages.
    >>>>
    >>>> This is likely not an issue in the OTR4J library, but rather
    in Jitsi
    >>>> not including OTR4J, since it isn't enabled. I believe that
    if OTR4J was
    >>>> "in the loop" it would have handled this message. Maybe by
    dropping a
    >>>> system message saying what is happening. Need to look into
    that further.
    >>>>
    >>> There seems to be an issue here. You're talking about
    >>> OtrTransformLayer:149, right? Where this code fragment is
    executed:
    >>>
    >>> f (!policy.getEnableManual()
    >>> && sessionStatus != ScSessionStatus.ENCRYPTED
    >>> && sessionStatus != ScSessionStatus.FINISHED)
    >>> return evt;
    >>>
    >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
    message it
    >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
    at Pidgin
    >>>>> side. (Though javascript doesn't get executed :-P)
    >>>> This one's a bit tricky. We receive a text message which is
    encrypted.
    >>>> Once decrypted, we need to discover whether it is intended as
    HTML or
    >>>> plain text. I'm not sure how another OTR-capable chat client
    makes this
    >>>> distinction, though looking at Pidgin's behaviour, I suspect
    they may
    >>>> simply have assumed HTML. (Otherwise it wouldn't have been as
    simple to
    >>>> inject styling in the message sent to Pidgin client.)
    >>> Other clients, like Miranda, have the exact same problem when they
    >>> communicate with Pidgin
    (https://developer.pidgin.im/ticket/8453). I
    >>> suppose the messages that Pidgin is sending don't have their
    >>> contentType set correctly, right? In that case, one way to fix it
    >>> would be to assume HTML if the remote client is Pidgin.
    >>>
    >>>>> 3. Jitsi does not unescape html received from Pidgin. So
    "<dude>" sent
    >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
    >>>> Same as above.
    >>>>> All should be fairly easy to fix.
    >>>> I should've known better ... saying things like that :stuck_out_tongue:
    >>>>
    >>>>> (Assuming Pidgin is the one behaving
    >>>>> as expected, which I am at the moment but will try to check
    before
    >>>>> fixing things in Jitsi.)
    >>>>>
    >>>>> I haven't found a case yet where I get to see the actual
    HTML that is
    >>>>> being sent as was described in
    >>>>>
    http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
    >>>>> understand correctly that is ...)
    >>>> Still same. I have only seen html entities up to now. If
    anyone knows
    >>>> otherwise, plz let me know.
    >>>>
    >>>> As an added bonus I found out that plain text messages aren't
    correctly
    >>>> escaped in the notification popup, so at least that's fixed
    now :slight_smile:
    >>>>
    >>>> Danny
    >>>>
    >>>>> Danny
    >>>>>
    >>>>>
    >>>>>
    >>>>> _______________________________________________
    >>>>> dev mailing list
    >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
    >>>>> Unsubscribe instructions and other list options:
    >>>>> http://lists.jitsi.org/mailman/listinfo/dev
    >>>> _______________________________________________
    >>>> dev mailing list
    >>>> dev@jitsi.org <mailto:dev@jitsi.org>
    >>>> Unsubscribe instructions and other list options:
    >>>> http://lists.jitsi.org/mailman/listinfo/dev
    >>> _______________________________________________
    >>> dev mailing list
    >>> dev@jitsi.org <mailto:dev@jitsi.org>
    >>> Unsubscribe instructions and other list options:
    >>> http://lists.jitsi.org/mailman/listinfo/dev
    >>
    >>
    >> _______________________________________________
    >> dev mailing list
    >> dev@jitsi.org <mailto:dev@jitsi.org>
    >> Unsubscribe instructions and other list options:
    >> http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

Hi Danny,

As I understand it now, that

is what I can derive from your comments about the implementation, is
that there is supposed to be a menu for selecting slave sessions, like
you said. These slave sessions are for each of the different sender
instances encountered by otr4j. Going into the implementation, do I
understand correctly that the variable 'outgoingSession' contains an
instance of the available slave sessions that is selected as the
outgoing session? So, in other words, the outgoingSession variable
always contains an instance that is also found in the slaveSessions map?

That is completely correct. Or at least it is supposed to work that way.

If you are supposed to switch slave sessions manually, then the user

should be able to manually switch to the encrypted slave session. I
haven't seen this menu though, so that would explain a lot. I'm guessing
it does not do this automatically, e.g. after a new encrypted session is
established? ... I guess that would make sense, since it could frustrate
users trying to send a message.

Also correct. Please look at the
net.java.sip.communicator.plugin.otr.authdialog.OTRv3OutgoingSessionSwitcher
class.
If I recall correctly, one could also use the Secure Chat menu in order to
switch between slave sessions but I'm not completely sure about that.

None of the menu entries has a closed

padlock. (Again, if I send a message from the other side, it correctly
gets decrypted, so the OTR-session is still "encrypted".) Additionally,
the "Secure chat" menu shows a list of session, right? Also there, every
session has an open padlock.

Since an incoming message gets decrypted that means you have a slave
session in ENCRYPTED state which is good - otr was established. All
incoming messages will get decrypted correctly. But you can use this slave
session to encrypt outgoing messages aswell. You just have to select it. An
open padlock means that the slave session is not currently selected, or
better said - the current outgoing session is in PLAINTEXT state.

Correct, it switches ... although I think it stops switching if I select

this "root" (bare?) session. Could that be right?

Yes, correct. Also, please note that with the current implementation you
could never establish ENCRYPTED session with the bare jid. That's because
jids are mapped to instance id's (or sth like that). So even if one Jitsi
client (Alice) tries to send an OTR initiation request to his buddy (Bob)
using his Bob's bare jid, what happens is that actually when Bob receives
Alice's message he'll respond with his actual JID. Then, when Alice receive
Bob's response she'll create a slave session since Bob's response doesn't
come from a bare jid but from an actual one. I hope that makes sense.

I think I'm getting there ... given that it is possible to select slave

sessions, that would mean that the encrypted session can be looked up
manually. So in that case it could be merely a UI issue - and a lot of
confusing messages like "Private conversation with ... lost.",
immediately after establishing an encrypted session.

Yes, you are!
Thank you very much for the effort. I know from experience how frustrating
that could be. Debugging OTR issues in combination with XMPP is very
exhausting as it may often seem indeterministic.

Best regards,
Marin

···

On Thu, Feb 26, 2015 at 9:56 PM, Danny van Heumen <danny@dannyvanheumen.nl> wrote:

Hi Marin,

Thanks for your quite detailed response. I'll add my comments in-line.
Hopefully that clarifies what I think my issue is about.

On 26-02-15 14:06, Marin Dzhigarov wrote:
> Hello Danny,
>
> Thank you for your findings but...
>
> RESULT:
> 1. Plain text Master session. Will answer calls to
> getStatus(SessionID).
> 2. Fully established ENCRYPTED slave session. Will be reachable
> for decrypting messages, however it is completely off-the-radar
> when querying the status of a session.
> 3. Received messages get routed by their sender instance ID and
> arrive at the slave session, get processed appropriately and hence
> get returned decrypted to Jitsi.
> 4. Sent messages get sent in plain text according to the Master
> session's status. Client at other end will received a plain text
> message even though it has an OTR session established.
>
>
> I still don't see anything wrong with this behaviour. Actually, I
> implemented it that way so I'm glad it's still working :smiley:
> You can use the icon in the left-down corner in order to switch
> between carbons. When you do, the "active" carbon is going to change
> and you will see that the padlock is closed. (Or at least it should
> work that way if I remember correctly).
So, when I'm talking about carbons, I'm referring to the actual messages
themselves being replicated to other clients of the same account. I am
assuming here that you mean the various "sessions", one session for each
of the logged in clients of that account, right?

So, after the session is established, I can indeed switch these sessions
using that drop down menu. None of the menu entries has a closed
padlock. (Again, if I send a message from the other side, it correctly
gets decrypted, so the OTR-session is still "encrypted".) Additionally,
the "Secure chat" menu shows a list of session, right? Also there, every
session has an open padlock.

> Addionally, you may have an icon in the right-down corner that
> switches between active slave sessions but I don't remember the
> details for that one. So you might end up having to choose between a
> combination of [carbon - otr session] from the two down corners in
> order to send proper messages.
I have not found this right-bottom menu. Never seen it as far as I can
remember.

I think this might be related to my issue. As I understand it now, that
is what I can derive from your comments about the implementation, is
that there is supposed to be a menu for selecting slave sessions, like
you said. These slave sessions are for each of the different sender
instances encountered by otr4j. Going into the implementation, do I
understand correctly that the variable 'outgoingSession' contains an
instance of the available slave sessions that is selected as the
outgoing session? So, in other words, the outgoingSession variable
always contains an instance that is also found in the slaveSessions map?

If you are supposed to switch slave sessions manually, then the user
should be able to manually switch to the encrypted slave session. I
haven't seen this menu though, so that would explain a lot. I'm guessing
it does not do this automatically, e.g. after a new encrypted session is
established? ... I guess that would make sense, since it could frustrate
users trying to send a message.

> I remember that I also put some logic so that Jitsi can automacally
> switch between carbons (down-left icon) depending on the received
> message. The idea was that if one receives a message from a certain
> jid, the default carbon and thus the active otr slave session (used to
> encrypt outgoing messages) is switched.
Correct, it switches ... although I think it stops switching if I select
this "root" (bare?) session. Could that be right?

>
> ​
>
>
> * Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
> possible, but should not be a problem. Given that the slave
> sessions are
> about decrypting received messages. Sending encrypted messages
> wouldn't
> be a problem, since the master session is ENCRYPTED. Also, the
session
> status reflects the status of the Master sessions which also sends,
so
> the status is accurate.
>
>
> Also, again if I remember correctly, there is no way to have an
> ENCRYPTED master session because master sessions delegate session
> initiation requests to slave sessions.
Okay, sure, that makes sense. I did check logging I produce and it shows
that the same session instance that had old status 'plaintext' and new
status 'encrypted' has isMasterSession == true. So it seems that this is
possible.

I think I'm getting there ... given that it is possible to select slave
sessions, that would mean that the encrypted session can be looked up
manually. So in that case it could be merely a UI issue - and a lot of
confusing messages like "Private conversation with ... lost.",
immediately after establishing an encrypted session.

I'm going to look into getting these slave sessions to the surface ...

Danny

> ​
>
> I hope that helps.
>
> Best regards,
> Marin
>
> On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
>
>
> A quick addition ... I was thinking about which combinations are
> possible for Master - Slave session combinations.
>
> * Master session: PLAINTEXT + Slave session: ENCRYPTED -- possible as
> this is the current problem.
>
> * Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
> possible, but should not be a problem. Given that the slave
> sessions are
> about decrypting received messages. Sending encrypted messages
> wouldn't
> be a problem, since the master session is ENCRYPTED. Also, the
session
> status reflects the status of the Master sessions which also sends,
so
> the status is accurate.
>
> * Both PLAINTEXT shouldn't be an issue in any case, i.e. no encrypted
> sessions established.
>
> * Both ENCRYPTED: not sure if this makes sense, but in any case we
> would
> sent an encrypted message. It might get delivered to the wrong
> address,
> but it wouldn't unintentionally be sent PLAINTEXT, so not an issue(?)
>
> Danny
>
>
>
> On 25-02-15 23:43, Danny van Heumen wrote:
> > Hi all,
> >
> > So, here's another follow up with what I found out yesterday. I
> think
> > I may have an explanation of what happens. It's pretty interesting
> > interplay of features, I think ...
> >
> > A FEW FACTS:
> > * When message carbons are activated, the messages sent by one
> client
> > are repeated to the other clients as message delivered events. (I'm
> > quite sure, but please correct me if I'm wrong here ...)
> > * Jitsi's OTR implementation does not process message delivered
> > events. (The only exception to this is to check if a message is
> > injected such that the user is not bothered with OTR interaction
> > inside the client.)
> > * I found out that the session status gets updated in another
> instance
> > of SessionImpl than where the instance where we query for the
> current
> > session status. This explains both:
> >
> > 1. Why the statuses deviate - between session establishment (in log
> > messages) and session status querying, and
> > 2. Why messages till get decrypted when received even though the
> > status is PLAINTEXT.
> >
> > FLOW OF EVENTS: Here's where it gets interesting ...
> >
> > Say we have:
> > * An account a@jit.si <mailto:a@jit.si> on server jit.si
> <http://jit.si> which supports message carbons.
> > * An account b@gmail.com <mailto:b@gmail.com> on server
> gmail.com <http://gmail.com> which does not support
> > message carbons.
> > * Client A, a Jitsi client, with account a@jit.si
> <mailto:a@jit.si> - with message
> > carbons enabled - and account b@gmail.com <mailto:b@gmail.com>.
> > * Client B, another client with account a@jit.si
> <mailto:a@jit.si> - without message
> > carbons enabled.
> >
> > 1. We initiate an OTR session with client A to account
> b@gmail.com <mailto:b@gmail.com>.
> > This means that B sends the OTR v3 query message.
> > -- a) client A receives the request on account b@gmail.com
> <mailto:b@gmail.com>
> > -- b) client A receives a carbon of the request on a@jit.si
> <mailto:a@jit.si>. This
> > message isn't processed by otr4j, so effectively gets ignored.
> >
> > 2. Client A receives OTR v3 query message, answers with D-H commit
> > message.
> > -- a) client B receives the request on account a@jit.si
> <mailto:a@jit.si>.
> > -- b) client A a@jit.si <mailto:a@jit.si> receives the message
> carbon and sets a master
> > session for this sender instance id, however it does not expect the
> > D-H commit message so does not respond.
> >
> > 3. Client A (a@jit.si <mailto:a@jit.si>) and client B
> (b@gmail.com <mailto:b@gmail.com>) finish up OTR
> > protocol and establish a secure session.
> >
> > Now Client A (b@gmail.com <mailto:b@gmail.com>) wants to
> establish an OTR session with
> > Client A (a@jit.si <mailto:a@jit.si>), so it sends initial OTR
> v3 query message.
> >
> > 4. Client A on b@gmail.com <mailto:b@gmail.com> sends message to
> a@jit.si <mailto:a@jit.si> for client A
> > (that is, that specific session id).
> > -- a) Client A a@jit.si <mailto:a@jit.si> receives this message,
> however it contains a
> > different sender instance id than the message before, so a slave
> > session is established. The received message gets passed through to
> > slave session. Slave session handles message.
> >
> > 5. Client A a@jit.si <mailto:a@jit.si> responds and continues
> establishing OTR encrypted
> > session. Now Client A a@jit.si <mailto:a@jit.si> has 2 sessions
> available:
> > * Master session: PLAINTEXT, received some OTR messages but
> nothing to
> > establish a connection with.
> > * Slave session: ENCRYPTED, did full processing of OTR session
> > establishment and has a full, completed ENCRYPTED session.
> >
> > Now that an encrypted session is established, we call listeners to
> > inform of a sessionStatusChanged(OtrContact). However, a call of
> > getStatus(SessionID for OtrContact) will return the session
> status of
> > the MASTER session, which is plain text, since it was based upon
the
> > message carbons.
> >
> > RESULT:
> >
> > 1. Plain text Master session. Will answer calls to
> getStatus(SessionID).
> > 2. Fully established ENCRYPTED slave session. Will be reachable for
> > decrypting messages, however it is completely off-the-radar when
> > querying the status of a session.
> > 3. Received messages get routed by their sender instance ID and
> arrive
> > at the slave session, get processed appropriately and hence get
> > returned decrypted to Jitsi.
> > 4. Sent messages get sent in plain text according to the Master
> > session's status. Client at other end will received a plain text
> > message even though it has an OTR session established.
> >
> > I hope this makes sense. It is a bit late, so please be critical
and
> > check if everything makes sense. I can clarify if there are any
> > questions. (Or replay the problem and/or recheck the logging.)
> >
> > Assuming the above is correct, this would also explain my earlier
> > comment regarding disabling message carbons. This would indeed
> prevent
> > establishing the early Master session, hence when the OTR session
is
> > deliberately initiated, this would become the Master session and
one
> > would indeed get the correct Session Status when queried via
> > getStatus(SessionID).
> >
> > So, if this correctly establishes the problem, I am quite
interested
> > in how we're going to solve this one. I haven't thought about
> this one
> > yet ... :slight_smile:
> >
> > Regards,
> > Danny
> >
> >
> >
> > On 22-02-15 21:18, Danny van Heumen wrote:
> >> Okay, so it's time for an update on this topic ...
> >>
> >> @George: In case of TL;DR, could you check my commit, just to
> be sure?
> >>
>
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
> >> It's about removing the conditionals so any message reaches the
> otr4j
> >> library, even if a secure session is not established yet.
> Basically what
> >> you suggested before.
> >> Also, can you explain why at SessionImpl:479 (call to
> >> setSessionStatus(ENCRYPTED)) the called method resets auth
> (AuthContext)
> >> to setIsSecure(false), while the passed parameter is
> >> SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
> >> contradictory.)
> >>
> >> I've been playing around with the whole OTR UI and plugin to
> see what I
> >> could discover apart from the stuff we already know. I have
> been playing
> >> around for a few hours and this is a quick report of what I've
> been able
> >> to discover.
> >>
> >> 1. The raw OTR-encrypted message I received as described below,
> is due
> >> to XMPP Carbons being enabled. We receive the message sent from
> another
> >> client (same account) and we subscribed to carbon copies, so we
> receive
> >> a carbon of the raw message. This particular message flow is
> not hooked
> >> into otr4j, so it gets shown as a plain old message. (@fippo:
> Thanks for
> >> pointing out the carbons!)
> >>
> >> a) I'm thinking of whether or not we *can* hook that into
> otr4j. Maybe
> >> we can process this as a "received" message. I have not done
> that yet,
> >> though, because I'm not a 100% sure that there aren't any other
> >> consequences. (It would be nice to see a notification of a message
> >> encrypted for another session, and have the ability to drop the
> message
> >> itself, since that has no value to us.)
> >>
> >> 2. I have seen a mismatching padlock icon, compared to the actual
> >> session and the sessions in the "Secure chat" menu. The
> sessions listed
> >> in "Secure chat" menu have always been accurate AFAICT. I have
> not been
> >> able to reproduce it reliably though -- and I'm starting to doubt
> >> whether session selection isn't the culprit.
> >>
> >> 3. About encryption-state mismatches ...
> >>
> >> a) I have NOT been able to get a session that was not actually
> >> encrypted even though Jitsi says it IS encrypted. This in
> itself does
> >> not prove that there isn't an issue, but it's not so easy to
> get into
> >> that state by just clicking buttons (with or without thinking
> about it).
> >>
> >> b) I have been able to send unencrypted messages while an
> encrypted
> >> session was set up. HOWEVER, Jitsi accurately showed an open
> padlock
> >> when sending the message. The reason for this is that I had
> selected the
> >> "root" XMPP session and sent the message via there. If you
> select this
> >> session, Jitsi accurately shows an open padlock and messages
> are sent to
> >> all session (I think). The chat client on the other side
accurately
> >> warns of an unencrypted message being received. If you then
> select one
> >> specific XMPP session in the chat window, the padlock updates
> and indeed
> >> messages are sent in encrypted form.
> >>
> >> As far as I have been able to determine this is all expected
> behaviour.
> >> The root session cannot be OTR-encrypted, since it sends to
> (multiple?)
> >> sessions and you would need to encrypt differently for every
> session. So
> >> you need to select one specific session to send encrypted
> messages. (OTR
> >> also stores a new session instance for each XMPP session.)
> >>
> >> 4. Given the behaviour above, it would be good to somehow warn or
> >> prevent users from selecting the "root" session if multiple
> sessions are
> >> known/active. This should prevent mistakes from being made.
> >>
> >> a) We may need to change the UI so that the "active" session
> (last
> >> message) is selected automatically and users would always need
> to select
> >> a specific session to switch. (And maybe we should not allow
> selecting
> >> this top-most session.)
> >>
> >> ... after some more hours of fiddling around and lots of confusing
> >> moments ...
> >>
> >> 5. I have now determined that XMPP message carbons can
> interfere with
> >> correctly establishing an encrypted OTR sessions at one of two
> sides. I
> >> am not clear on the details yet (and I am starting to believe
> that this
> >> is a bug in the implementation), but this issue seems to arise
> at the
> >> side where 2 sessions are active and carbons are enabled. (I
> see the
> >> occasional OTR debug log entry about messages meant for another
> session.)
> >>
> >> a) The result is an encrypted OTR session that IS established
> for the
> >> non-problematic side (account with only a single XMPP session).
The
> >> sessions is established fully, and it can send encrypted
> messages. The
> >> other side (2 active XMPP sessions) eventually decides to go with
> >> plaintext and does not expose the encrypted session, even
> though it is
> >> established. It is established because it can decrypt any received
> >> encrypted messages, however ask the OTR Session-instance for its
> >> SessionStatus and it will return PLAINTEXT. Send a message from
> that
> >> side and it will send a plain text message (not encrypted).
> NOTE that
> >> the padlock icon consistently shows an accurate state.
> >>
> >> 6. Further more, a small issue which may not actually be a
> problem. I
> >> note this here for reference as it may only ever occur if you
> delay the
> >> process by debugging (stepping through code): In the OTR
> plugin, if the
> >> timeout-scheduler isn't cancelled in time, it will set a
> "timeout" state
> >> which is then used and hides the true state of the OTR Session
> instance.
> >>
> >> Reproduction recipe for 5.:
> >> 1. Start some other chat client. Log in the account with server
> support
> >> message carbons, e.g. @jit.si <http://jit.si>. This is going to
> be the shared account.
> >> 2. Start Jitsi. Log in with same account as in 1. Make sure
message
> >> carbons are enabled.
> >> Using Jitsi, log in with another XMPP account.
> >>
> >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
> other client
> >> - with message carbons, 1 solely for Jitsi.
> >>
> >> 3. Use client from 1. initiate OTR-encrypted session with 2. using
> >> @jit.si <http://jit.si> account
> >> 4. Using client from 1. send message to other XMPP account.
> >> 5. Jitsi popup shows that it received a message. Click popup to
> view
> >> message. Notice that OTR session is established.
> >> 6. In Jitsi, select the other session for this account (@jit.si
> <http://jit.si>) that is
> >> available (which accidentally is the Jitsi client's XMPP session)
> >> 7. Initiate OTR-encrypted session between the 2 accounts, both
> in Jitsi.
> >>
> >> -- Notice that session correctly establishes at initiating
> side, which
> >> is the 1-session XMPP account solely in use by Jitsi.
> >>
> >> 9. Send a message over this newly instantiated OTR session.
> >> 10. Popup shows for newly received message, click and it opens
> a second
> >> tab showing the message received on the shared @jit.si
> <http://jit.si> account.
> >>
> >> -- Notice now that *that* account's OTR-encrypted session was not
> >> recognized. The padlock is open. Sending messages now will send
> them as
> >> plain text. However, it did just receive the encrypted message and
> >> decrypted it successfully.
> >>
> >> When enabling debug logging in OTR one notices that the
> messages are
> >> indeed encrypted from the side showing the OTR-encrypted
> session, and
> >> plain text for the other side.
> >>
> >> Disabling message carbons fixes the problem described above.
> (At least,
> >> it does for me.)
> >>
> >>
> >> Sorry for making this such a long post. To conclude: I have
> been trying
> >> to get a feel for the state of OTR support in Jitsi. We already
> knew of
> >> some issues with state mangement. I believe these findings may
have
> >> fine-tuned this issue a bit. For now I do not see any big
problems,
> >> especially since the UI always showed an accurate state.
> Confusion is
> >> mostly caused by XMPP's message carbons together with multiple
> active
> >> sessions, which also makes the issues local to the XMPP
> protocol. The
> >> confusion is focused on using the UI, as OTR seems to do the
> right thing
> >> in the background. EXCEPT for this one issue described above
> where the
> >> OTR-encrypted session should have been established at both
> sides. But
> >> even then, Jitsi showed the correct state as the results were
> accordingly.
> >>
> >> So, if you rely on OTR, make sure that your XMPP accounts have
> message
> >> carbons disabled. Then you should have a pretty smooth ride.
> (As far as
> >> I can tell from these tests.)
> >>
> >> Danny
> >>
> >>
> >>
> >>
> >> On 26-01-15 10:50, George Politis wrote:
> >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Quick follow-up. I haven't had as much time as I would've
> liked. I have
> >>>> found out the following things. (in line ...)
> >>>>
> >>>> On 23-01-15 21:34, Danny van Heumen wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Because of recent remarks about OTR support in Jitsi, I've
> been trying
> >>>>> out some cases - all using XMPP as messaging protocol. These
> were
> >>>>> all in
> >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
> accounts also
> >>>>> logged in on Pidgin.
> >>>>>
> >>>>> For now, here's what I've found.
> >>>>>
> >>>>> 1. When using multiple sessions, Jitsi doesn't seem to
correctly
> >>>>> distinguish and discard the messages-for-another-session. I
> quickly
> >>>>> looked at the otr4j source and if I read it correctly, then
> the message
> >>>>> gets returned unchanged. (Only took a quick look, so may not be
> >>>>> accurate.) In that case the Jitsi client will just show the
> >>>>> base64(encrypted) content. ... at least in this test ...
> (So, send from
> >>>>> Jitsi client to Pidgin client, while Jitsi also connected to
> same
> >>>>> account as Pidgin's is logged on to.)
> >>>> It is just slightly different than I've stated above. It
> turns out that
> >>>> the 2nd session "listening in" (not in the malicious way)
> does not have
> >>>> an OTR session established. So, as a consequence this session
> receives
> >>>> encrypted messages as if they were normal messages.
> >>>>
> >>>> This is likely not an issue in the OTR4J library, but rather
> in Jitsi
> >>>> not including OTR4J, since it isn't enabled. I believe that
> if OTR4J was
> >>>> "in the loop" it would have handled this message. Maybe by
> dropping a
> >>>> system message saying what is happening. Need to look into
> that further.
> >>>>
> >>> There seems to be an issue here. You're talking about
> >>> OtrTransformLayer:149, right? Where this code fragment is
> executed:
> >>>
> >>> f (!policy.getEnableManual()
> >>> && sessionStatus != ScSessionStatus.ENCRYPTED
> >>> && sessionStatus != ScSessionStatus.FINISHED)
> >>> return evt;
> >>>
> >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
> message it
> >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
> at Pidgin
> >>>>> side. (Though javascript doesn't get executed :-P)
> >>>> This one's a bit tricky. We receive a text message which is
> encrypted.
> >>>> Once decrypted, we need to discover whether it is intended as
> HTML or
> >>>> plain text. I'm not sure how another OTR-capable chat client
> makes this
> >>>> distinction, though looking at Pidgin's behaviour, I suspect
> they may
> >>>> simply have assumed HTML. (Otherwise it wouldn't have been as
> simple to
> >>>> inject styling in the message sent to Pidgin client.)
> >>> Other clients, like Miranda, have the exact same problem when
they
> >>> communicate with Pidgin
> (https://developer.pidgin.im/ticket/8453). I
> >>> suppose the messages that Pidgin is sending don't have their
> >>> contentType set correctly, right? In that case, one way to fix it
> >>> would be to assume HTML if the remote client is Pidgin.
> >>>
> >>>>> 3. Jitsi does not unescape html received from Pidgin. So
> "<dude>" sent
> >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
> >>>> Same as above.
> >>>>> All should be fairly easy to fix.
> >>>> I should've known better ... saying things like that :stuck_out_tongue:
> >>>>
> >>>>> (Assuming Pidgin is the one behaving
> >>>>> as expected, which I am at the moment but will try to check
> before
> >>>>> fixing things in Jitsi.)
> >>>>>
> >>>>> I haven't found a case yet where I get to see the actual
> HTML that is
> >>>>> being sent as was described in
> >>>>>
> http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if
I
> >>>>> understand correctly that is ...)
> >>>> Still same. I have only seen html entities up to now. If
> anyone knows
> >>>> otherwise, plz let me know.
> >>>>
> >>>> As an added bonus I found out that plain text messages aren't
> correctly
> >>>> escaped in the notification popup, so at least that's fixed
> now :slight_smile:
> >>>>
> >>>> Danny
> >>>>
> >>>>> Danny
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> dev mailing list
> >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>>>> Unsubscribe instructions and other list options:
> >>>>> http://lists.jitsi.org/mailman/listinfo/dev
> >>>> _______________________________________________
> >>>> dev mailing list
> >>>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>>> Unsubscribe instructions and other list options:
> >>>> http://lists.jitsi.org/mailman/listinfo/dev
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>> Unsubscribe instructions and other list options:
> >>> http://lists.jitsi.org/mailman/listinfo/dev
> >>
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev@jitsi.org <mailto:dev@jitsi.org>
> >> Unsubscribe instructions and other list options:
> >> http://lists.jitsi.org/mailman/listinfo/dev
> >
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org <mailto:dev@jitsi.org>
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#16

Hi,

Just to correct a typo from my last email

That's because jids are mapped to instance id's (or sth like that).

What I meant here is instance tags. I'm talking about OTRv3 instance tags
and slave sessions. So Alice will have 1 slave session for every jid of Bob.

···

On Fri, Feb 27, 2015 at 9:08 AM, Marin Dzhigarov <m.dzhigarov@gmail.com> wrote:

Hi Danny,

As I understand it now, that

is what I can derive from your comments about the implementation, is
that there is supposed to be a menu for selecting slave sessions, like
you said. These slave sessions are for each of the different sender
instances encountered by otr4j. Going into the implementation, do I
understand correctly that the variable 'outgoingSession' contains an
instance of the available slave sessions that is selected as the
outgoing session? So, in other words, the outgoingSession variable
always contains an instance that is also found in the slaveSessions map?

That is completely correct. Or at least it is supposed to work that way.

If you are supposed to switch slave sessions manually, then the user

should be able to manually switch to the encrypted slave session. I
haven't seen this menu though, so that would explain a lot. I'm guessing
it does not do this automatically, e.g. after a new encrypted session is
established? ... I guess that would make sense, since it could frustrate
users trying to send a message.

Also correct. Please look at the
net.java.sip.communicator.plugin.otr.authdialog.
OTRv3OutgoingSessionSwitcher class.
If I recall correctly, one could also use the Secure Chat menu in order to
switch between slave sessions but I'm not completely sure about that.

None of the menu entries has a closed

padlock. (Again, if I send a message from the other side, it correctly
gets decrypted, so the OTR-session is still "encrypted".) Additionally,
the "Secure chat" menu shows a list of session, right? Also there, every
session has an open padlock.

Since an incoming message gets decrypted that means you have a slave
session in ENCRYPTED state which is good - otr was established. All
incoming messages will get decrypted correctly. But you can use this slave
session to encrypt outgoing messages aswell. You just have to select it. An
open padlock means that the slave session is not currently selected, or
better said - the current outgoing session is in PLAINTEXT state.

Correct, it switches ... although I think it stops switching if I select

this "root" (bare?) session. Could that be right?

Yes, correct. Also, please note that with the current implementation you
could never establish ENCRYPTED session with the bare jid. That's because
jids are mapped to instance id's (or sth like that). So even if one Jitsi
client (Alice) tries to send an OTR initiation request to his buddy (Bob)
using his Bob's bare jid, what happens is that actually when Bob receives
Alice's message he'll respond with his actual JID. Then, when Alice receive
Bob's response she'll create a slave session since Bob's response doesn't
come from a bare jid but from an actual one. I hope that makes sense.

I think I'm getting there ... given that it is possible to select slave

sessions, that would mean that the encrypted session can be looked up
manually. So in that case it could be merely a UI issue - and a lot of
confusing messages like "Private conversation with ... lost.",
immediately after establishing an encrypted session.

Yes, you are!
Thank you very much for the effort. I know from experience how frustrating
that could be. Debugging OTR issues in combination with XMPP is very
exhausting as it may often seem indeterministic.

Best regards,
Marin

On Thu, Feb 26, 2015 at 9:56 PM, Danny van Heumen <danny@dannyvanheumen.nl > > wrote:

Hi Marin,

Thanks for your quite detailed response. I'll add my comments in-line.
Hopefully that clarifies what I think my issue is about.

On 26-02-15 14:06, Marin Dzhigarov wrote:
> Hello Danny,
>
> Thank you for your findings but...
>
> RESULT:
> 1. Plain text Master session. Will answer calls to
> getStatus(SessionID).
> 2. Fully established ENCRYPTED slave session. Will be reachable
> for decrypting messages, however it is completely off-the-radar
> when querying the status of a session.
> 3. Received messages get routed by their sender instance ID and
> arrive at the slave session, get processed appropriately and hence
> get returned decrypted to Jitsi.
> 4. Sent messages get sent in plain text according to the Master
> session's status. Client at other end will received a plain text
> message even though it has an OTR session established.
>
>
> I still don't see anything wrong with this behaviour. Actually, I
> implemented it that way so I'm glad it's still working :smiley:
> You can use the icon in the left-down corner in order to switch
> between carbons. When you do, the "active" carbon is going to change
> and you will see that the padlock is closed. (Or at least it should
> work that way if I remember correctly).
So, when I'm talking about carbons, I'm referring to the actual messages
themselves being replicated to other clients of the same account. I am
assuming here that you mean the various "sessions", one session for each
of the logged in clients of that account, right?

So, after the session is established, I can indeed switch these sessions
using that drop down menu. None of the menu entries has a closed
padlock. (Again, if I send a message from the other side, it correctly
gets decrypted, so the OTR-session is still "encrypted".) Additionally,
the "Secure chat" menu shows a list of session, right? Also there, every
session has an open padlock.

> Addionally, you may have an icon in the right-down corner that
> switches between active slave sessions but I don't remember the
> details for that one. So you might end up having to choose between a
> combination of [carbon - otr session] from the two down corners in
> order to send proper messages.
I have not found this right-bottom menu. Never seen it as far as I can
remember.

I think this might be related to my issue. As I understand it now, that
is what I can derive from your comments about the implementation, is
that there is supposed to be a menu for selecting slave sessions, like
you said. These slave sessions are for each of the different sender
instances encountered by otr4j. Going into the implementation, do I
understand correctly that the variable 'outgoingSession' contains an
instance of the available slave sessions that is selected as the
outgoing session? So, in other words, the outgoingSession variable
always contains an instance that is also found in the slaveSessions map?

If you are supposed to switch slave sessions manually, then the user
should be able to manually switch to the encrypted slave session. I
haven't seen this menu though, so that would explain a lot. I'm guessing
it does not do this automatically, e.g. after a new encrypted session is
established? ... I guess that would make sense, since it could frustrate
users trying to send a message.

> I remember that I also put some logic so that Jitsi can automacally
> switch between carbons (down-left icon) depending on the received
> message. The idea was that if one receives a message from a certain
> jid, the default carbon and thus the active otr slave session (used to
> encrypt outgoing messages) is switched.
Correct, it switches ... although I think it stops switching if I select
this "root" (bare?) session. Could that be right?

>
> ​
>
>
> * Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
> possible, but should not be a problem. Given that the slave
> sessions are
> about decrypting received messages. Sending encrypted messages
> wouldn't
> be a problem, since the master session is ENCRYPTED. Also, the
session
> status reflects the status of the Master sessions which also sends,
so
> the status is accurate.
>
>
> Also, again if I remember correctly, there is no way to have an
> ENCRYPTED master session because master sessions delegate session
> initiation requests to slave sessions.
Okay, sure, that makes sense. I did check logging I produce and it shows
that the same session instance that had old status 'plaintext' and new
status 'encrypted' has isMasterSession == true. So it seems that this is
possible.

I think I'm getting there ... given that it is possible to select slave
sessions, that would mean that the encrypted session can be looked up
manually. So in that case it could be merely a UI issue - and a lot of
confusing messages like "Private conversation with ... lost.",
immediately after establishing an encrypted session.

I'm going to look into getting these slave sessions to the surface ...

Danny

> ​
>
> I hope that helps.
>
> Best regards,
> Marin
>
> On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen >> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:
>
>
> A quick addition ... I was thinking about which combinations are
> possible for Master - Slave session combinations.
>
> * Master session: PLAINTEXT + Slave session: ENCRYPTED -- possible
as
> this is the current problem.
>
> * Master session: ENCRYPTED + Slave session: PLAINTEXT -- should be
> possible, but should not be a problem. Given that the slave
> sessions are
> about decrypting received messages. Sending encrypted messages
> wouldn't
> be a problem, since the master session is ENCRYPTED. Also, the
session
> status reflects the status of the Master sessions which also sends,
so
> the status is accurate.
>
> * Both PLAINTEXT shouldn't be an issue in any case, i.e. no
encrypted
> sessions established.
>
> * Both ENCRYPTED: not sure if this makes sense, but in any case we
> would
> sent an encrypted message. It might get delivered to the wrong
> address,
> but it wouldn't unintentionally be sent PLAINTEXT, so not an
issue(?)
>
> Danny
>
>
>
> On 25-02-15 23:43, Danny van Heumen wrote:
> > Hi all,
> >
> > So, here's another follow up with what I found out yesterday. I
> think
> > I may have an explanation of what happens. It's pretty interesting
> > interplay of features, I think ...
> >
> > A FEW FACTS:
> > * When message carbons are activated, the messages sent by one
> client
> > are repeated to the other clients as message delivered events.
(I'm
> > quite sure, but please correct me if I'm wrong here ...)
> > * Jitsi's OTR implementation does not process message delivered
> > events. (The only exception to this is to check if a message is
> > injected such that the user is not bothered with OTR interaction
> > inside the client.)
> > * I found out that the session status gets updated in another
> instance
> > of SessionImpl than where the instance where we query for the
> current
> > session status. This explains both:
> >
> > 1. Why the statuses deviate - between session establishment (in
log
> > messages) and session status querying, and
> > 2. Why messages till get decrypted when received even though the
> > status is PLAINTEXT.
> >
> > FLOW OF EVENTS: Here's where it gets interesting ...
> >
> > Say we have:
> > * An account a@jit.si <mailto:a@jit.si> on server jit.si
> <http://jit.si> which supports message carbons.
> > * An account b@gmail.com <mailto:b@gmail.com> on server
> gmail.com <http://gmail.com> which does not support
> > message carbons.
> > * Client A, a Jitsi client, with account a@jit.si
> <mailto:a@jit.si> - with message
> > carbons enabled - and account b@gmail.com <mailto:b@gmail.com>.
> > * Client B, another client with account a@jit.si
> <mailto:a@jit.si> - without message
> > carbons enabled.
> >
> > 1. We initiate an OTR session with client A to account
> b@gmail.com <mailto:b@gmail.com>.
> > This means that B sends the OTR v3 query message.
> > -- a) client A receives the request on account b@gmail.com
> <mailto:b@gmail.com>
> > -- b) client A receives a carbon of the request on a@jit.si
> <mailto:a@jit.si>. This
> > message isn't processed by otr4j, so effectively gets ignored.
> >
> > 2. Client A receives OTR v3 query message, answers with D-H commit
> > message.
> > -- a) client B receives the request on account a@jit.si
> <mailto:a@jit.si>.
> > -- b) client A a@jit.si <mailto:a@jit.si> receives the message
> carbon and sets a master
> > session for this sender instance id, however it does not expect
the
> > D-H commit message so does not respond.
> >
> > 3. Client A (a@jit.si <mailto:a@jit.si>) and client B
> (b@gmail.com <mailto:b@gmail.com>) finish up OTR
> > protocol and establish a secure session.
> >
> > Now Client A (b@gmail.com <mailto:b@gmail.com>) wants to
> establish an OTR session with
> > Client A (a@jit.si <mailto:a@jit.si>), so it sends initial OTR
> v3 query message.
> >
> > 4. Client A on b@gmail.com <mailto:b@gmail.com> sends message to
> a@jit.si <mailto:a@jit.si> for client A
> > (that is, that specific session id).
> > -- a) Client A a@jit.si <mailto:a@jit.si> receives this message,
> however it contains a
> > different sender instance id than the message before, so a slave
> > session is established. The received message gets passed through
to
> > slave session. Slave session handles message.
> >
> > 5. Client A a@jit.si <mailto:a@jit.si> responds and continues
> establishing OTR encrypted
> > session. Now Client A a@jit.si <mailto:a@jit.si> has 2 sessions
> available:
> > * Master session: PLAINTEXT, received some OTR messages but
> nothing to
> > establish a connection with.
> > * Slave session: ENCRYPTED, did full processing of OTR session
> > establishment and has a full, completed ENCRYPTED session.
> >
> > Now that an encrypted session is established, we call listeners to
> > inform of a sessionStatusChanged(OtrContact). However, a call of
> > getStatus(SessionID for OtrContact) will return the session
> status of
> > the MASTER session, which is plain text, since it was based upon
the
> > message carbons.
> >
> > RESULT:
> >
> > 1. Plain text Master session. Will answer calls to
> getStatus(SessionID).
> > 2. Fully established ENCRYPTED slave session. Will be reachable
for
> > decrypting messages, however it is completely off-the-radar when
> > querying the status of a session.
> > 3. Received messages get routed by their sender instance ID and
> arrive
> > at the slave session, get processed appropriately and hence get
> > returned decrypted to Jitsi.
> > 4. Sent messages get sent in plain text according to the Master
> > session's status. Client at other end will received a plain text
> > message even though it has an OTR session established.
> >
> > I hope this makes sense. It is a bit late, so please be critical
and
> > check if everything makes sense. I can clarify if there are any
> > questions. (Or replay the problem and/or recheck the logging.)
> >
> > Assuming the above is correct, this would also explain my earlier
> > comment regarding disabling message carbons. This would indeed
> prevent
> > establishing the early Master session, hence when the OTR session
is
> > deliberately initiated, this would become the Master session and
one
> > would indeed get the correct Session Status when queried via
> > getStatus(SessionID).
> >
> > So, if this correctly establishes the problem, I am quite
interested
> > in how we're going to solve this one. I haven't thought about
> this one
> > yet ... :slight_smile:
> >
> > Regards,
> > Danny
> >
> >
> >
> > On 22-02-15 21:18, Danny van Heumen wrote:
> >> Okay, so it's time for an update on this topic ...
> >>
> >> @George: In case of TL;DR, could you check my commit, just to
> be sure?
> >>
>
https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
> >> It's about removing the conditionals so any message reaches the
> otr4j
> >> library, even if a secure session is not established yet.
> Basically what
> >> you suggested before.
> >> Also, can you explain why at SessionImpl:479 (call to
> >> setSessionStatus(ENCRYPTED)) the called method resets auth
> (AuthContext)
> >> to setIsSecure(false), while the passed parameter is
> >> SessionStatus.ENCRYPTED? (It may be completely fine, but it seems
> >> contradictory.)
> >>
> >> I've been playing around with the whole OTR UI and plugin to
> see what I
> >> could discover apart from the stuff we already know. I have
> been playing
> >> around for a few hours and this is a quick report of what I've
> been able
> >> to discover.
> >>
> >> 1. The raw OTR-encrypted message I received as described below,
> is due
> >> to XMPP Carbons being enabled. We receive the message sent from
> another
> >> client (same account) and we subscribed to carbon copies, so we
> receive
> >> a carbon of the raw message. This particular message flow is
> not hooked
> >> into otr4j, so it gets shown as a plain old message. (@fippo:
> Thanks for
> >> pointing out the carbons!)
> >>
> >> a) I'm thinking of whether or not we *can* hook that into
> otr4j. Maybe
> >> we can process this as a "received" message. I have not done
> that yet,
> >> though, because I'm not a 100% sure that there aren't any other
> >> consequences. (It would be nice to see a notification of a
message
> >> encrypted for another session, and have the ability to drop the
> message
> >> itself, since that has no value to us.)
> >>
> >> 2. I have seen a mismatching padlock icon, compared to the actual
> >> session and the sessions in the "Secure chat" menu. The
> sessions listed
> >> in "Secure chat" menu have always been accurate AFAICT. I have
> not been
> >> able to reproduce it reliably though -- and I'm starting to doubt
> >> whether session selection isn't the culprit.
> >>
> >> 3. About encryption-state mismatches ...
> >>
> >> a) I have NOT been able to get a session that was not actually
> >> encrypted even though Jitsi says it IS encrypted. This in
> itself does
> >> not prove that there isn't an issue, but it's not so easy to
> get into
> >> that state by just clicking buttons (with or without thinking
> about it).
> >>
> >> b) I have been able to send unencrypted messages while an
> encrypted
> >> session was set up. HOWEVER, Jitsi accurately showed an open
> padlock
> >> when sending the message. The reason for this is that I had
> selected the
> >> "root" XMPP session and sent the message via there. If you
> select this
> >> session, Jitsi accurately shows an open padlock and messages
> are sent to
> >> all session (I think). The chat client on the other side
accurately
> >> warns of an unencrypted message being received. If you then
> select one
> >> specific XMPP session in the chat window, the padlock updates
> and indeed
> >> messages are sent in encrypted form.
> >>
> >> As far as I have been able to determine this is all expected
> behaviour.
> >> The root session cannot be OTR-encrypted, since it sends to
> (multiple?)
> >> sessions and you would need to encrypt differently for every
> session. So
> >> you need to select one specific session to send encrypted
> messages. (OTR
> >> also stores a new session instance for each XMPP session.)
> >>
> >> 4. Given the behaviour above, it would be good to somehow warn or
> >> prevent users from selecting the "root" session if multiple
> sessions are
> >> known/active. This should prevent mistakes from being made.
> >>
> >> a) We may need to change the UI so that the "active" session
> (last
> >> message) is selected automatically and users would always need
> to select
> >> a specific session to switch. (And maybe we should not allow
> selecting
> >> this top-most session.)
> >>
> >> ... after some more hours of fiddling around and lots of
confusing
> >> moments ...
> >>
> >> 5. I have now determined that XMPP message carbons can
> interfere with
> >> correctly establishing an encrypted OTR sessions at one of two
> sides. I
> >> am not clear on the details yet (and I am starting to believe
> that this
> >> is a bug in the implementation), but this issue seems to arise
> at the
> >> side where 2 sessions are active and carbons are enabled. (I
> see the
> >> occasional OTR debug log entry about messages meant for another
> session.)
> >>
> >> a) The result is an encrypted OTR session that IS established
> for the
> >> non-problematic side (account with only a single XMPP session).
The
> >> sessions is established fully, and it can send encrypted
> messages. The
> >> other side (2 active XMPP sessions) eventually decides to go with
> >> plaintext and does not expose the encrypted session, even
> though it is
> >> established. It is established because it can decrypt any
received
> >> encrypted messages, however ask the OTR Session-instance for its
> >> SessionStatus and it will return PLAINTEXT. Send a message from
> that
> >> side and it will send a plain text message (not encrypted).
> NOTE that
> >> the padlock icon consistently shows an accurate state.
> >>
> >> 6. Further more, a small issue which may not actually be a
> problem. I
> >> note this here for reference as it may only ever occur if you
> delay the
> >> process by debugging (stepping through code): In the OTR
> plugin, if the
> >> timeout-scheduler isn't cancelled in time, it will set a
> "timeout" state
> >> which is then used and hides the true state of the OTR Session
> instance.
> >>
> >> Reproduction recipe for 5.:
> >> 1. Start some other chat client. Log in the account with server
> support
> >> message carbons, e.g. @jit.si <http://jit.si>. This is going to
> be the shared account.
> >> 2. Start Jitsi. Log in with same account as in 1. Make sure
message
> >> carbons are enabled.
> >> Using Jitsi, log in with another XMPP account.
> >>
> >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
> other client
> >> - with message carbons, 1 solely for Jitsi.
> >>
> >> 3. Use client from 1. initiate OTR-encrypted session with 2.
using
> >> @jit.si <http://jit.si> account
> >> 4. Using client from 1. send message to other XMPP account.
> >> 5. Jitsi popup shows that it received a message. Click popup to
> view
> >> message. Notice that OTR session is established.
> >> 6. In Jitsi, select the other session for this account (@jit.si
> <http://jit.si>) that is
> >> available (which accidentally is the Jitsi client's XMPP session)
> >> 7. Initiate OTR-encrypted session between the 2 accounts, both
> in Jitsi.
> >>
> >> -- Notice that session correctly establishes at initiating
> side, which
> >> is the 1-session XMPP account solely in use by Jitsi.
> >>
> >> 9. Send a message over this newly instantiated OTR session.
> >> 10. Popup shows for newly received message, click and it opens
> a second
> >> tab showing the message received on the shared @jit.si
> <http://jit.si> account.
> >>
> >> -- Notice now that *that* account's OTR-encrypted session was not
> >> recognized. The padlock is open. Sending messages now will send
> them as
> >> plain text. However, it did just receive the encrypted message
and
> >> decrypted it successfully.
> >>
> >> When enabling debug logging in OTR one notices that the
> messages are
> >> indeed encrypted from the side showing the OTR-encrypted
> session, and
> >> plain text for the other side.
> >>
> >> Disabling message carbons fixes the problem described above.
> (At least,
> >> it does for me.)
> >>
> >>
> >> Sorry for making this such a long post. To conclude: I have
> been trying
> >> to get a feel for the state of OTR support in Jitsi. We already
> knew of
> >> some issues with state mangement. I believe these findings may
have
> >> fine-tuned this issue a bit. For now I do not see any big
problems,
> >> especially since the UI always showed an accurate state.
> Confusion is
> >> mostly caused by XMPP's message carbons together with multiple
> active
> >> sessions, which also makes the issues local to the XMPP
> protocol. The
> >> confusion is focused on using the UI, as OTR seems to do the
> right thing
> >> in the background. EXCEPT for this one issue described above
> where the
> >> OTR-encrypted session should have been established at both
> sides. But
> >> even then, Jitsi showed the correct state as the results were
> accordingly.
> >>
> >> So, if you rely on OTR, make sure that your XMPP accounts have
> message
> >> carbons disabled. Then you should have a pretty smooth ride.
> (As far as
> >> I can tell from these tests.)
> >>
> >> Danny
> >>
> >>
> >>
> >>
> >> On 26-01-15 10:50, George Politis wrote:
> >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Quick follow-up. I haven't had as much time as I would've
> liked. I have
> >>>> found out the following things. (in line ...)
> >>>>
> >>>> On 23-01-15 21:34, Danny van Heumen wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Because of recent remarks about OTR support in Jitsi, I've
> been trying
> >>>>> out some cases - all using XMPP as messaging protocol. These
> were
> >>>>> all in
> >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
> accounts also
> >>>>> logged in on Pidgin.
> >>>>>
> >>>>> For now, here's what I've found.
> >>>>>
> >>>>> 1. When using multiple sessions, Jitsi doesn't seem to
correctly
> >>>>> distinguish and discard the messages-for-another-session. I
> quickly
> >>>>> looked at the otr4j source and if I read it correctly, then
> the message
> >>>>> gets returned unchanged. (Only took a quick look, so may not
be
> >>>>> accurate.) In that case the Jitsi client will just show the
> >>>>> base64(encrypted) content. ... at least in this test ...
> (So, send from
> >>>>> Jitsi client to Pidgin client, while Jitsi also connected to
> same
> >>>>> account as Pidgin's is logged on to.)
> >>>> It is just slightly different than I've stated above. It
> turns out that
> >>>> the 2nd session "listening in" (not in the malicious way)
> does not have
> >>>> an OTR session established. So, as a consequence this session
> receives
> >>>> encrypted messages as if they were normal messages.
> >>>>
> >>>> This is likely not an issue in the OTR4J library, but rather
> in Jitsi
> >>>> not including OTR4J, since it isn't enabled. I believe that
> if OTR4J was
> >>>> "in the loop" it would have handled this message. Maybe by
> dropping a
> >>>> system message saying what is happening. Need to look into
> that further.
> >>>>
> >>> There seems to be an issue here. You're talking about
> >>> OtrTransformLayer:149, right? Where this code fragment is
> executed:
> >>>
> >>> f (!policy.getEnableManual()
> >>> && sessionStatus != ScSessionStatus.ENCRYPTED
> >>> && sessionStatus != ScSessionStatus.FINISHED)
> >>> return evt;
> >>>
> >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
> message it
> >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
> at Pidgin
> >>>>> side. (Though javascript doesn't get executed :-P)
> >>>> This one's a bit tricky. We receive a text message which is
> encrypted.
> >>>> Once decrypted, we need to discover whether it is intended as
> HTML or
> >>>> plain text. I'm not sure how another OTR-capable chat client
> makes this
> >>>> distinction, though looking at Pidgin's behaviour, I suspect
> they may
> >>>> simply have assumed HTML. (Otherwise it wouldn't have been as
> simple to
> >>>> inject styling in the message sent to Pidgin client.)
> >>> Other clients, like Miranda, have the exact same problem when
they
> >>> communicate with Pidgin
> (https://developer.pidgin.im/ticket/8453). I
> >>> suppose the messages that Pidgin is sending don't have their
> >>> contentType set correctly, right? In that case, one way to fix
it
> >>> would be to assume HTML if the remote client is Pidgin.
> >>>
> >>>>> 3. Jitsi does not unescape html received from Pidgin. So
> "<dude>" sent
> >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
> >>>> Same as above.
> >>>>> All should be fairly easy to fix.
> >>>> I should've known better ... saying things like that :stuck_out_tongue:
> >>>>
> >>>>> (Assuming Pidgin is the one behaving
> >>>>> as expected, which I am at the moment but will try to check
> before
> >>>>> fixing things in Jitsi.)
> >>>>>
> >>>>> I haven't found a case yet where I get to see the actual
> HTML that is
> >>>>> being sent as was described in
> >>>>>
> http://lists.jitsi.org/pipermail/users/2015-January/008515.html
(if I
> >>>>> understand correctly that is ...)
> >>>> Still same. I have only seen html entities up to now. If
> anyone knows
> >>>> otherwise, plz let me know.
> >>>>
> >>>> As an added bonus I found out that plain text messages aren't
> correctly
> >>>> escaped in the notification popup, so at least that's fixed
> now :slight_smile:
> >>>>
> >>>> Danny
> >>>>
> >>>>> Danny
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> dev mailing list
> >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>>>> Unsubscribe instructions and other list options:
> >>>>> http://lists.jitsi.org/mailman/listinfo/dev
> >>>> _______________________________________________
> >>>> dev mailing list
> >>>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>>> Unsubscribe instructions and other list options:
> >>>> http://lists.jitsi.org/mailman/listinfo/dev
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev@jitsi.org <mailto:dev@jitsi.org>
> >>> Unsubscribe instructions and other list options:
> >>> http://lists.jitsi.org/mailman/listinfo/dev
> >>
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev@jitsi.org <mailto:dev@jitsi.org>
> >> Unsubscribe instructions and other list options:
> >> http://lists.jitsi.org/mailman/listinfo/dev
> >
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org <mailto:dev@jitsi.org>
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#17

Hi Marin,

Thanks for these clarifications.

Hi Danny,

    As I understand it now, that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

That is completely correct. Or at least it is supposed to work that way.

Okay, so the relation between outgoingSession and the slaveSessions
collection wasn't obvious to me at first. That was also what added to
the confusion. (Of course the root cause was in the missing UI parts.)

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

Also correct. Please look at
the net.java.sip.communicator.plugin.otr.authdialog.OTRv3OutgoingSessionSwitcher class.
If I recall correctly, one could also use the Secure Chat menu in
order to switch between slave sessions but I'm not completely sure
about that.

Yeah, I believe there's an menu item "Select" there, so I guess that
would select other slave sessions. I haven't found an alternative for
the menu on the right, though.

     None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

Since an incoming message gets decrypted that means you have a slave
session in ENCRYPTED state which is good - otr was established. All
incoming messages will get decrypted correctly. But you can use this
slave session to encrypt outgoing messages aswell. You just have to
select it. An open padlock means that the slave session is not
currently selected, or better said - the current outgoing session is
in PLAINTEXT state.

Yup.

    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

Yes, correct. Also, please note that with the current implementation
you could never establish ENCRYPTED session with the bare jid. That's
because jids are mapped to instance id's (or sth like that). So even
if one Jitsi client (Alice) tries to send an OTR initiation request to
his buddy (Bob) using his Bob's bare jid, what happens is that
actually when Bob receives Alice's message he'll respond with his
actual JID. Then, when Alice receive Bob's response she'll create a
slave session since Bob's response doesn't come from a bare jid but
from an actual one. I hope that makes sense.

Yeah, this part is clear. Since the bare jid isn't an exact address you
cannot map it to exactly one OTR session. This is clear and obvious to me.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

Yes, you are!
Thank you very much for the effort. I know from experience how
frustrating that could be. Debugging OTR issues in combination with
XMPP is very exhausting as it may often seem indeterministic.

Well, yeah, at it's mainly XMPP that is confusing. Actually the OTR part
was always the more obvious part, except of course for the interaction
between the slave sessions and outgoing session.

Danny

···

On 27-02-15 08:08, Marin Dzhigarov wrote:

Best regards,
Marin

On Thu, Feb 26, 2015 at 9:56 PM, Danny van Heumen > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi Marin,

    Thanks for your quite detailed response. I'll add my comments in-line.
    Hopefully that clarifies what I think my issue is about.

    On 26-02-15 14:06, Marin Dzhigarov wrote:
    > Hello Danny,
    >
    > Thank you for your findings but...
    >
    > RESULT:
    > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > 2. Fully established ENCRYPTED slave session. Will be reachable
    > for decrypting messages, however it is completely off-the-radar
    > when querying the status of a session.
    > 3. Received messages get routed by their sender instance ID and
    > arrive at the slave session, get processed appropriately and
    hence
    > get returned decrypted to Jitsi.
    > 4. Sent messages get sent in plain text according to the Master
    > session's status. Client at other end will received a plain text
    > message even though it has an OTR session established.
    >
    >
    > I still don't see anything wrong with this behaviour. Actually, I
    > implemented it that way so I'm glad it's still working :smiley:
    > You can use the icon in the left-down corner in order to switch
    > between carbons. When you do, the "active" carbon is going to change
    > and you will see that the padlock is closed. (Or at least it should
    > work that way if I remember correctly).
    So, when I'm talking about carbons, I'm referring to the actual
    messages
    themselves being replicated to other clients of the same account. I am
    assuming here that you mean the various "sessions", one session
    for each
    of the logged in clients of that account, right?

    So, after the session is established, I can indeed switch these
    sessions
    using that drop down menu. None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

    > Addionally, you may have an icon in the right-down corner that
    > switches between active slave sessions but I don't remember the
    > details for that one. So you might end up having to choose between a
    > combination of [carbon - otr session] from the two down corners in
    > order to send proper messages.
    I have not found this right-bottom menu. Never seen it as far as I can
    remember.

    I think this might be related to my issue. As I understand it now,
    that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

    > I remember that I also put some logic so that Jitsi can automacally
    > switch between carbons (down-left icon) depending on the received
    > message. The idea was that if one receives a message from a certain
    > jid, the default carbon and thus the active otr slave session
    (used to
    > encrypt outgoing messages) is switched.
    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

    >
    > ​
    >
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    >
    > Also, again if I remember correctly, there is no way to have an
    > ENCRYPTED master session because master sessions delegate session
    > initiation requests to slave sessions.
    Okay, sure, that makes sense. I did check logging I produce and it
    shows
    that the same session instance that had old status 'plaintext' and new
    status 'encrypted' has isMasterSession == true. So it seems that
    this is
    possible.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

    I'm going to look into getting these slave sessions to the surface ...

    Danny

    > ​
    >
    > I hope that helps.
    >
    > Best regards,
    > Marin
    >
    > On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> > <mailto:danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>>> > wrote:
    >
    >
    > A quick addition ... I was thinking about which combinations are
    > possible for Master - Slave session combinations.
    >
    > * Master session: PLAINTEXT + Slave session: ENCRYPTED --
    possible as
    > this is the current problem.
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    > * Both PLAINTEXT shouldn't be an issue in any case, i.e. no
    encrypted
    > sessions established.
    >
    > * Both ENCRYPTED: not sure if this makes sense, but in any
    case we
    > would
    > sent an encrypted message. It might get delivered to the wrong
    > address,
    > but it wouldn't unintentionally be sent PLAINTEXT, so not an
    issue(?)
    >
    > Danny
    >
    >
    >
    > On 25-02-15 23:43, Danny van Heumen wrote:
    > > Hi all,
    > >
    > > So, here's another follow up with what I found out
    yesterday. I
    > think
    > > I may have an explanation of what happens. It's pretty
    interesting
    > > interplay of features, I think ...
    > >
    > > A FEW FACTS:
    > > * When message carbons are activated, the messages sent by one
    > client
    > > are repeated to the other clients as message delivered
    events. (I'm
    > > quite sure, but please correct me if I'm wrong here ...)
    > > * Jitsi's OTR implementation does not process message
    delivered
    > > events. (The only exception to this is to check if a
    message is
    > > injected such that the user is not bothered with OTR
    interaction
    > > inside the client.)
    > > * I found out that the session status gets updated in another
    > instance
    > > of SessionImpl than where the instance where we query for the
    > current
    > > session status. This explains both:
    > >
    > > 1. Why the statuses deviate - between session
    establishment (in log
    > > messages) and session status querying, and
    > > 2. Why messages till get decrypted when received even
    though the
    > > status is PLAINTEXT.
    > >
    > > FLOW OF EVENTS: Here's where it gets interesting ...
    > >
    > > Say we have:
    > > * An account a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> on server jit.si <http://jit.si>
    > <http://jit.si> which supports message carbons.
    > > * An account b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> on server
    > gmail.com <http://gmail.com> <http://gmail.com> which does
    not support
    > > message carbons.
    > > * Client A, a Jitsi client, with account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - with message
    > > carbons enabled - and account b@gmail.com
    <mailto:b@gmail.com> <mailto:b@gmail.com <mailto:b@gmail.com>>.
    > > * Client B, another client with account a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - without message
    > > carbons enabled.
    > >
    > > 1. We initiate an OTR session with client A to account
    > b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>.
    > > This means that B sends the OTR v3 query message.
    > > -- a) client A receives the request on account b@gmail.com
    <mailto:b@gmail.com>
    > <mailto:b@gmail.com <mailto:b@gmail.com>>
    > > -- b) client A receives a carbon of the request on a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>. This
    > > message isn't processed by otr4j, so effectively gets ignored.
    > >
    > > 2. Client A receives OTR v3 query message, answers with
    D-H commit
    > > message.
    > > -- a) client B receives the request on account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>.
    > > -- b) client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives the message
    > carbon and sets a master
    > > session for this sender instance id, however it does not
    expect the
    > > D-H commit message so does not respond.
    > >
    > > 3. Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>) and client B
    > (b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>) finish up OTR
    > > protocol and establish a secure session.
    > >
    > > Now Client A (b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>>) wants to
    > establish an OTR session with
    > > Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>), so it sends initial OTR
    > v3 query message.
    > >
    > > 4. Client A on b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> sends message to
    > a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> for client A
    > > (that is, that specific session id).
    > > -- a) Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives this message,
    > however it contains a
    > > different sender instance id than the message before, so a
    slave
    > > session is established. The received message gets passed
    through to
    > > slave session. Slave session handles message.
    > >
    > > 5. Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> responds and continues
    > establishing OTR encrypted
    > > session. Now Client A a@jit.si <mailto:a@jit.si>
    <mailto:a@jit.si <mailto:a@jit.si>> has 2 sessions
    > available:
    > > * Master session: PLAINTEXT, received some OTR messages but
    > nothing to
    > > establish a connection with.
    > > * Slave session: ENCRYPTED, did full processing of OTR session
    > > establishment and has a full, completed ENCRYPTED session.
    > >
    > > Now that an encrypted session is established, we call
    listeners to
    > > inform of a sessionStatusChanged(OtrContact). However, a
    call of
    > > getStatus(SessionID for OtrContact) will return the session
    > status of
    > > the MASTER session, which is plain text, since it was
    based upon the
    > > message carbons.
    > >
    > > RESULT:
    > >
    > > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > > 2. Fully established ENCRYPTED slave session. Will be
    reachable for
    > > decrypting messages, however it is completely
    off-the-radar when
    > > querying the status of a session.
    > > 3. Received messages get routed by their sender instance
    ID and
    > arrive
    > > at the slave session, get processed appropriately and
    hence get
    > > returned decrypted to Jitsi.
    > > 4. Sent messages get sent in plain text according to the
    Master
    > > session's status. Client at other end will received a
    plain text
    > > message even though it has an OTR session established.
    > >
    > > I hope this makes sense. It is a bit late, so please be
    critical and
    > > check if everything makes sense. I can clarify if there
    are any
    > > questions. (Or replay the problem and/or recheck the logging.)
    > >
    > > Assuming the above is correct, this would also explain my
    earlier
    > > comment regarding disabling message carbons. This would indeed
    > prevent
    > > establishing the early Master session, hence when the OTR
    session is
    > > deliberately initiated, this would become the Master
    session and one
    > > would indeed get the correct Session Status when queried via
    > > getStatus(SessionID).
    > >
    > > So, if this correctly establishes the problem, I am quite
    interested
    > > in how we're going to solve this one. I haven't thought about
    > this one
    > > yet ... :slight_smile:
    > >
    > > Regards,
    > > Danny
    > >
    > >
    > >
    > > On 22-02-15 21:18, Danny van Heumen wrote:
    > >> Okay, so it's time for an update on this topic ...
    > >>
    > >> @George: In case of TL;DR, could you check my commit, just to
    > be sure?
    > >>
    >
     https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
    > >> It's about removing the conditionals so any message
    reaches the
    > otr4j
    > >> library, even if a secure session is not established yet.
    > Basically what
    > >> you suggested before.
    > >> Also, can you explain why at SessionImpl:479 (call to
    > >> setSessionStatus(ENCRYPTED)) the called method resets auth
    > (AuthContext)
    > >> to setIsSecure(false), while the passed parameter is
    > >> SessionStatus.ENCRYPTED? (It may be completely fine, but
    it seems
    > >> contradictory.)
    > >>
    > >> I've been playing around with the whole OTR UI and plugin to
    > see what I
    > >> could discover apart from the stuff we already know. I have
    > been playing
    > >> around for a few hours and this is a quick report of what
    I've
    > been able
    > >> to discover.
    > >>
    > >> 1. The raw OTR-encrypted message I received as described
    below,
    > is due
    > >> to XMPP Carbons being enabled. We receive the message
    sent from
    > another
    > >> client (same account) and we subscribed to carbon copies,
    so we
    > receive
    > >> a carbon of the raw message. This particular message flow is
    > not hooked
    > >> into otr4j, so it gets shown as a plain old message. (@fippo:
    > Thanks for
    > >> pointing out the carbons!)
    > >>
    > >> a) I'm thinking of whether or not we *can* hook that into
    > otr4j. Maybe
    > >> we can process this as a "received" message. I have not done
    > that yet,
    > >> though, because I'm not a 100% sure that there aren't any
    other
    > >> consequences. (It would be nice to see a notification of
    a message
    > >> encrypted for another session, and have the ability to
    drop the
    > message
    > >> itself, since that has no value to us.)
    > >>
    > >> 2. I have seen a mismatching padlock icon, compared to
    the actual
    > >> session and the sessions in the "Secure chat" menu. The
    > sessions listed
    > >> in "Secure chat" menu have always been accurate AFAICT. I
    have
    > not been
    > >> able to reproduce it reliably though -- and I'm starting
    to doubt
    > >> whether session selection isn't the culprit.
    > >>
    > >> 3. About encryption-state mismatches ...
    > >>
    > >> a) I have NOT been able to get a session that was not
    actually
    > >> encrypted even though Jitsi says it IS encrypted. This in
    > itself does
    > >> not prove that there isn't an issue, but it's not so easy to
    > get into
    > >> that state by just clicking buttons (with or without thinking
    > about it).
    > >>
    > >> b) I have been able to send unencrypted messages while an
    > encrypted
    > >> session was set up. HOWEVER, Jitsi accurately showed an open
    > padlock
    > >> when sending the message. The reason for this is that I had
    > selected the
    > >> "root" XMPP session and sent the message via there. If you
    > select this
    > >> session, Jitsi accurately shows an open padlock and messages
    > are sent to
    > >> all session (I think). The chat client on the other side
    accurately
    > >> warns of an unencrypted message being received. If you then
    > select one
    > >> specific XMPP session in the chat window, the padlock updates
    > and indeed
    > >> messages are sent in encrypted form.
    > >>
    > >> As far as I have been able to determine this is all expected
    > behaviour.
    > >> The root session cannot be OTR-encrypted, since it sends to
    > (multiple?)
    > >> sessions and you would need to encrypt differently for every
    > session. So
    > >> you need to select one specific session to send encrypted
    > messages. (OTR
    > >> also stores a new session instance for each XMPP session.)
    > >>
    > >> 4. Given the behaviour above, it would be good to somehow
    warn or
    > >> prevent users from selecting the "root" session if multiple
    > sessions are
    > >> known/active. This should prevent mistakes from being made.
    > >>
    > >> a) We may need to change the UI so that the "active"
    session
    > (last
    > >> message) is selected automatically and users would always
    need
    > to select
    > >> a specific session to switch. (And maybe we should not allow
    > selecting
    > >> this top-most session.)
    > >>
    > >> ... after some more hours of fiddling around and lots of
    confusing
    > >> moments ...
    > >>
    > >> 5. I have now determined that XMPP message carbons can
    > interfere with
    > >> correctly establishing an encrypted OTR sessions at one
    of two
    > sides. I
    > >> am not clear on the details yet (and I am starting to believe
    > that this
    > >> is a bug in the implementation), but this issue seems to
    arise
    > at the
    > >> side where 2 sessions are active and carbons are enabled. (I
    > see the
    > >> occasional OTR debug log entry about messages meant for
    another
    > session.)
    > >>
    > >> a) The result is an encrypted OTR session that IS
    established
    > for the
    > >> non-problematic side (account with only a single XMPP
    session). The
    > >> sessions is established fully, and it can send encrypted
    > messages. The
    > >> other side (2 active XMPP sessions) eventually decides to
    go with
    > >> plaintext and does not expose the encrypted session, even
    > though it is
    > >> established. It is established because it can decrypt any
    received
    > >> encrypted messages, however ask the OTR Session-instance
    for its
    > >> SessionStatus and it will return PLAINTEXT. Send a
    message from
    > that
    > >> side and it will send a plain text message (not encrypted).
    > NOTE that
    > >> the padlock icon consistently shows an accurate state.
    > >>
    > >> 6. Further more, a small issue which may not actually be a
    > problem. I
    > >> note this here for reference as it may only ever occur if you
    > delay the
    > >> process by debugging (stepping through code): In the OTR
    > plugin, if the
    > >> timeout-scheduler isn't cancelled in time, it will set a
    > "timeout" state
    > >> which is then used and hides the true state of the OTR
    Session
    > instance.
    > >>
    > >> Reproduction recipe for 5.:
    > >> 1. Start some other chat client. Log in the account with
    server
    > support
    > >> message carbons, e.g. @jit.si <http://jit.si>
    <http://jit.si>. This is going to
    > be the shared account.
    > >> 2. Start Jitsi. Log in with same account as in 1. Make
    sure message
    > >> carbons are enabled.
    > >> Using Jitsi, log in with another XMPP account.
    > >>
    > >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
    > other client
    > >> - with message carbons, 1 solely for Jitsi.
    > >>
    > >> 3. Use client from 1. initiate OTR-encrypted session with
    2. using
    > >> @jit.si <http://jit.si> <http://jit.si> account
    > >> 4. Using client from 1. send message to other XMPP account.
    > >> 5. Jitsi popup shows that it received a message. Click
    popup to
    > view
    > >> message. Notice that OTR session is established.
    > >> 6. In Jitsi, select the other session for this account
    (@jit.si <http://jit.si>
    > <http://jit.si>) that is
    > >> available (which accidentally is the Jitsi client's XMPP session)
    > >> 7. Initiate OTR-encrypted session between the 2 accounts,
    both
    > in Jitsi.
    > >>
    > >> -- Notice that session correctly establishes at initiating
    > side, which
    > >> is the 1-session XMPP account solely in use by Jitsi.
    > >>
    > >> 9. Send a message over this newly instantiated OTR session.
    > >> 10. Popup shows for newly received message, click and it
    opens
    > a second
    > >> tab showing the message received on the shared @jit.si
    <http://jit.si>
    > <http://jit.si> account.
    > >>
    > >> -- Notice now that *that* account's OTR-encrypted session
    was not
    > >> recognized. The padlock is open. Sending messages now
    will send
    > them as
    > >> plain text. However, it did just receive the encrypted
    message and
    > >> decrypted it successfully.
    > >>
    > >> When enabling debug logging in OTR one notices that the
    > messages are
    > >> indeed encrypted from the side showing the OTR-encrypted
    > session, and
    > >> plain text for the other side.
    > >>
    > >> Disabling message carbons fixes the problem described above.
    > (At least,
    > >> it does for me.)
    > >>
    > >>
    > >> Sorry for making this such a long post. To conclude: I have
    > been trying
    > >> to get a feel for the state of OTR support in Jitsi. We
    already
    > knew of
    > >> some issues with state mangement. I believe these
    findings may have
    > >> fine-tuned this issue a bit. For now I do not see any big
    problems,
    > >> especially since the UI always showed an accurate state.
    > Confusion is
    > >> mostly caused by XMPP's message carbons together with
    multiple
    > active
    > >> sessions, which also makes the issues local to the XMPP
    > protocol. The
    > >> confusion is focused on using the UI, as OTR seems to do the
    > right thing
    > >> in the background. EXCEPT for this one issue described above
    > where the
    > >> OTR-encrypted session should have been established at both
    > sides. But
    > >> even then, Jitsi showed the correct state as the results were
    > accordingly.
    > >>
    > >> So, if you rely on OTR, make sure that your XMPP accounts
    have
    > message
    > >> carbons disabled. Then you should have a pretty smooth ride.
    > (As far as
    > >> I can tell from these tests.)
    > >>
    > >> Danny
    > >>
    > >>
    > >>
    > >>
    > >> On 26-01-15 10:50, George Politis wrote:
    > >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
    > >>>
    > >>>> Hi all,
    > >>>>
    > >>>> Quick follow-up. I haven't had as much time as I would've
    > liked. I have
    > >>>> found out the following things. (in line ...)
    > >>>>
    > >>>> On 23-01-15 21:34, Danny van Heumen wrote:
    > >>>>> Hi all,
    > >>>>>
    > >>>>> Because of recent remarks about OTR support in Jitsi, I've
    > been trying
    > >>>>> out some cases - all using XMPP as messaging protocol.
    These
    > were
    > >>>>> all in
    > >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
    > accounts also
    > >>>>> logged in on Pidgin.
    > >>>>>
    > >>>>> For now, here's what I've found.
    > >>>>>
    > >>>>> 1. When using multiple sessions, Jitsi doesn't seem to
    correctly
    > >>>>> distinguish and discard the
    messages-for-another-session. I
    > quickly
    > >>>>> looked at the otr4j source and if I read it correctly,
    then
    > the message
    > >>>>> gets returned unchanged. (Only took a quick look, so
    may not be
    > >>>>> accurate.) In that case the Jitsi client will just
    show the
    > >>>>> base64(encrypted) content. ... at least in this test ...
    > (So, send from
    > >>>>> Jitsi client to Pidgin client, while Jitsi also
    connected to
    > same
    > >>>>> account as Pidgin's is logged on to.)
    > >>>> It is just slightly different than I've stated above. It
    > turns out that
    > >>>> the 2nd session "listening in" (not in the malicious way)
    > does not have
    > >>>> an OTR session established. So, as a consequence this
    session
    > receives
    > >>>> encrypted messages as if they were normal messages.
    > >>>>
    > >>>> This is likely not an issue in the OTR4J library, but
    rather
    > in Jitsi
    > >>>> not including OTR4J, since it isn't enabled. I believe that
    > if OTR4J was
    > >>>> "in the loop" it would have handled this message. Maybe by
    > dropping a
    > >>>> system message saying what is happening. Need to look into
    > that further.
    > >>>>
    > >>> There seems to be an issue here. You're talking about
    > >>> OtrTransformLayer:149, right? Where this code fragment is
    > executed:
    > >>>
    > >>> f (!policy.getEnableManual()
    > >>> && sessionStatus != ScSessionStatus.ENCRYPTED
    > >>> && sessionStatus != ScSessionStatus.FINISHED)
    > >>> return evt;
    > >>>
    > >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
    > message it
    > >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
    > at Pidgin
    > >>>>> side. (Though javascript doesn't get executed :-P)
    > >>>> This one's a bit tricky. We receive a text message which is
    > encrypted.
    > >>>> Once decrypted, we need to discover whether it is
    intended as
    > HTML or
    > >>>> plain text. I'm not sure how another OTR-capable chat
    client
    > makes this
    > >>>> distinction, though looking at Pidgin's behaviour, I
    suspect
    > they may
    > >>>> simply have assumed HTML. (Otherwise it wouldn't have
    been as
    > simple to
    > >>>> inject styling in the message sent to Pidgin client.)
    > >>> Other clients, like Miranda, have the exact same problem
    when they
    > >>> communicate with Pidgin
    > (https://developer.pidgin.im/ticket/8453). I
    > >>> suppose the messages that Pidgin is sending don't have their
    > >>> contentType set correctly, right? In that case, one way
    to fix it
    > >>> would be to assume HTML if the remote client is Pidgin.
    > >>>
    > >>>>> 3. Jitsi does not unescape html received from Pidgin. So
    > "<dude>" sent
    > >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
    > >>>> Same as above.
    > >>>>> All should be fairly easy to fix.
    > >>>> I should've known better ... saying things like that :stuck_out_tongue:
    > >>>>
    > >>>>> (Assuming Pidgin is the one behaving
    > >>>>> as expected, which I am at the moment but will try to
    check
    > before
    > >>>>> fixing things in Jitsi.)
    > >>>>>
    > >>>>> I haven't found a case yet where I get to see the actual
    > HTML that is
    > >>>>> being sent as was described in
    > >>>>>
    >
     http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
    > >>>>> understand correctly that is ...)
    > >>>> Still same. I have only seen html entities up to now. If
    > anyone knows
    > >>>> otherwise, plz let me know.
    > >>>>
    > >>>> As an added bonus I found out that plain text messages
    aren't
    > correctly
    > >>>> escaped in the notification popup, so at least that's fixed
    > now :slight_smile:
    > >>>>
    > >>>> Danny
    > >>>>
    > >>>>> Danny
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>> _______________________________________________
    > >>>>> dev mailing list
    > >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>>> Unsubscribe instructions and other list options:
    > >>>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>>> _______________________________________________
    > >>>> dev mailing list
    > >>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>> Unsubscribe instructions and other list options:
    > >>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>> _______________________________________________
    > >>> dev mailing list
    > >>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>> Unsubscribe instructions and other list options:
    > >>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>
    > >>
    > >> _______________________________________________
    > >> dev mailing list
    > >> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >> Unsubscribe instructions and other list options:
    > >> http://lists.jitsi.org/mailman/listinfo/dev
    > >
    > >
    > >
    > > _______________________________________________
    > > dev mailing list
    > > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > > Unsubscribe instructions and other list options:
    > > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#18

Hi Marin and others,

Okay, so I think I've pinpointed the cause ... ... that is, with
emphasis on *think* here :stuck_out_tongue:

It seems that multiple instances aren't recognized, because
OTRv3OutgoingSessionSwitcher does not get updates w.r.t. selected
session (chat transport changes). The method
'OTRv3OutgoingSessionSwitcher#setCurrentContact(contact, resourceName)'
never gets called. As a result, only the contact is ever known, so you
get a different session which does not contain the instances. (So
dude@jit.si, instead of dude@jit.si/jitsi-a3e89f.)

Just to be clear, '#setContact(contact)' is called. But that doesn't
specify the resource, so it becomes too general and points to a
different session.

'MainToolBar#currentChatTransportChanged' should call the instance of
OTRv3OutgoingSessionSwitcher, but it isn't registered as this type of
plugin component. I think I'm quite close to the solution, but currently
I'm trying to figure out on-the-fly how UI component plugins work, so
I'm not quite there yet. Any help would be appreciated.

Once this is fixed, it should also again show the OTR instances menu at
appropriate times.

Danny

···

On 27-02-15 08:08, Marin Dzhigarov wrote:

Hi Danny,

    As I understand it now, that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

That is completely correct. Or at least it is supposed to work that way.

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

Also correct. Please look at
the net.java.sip.communicator.plugin.otr.authdialog.OTRv3OutgoingSessionSwitcher class.
If I recall correctly, one could also use the Secure Chat menu in
order to switch between slave sessions but I'm not completely sure
about that.

     None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

Since an incoming message gets decrypted that means you have a slave
session in ENCRYPTED state which is good - otr was established. All
incoming messages will get decrypted correctly. But you can use this
slave session to encrypt outgoing messages aswell. You just have to
select it. An open padlock means that the slave session is not
currently selected, or better said - the current outgoing session is
in PLAINTEXT state.

    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

Yes, correct. Also, please note that with the current implementation
you could never establish ENCRYPTED session with the bare jid. That's
because jids are mapped to instance id's (or sth like that). So even
if one Jitsi client (Alice) tries to send an OTR initiation request to
his buddy (Bob) using his Bob's bare jid, what happens is that
actually when Bob receives Alice's message he'll respond with his
actual JID. Then, when Alice receive Bob's response she'll create a
slave session since Bob's response doesn't come from a bare jid but
from an actual one. I hope that makes sense.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

Yes, you are!
Thank you very much for the effort. I know from experience how
frustrating that could be. Debugging OTR issues in combination with
XMPP is very exhausting as it may often seem indeterministic.

Best regards,
Marin

On Thu, Feb 26, 2015 at 9:56 PM, Danny van Heumen > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi Marin,

    Thanks for your quite detailed response. I'll add my comments in-line.
    Hopefully that clarifies what I think my issue is about.

    On 26-02-15 14:06, Marin Dzhigarov wrote:
    > Hello Danny,
    >
    > Thank you for your findings but...
    >
    > RESULT:
    > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > 2. Fully established ENCRYPTED slave session. Will be reachable
    > for decrypting messages, however it is completely off-the-radar
    > when querying the status of a session.
    > 3. Received messages get routed by their sender instance ID and
    > arrive at the slave session, get processed appropriately and
    hence
    > get returned decrypted to Jitsi.
    > 4. Sent messages get sent in plain text according to the Master
    > session's status. Client at other end will received a plain text
    > message even though it has an OTR session established.
    >
    >
    > I still don't see anything wrong with this behaviour. Actually, I
    > implemented it that way so I'm glad it's still working :smiley:
    > You can use the icon in the left-down corner in order to switch
    > between carbons. When you do, the "active" carbon is going to change
    > and you will see that the padlock is closed. (Or at least it should
    > work that way if I remember correctly).
    So, when I'm talking about carbons, I'm referring to the actual
    messages
    themselves being replicated to other clients of the same account. I am
    assuming here that you mean the various "sessions", one session
    for each
    of the logged in clients of that account, right?

    So, after the session is established, I can indeed switch these
    sessions
    using that drop down menu. None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

    > Addionally, you may have an icon in the right-down corner that
    > switches between active slave sessions but I don't remember the
    > details for that one. So you might end up having to choose between a
    > combination of [carbon - otr session] from the two down corners in
    > order to send proper messages.
    I have not found this right-bottom menu. Never seen it as far as I can
    remember.

    I think this might be related to my issue. As I understand it now,
    that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

    > I remember that I also put some logic so that Jitsi can automacally
    > switch between carbons (down-left icon) depending on the received
    > message. The idea was that if one receives a message from a certain
    > jid, the default carbon and thus the active otr slave session
    (used to
    > encrypt outgoing messages) is switched.
    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

    >
    > ​
    >
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    >
    > Also, again if I remember correctly, there is no way to have an
    > ENCRYPTED master session because master sessions delegate session
    > initiation requests to slave sessions.
    Okay, sure, that makes sense. I did check logging I produce and it
    shows
    that the same session instance that had old status 'plaintext' and new
    status 'encrypted' has isMasterSession == true. So it seems that
    this is
    possible.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

    I'm going to look into getting these slave sessions to the surface ...

    Danny

    > ​
    >
    > I hope that helps.
    >
    > Best regards,
    > Marin
    >
    > On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen > > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> > <mailto:danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>>> > wrote:
    >
    >
    > A quick addition ... I was thinking about which combinations are
    > possible for Master - Slave session combinations.
    >
    > * Master session: PLAINTEXT + Slave session: ENCRYPTED --
    possible as
    > this is the current problem.
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    > * Both PLAINTEXT shouldn't be an issue in any case, i.e. no
    encrypted
    > sessions established.
    >
    > * Both ENCRYPTED: not sure if this makes sense, but in any
    case we
    > would
    > sent an encrypted message. It might get delivered to the wrong
    > address,
    > but it wouldn't unintentionally be sent PLAINTEXT, so not an
    issue(?)
    >
    > Danny
    >
    >
    >
    > On 25-02-15 23:43, Danny van Heumen wrote:
    > > Hi all,
    > >
    > > So, here's another follow up with what I found out
    yesterday. I
    > think
    > > I may have an explanation of what happens. It's pretty
    interesting
    > > interplay of features, I think ...
    > >
    > > A FEW FACTS:
    > > * When message carbons are activated, the messages sent by one
    > client
    > > are repeated to the other clients as message delivered
    events. (I'm
    > > quite sure, but please correct me if I'm wrong here ...)
    > > * Jitsi's OTR implementation does not process message
    delivered
    > > events. (The only exception to this is to check if a
    message is
    > > injected such that the user is not bothered with OTR
    interaction
    > > inside the client.)
    > > * I found out that the session status gets updated in another
    > instance
    > > of SessionImpl than where the instance where we query for the
    > current
    > > session status. This explains both:
    > >
    > > 1. Why the statuses deviate - between session
    establishment (in log
    > > messages) and session status querying, and
    > > 2. Why messages till get decrypted when received even
    though the
    > > status is PLAINTEXT.
    > >
    > > FLOW OF EVENTS: Here's where it gets interesting ...
    > >
    > > Say we have:
    > > * An account a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> on server jit.si <http://jit.si>
    > <http://jit.si> which supports message carbons.
    > > * An account b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> on server
    > gmail.com <http://gmail.com> <http://gmail.com> which does
    not support
    > > message carbons.
    > > * Client A, a Jitsi client, with account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - with message
    > > carbons enabled - and account b@gmail.com
    <mailto:b@gmail.com> <mailto:b@gmail.com <mailto:b@gmail.com>>.
    > > * Client B, another client with account a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - without message
    > > carbons enabled.
    > >
    > > 1. We initiate an OTR session with client A to account
    > b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>.
    > > This means that B sends the OTR v3 query message.
    > > -- a) client A receives the request on account b@gmail.com
    <mailto:b@gmail.com>
    > <mailto:b@gmail.com <mailto:b@gmail.com>>
    > > -- b) client A receives a carbon of the request on a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>. This
    > > message isn't processed by otr4j, so effectively gets ignored.
    > >
    > > 2. Client A receives OTR v3 query message, answers with
    D-H commit
    > > message.
    > > -- a) client B receives the request on account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>.
    > > -- b) client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives the message
    > carbon and sets a master
    > > session for this sender instance id, however it does not
    expect the
    > > D-H commit message so does not respond.
    > >
    > > 3. Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>) and client B
    > (b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>) finish up OTR
    > > protocol and establish a secure session.
    > >
    > > Now Client A (b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>>) wants to
    > establish an OTR session with
    > > Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>), so it sends initial OTR
    > v3 query message.
    > >
    > > 4. Client A on b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> sends message to
    > a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> for client A
    > > (that is, that specific session id).
    > > -- a) Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives this message,
    > however it contains a
    > > different sender instance id than the message before, so a
    slave
    > > session is established. The received message gets passed
    through to
    > > slave session. Slave session handles message.
    > >
    > > 5. Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> responds and continues
    > establishing OTR encrypted
    > > session. Now Client A a@jit.si <mailto:a@jit.si>
    <mailto:a@jit.si <mailto:a@jit.si>> has 2 sessions
    > available:
    > > * Master session: PLAINTEXT, received some OTR messages but
    > nothing to
    > > establish a connection with.
    > > * Slave session: ENCRYPTED, did full processing of OTR session
    > > establishment and has a full, completed ENCRYPTED session.
    > >
    > > Now that an encrypted session is established, we call
    listeners to
    > > inform of a sessionStatusChanged(OtrContact). However, a
    call of
    > > getStatus(SessionID for OtrContact) will return the session
    > status of
    > > the MASTER session, which is plain text, since it was
    based upon the
    > > message carbons.
    > >
    > > RESULT:
    > >
    > > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > > 2. Fully established ENCRYPTED slave session. Will be
    reachable for
    > > decrypting messages, however it is completely
    off-the-radar when
    > > querying the status of a session.
    > > 3. Received messages get routed by their sender instance
    ID and
    > arrive
    > > at the slave session, get processed appropriately and
    hence get
    > > returned decrypted to Jitsi.
    > > 4. Sent messages get sent in plain text according to the
    Master
    > > session's status. Client at other end will received a
    plain text
    > > message even though it has an OTR session established.
    > >
    > > I hope this makes sense. It is a bit late, so please be
    critical and
    > > check if everything makes sense. I can clarify if there
    are any
    > > questions. (Or replay the problem and/or recheck the logging.)
    > >
    > > Assuming the above is correct, this would also explain my
    earlier
    > > comment regarding disabling message carbons. This would indeed
    > prevent
    > > establishing the early Master session, hence when the OTR
    session is
    > > deliberately initiated, this would become the Master
    session and one
    > > would indeed get the correct Session Status when queried via
    > > getStatus(SessionID).
    > >
    > > So, if this correctly establishes the problem, I am quite
    interested
    > > in how we're going to solve this one. I haven't thought about
    > this one
    > > yet ... :slight_smile:
    > >
    > > Regards,
    > > Danny
    > >
    > >
    > >
    > > On 22-02-15 21:18, Danny van Heumen wrote:
    > >> Okay, so it's time for an update on this topic ...
    > >>
    > >> @George: In case of TL;DR, could you check my commit, just to
    > be sure?
    > >>
    >
     https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
    > >> It's about removing the conditionals so any message
    reaches the
    > otr4j
    > >> library, even if a secure session is not established yet.
    > Basically what
    > >> you suggested before.
    > >> Also, can you explain why at SessionImpl:479 (call to
    > >> setSessionStatus(ENCRYPTED)) the called method resets auth
    > (AuthContext)
    > >> to setIsSecure(false), while the passed parameter is
    > >> SessionStatus.ENCRYPTED? (It may be completely fine, but
    it seems
    > >> contradictory.)
    > >>
    > >> I've been playing around with the whole OTR UI and plugin to
    > see what I
    > >> could discover apart from the stuff we already know. I have
    > been playing
    > >> around for a few hours and this is a quick report of what
    I've
    > been able
    > >> to discover.
    > >>
    > >> 1. The raw OTR-encrypted message I received as described
    below,
    > is due
    > >> to XMPP Carbons being enabled. We receive the message
    sent from
    > another
    > >> client (same account) and we subscribed to carbon copies,
    so we
    > receive
    > >> a carbon of the raw message. This particular message flow is
    > not hooked
    > >> into otr4j, so it gets shown as a plain old message. (@fippo:
    > Thanks for
    > >> pointing out the carbons!)
    > >>
    > >> a) I'm thinking of whether or not we *can* hook that into
    > otr4j. Maybe
    > >> we can process this as a "received" message. I have not done
    > that yet,
    > >> though, because I'm not a 100% sure that there aren't any
    other
    > >> consequences. (It would be nice to see a notification of
    a message
    > >> encrypted for another session, and have the ability to
    drop the
    > message
    > >> itself, since that has no value to us.)
    > >>
    > >> 2. I have seen a mismatching padlock icon, compared to
    the actual
    > >> session and the sessions in the "Secure chat" menu. The
    > sessions listed
    > >> in "Secure chat" menu have always been accurate AFAICT. I
    have
    > not been
    > >> able to reproduce it reliably though -- and I'm starting
    to doubt
    > >> whether session selection isn't the culprit.
    > >>
    > >> 3. About encryption-state mismatches ...
    > >>
    > >> a) I have NOT been able to get a session that was not
    actually
    > >> encrypted even though Jitsi says it IS encrypted. This in
    > itself does
    > >> not prove that there isn't an issue, but it's not so easy to
    > get into
    > >> that state by just clicking buttons (with or without thinking
    > about it).
    > >>
    > >> b) I have been able to send unencrypted messages while an
    > encrypted
    > >> session was set up. HOWEVER, Jitsi accurately showed an open
    > padlock
    > >> when sending the message. The reason for this is that I had
    > selected the
    > >> "root" XMPP session and sent the message via there. If you
    > select this
    > >> session, Jitsi accurately shows an open padlock and messages
    > are sent to
    > >> all session (I think). The chat client on the other side
    accurately
    > >> warns of an unencrypted message being received. If you then
    > select one
    > >> specific XMPP session in the chat window, the padlock updates
    > and indeed
    > >> messages are sent in encrypted form.
    > >>
    > >> As far as I have been able to determine this is all expected
    > behaviour.
    > >> The root session cannot be OTR-encrypted, since it sends to
    > (multiple?)
    > >> sessions and you would need to encrypt differently for every
    > session. So
    > >> you need to select one specific session to send encrypted
    > messages. (OTR
    > >> also stores a new session instance for each XMPP session.)
    > >>
    > >> 4. Given the behaviour above, it would be good to somehow
    warn or
    > >> prevent users from selecting the "root" session if multiple
    > sessions are
    > >> known/active. This should prevent mistakes from being made.
    > >>
    > >> a) We may need to change the UI so that the "active"
    session
    > (last
    > >> message) is selected automatically and users would always
    need
    > to select
    > >> a specific session to switch. (And maybe we should not allow
    > selecting
    > >> this top-most session.)
    > >>
    > >> ... after some more hours of fiddling around and lots of
    confusing
    > >> moments ...
    > >>
    > >> 5. I have now determined that XMPP message carbons can
    > interfere with
    > >> correctly establishing an encrypted OTR sessions at one
    of two
    > sides. I
    > >> am not clear on the details yet (and I am starting to believe
    > that this
    > >> is a bug in the implementation), but this issue seems to
    arise
    > at the
    > >> side where 2 sessions are active and carbons are enabled. (I
    > see the
    > >> occasional OTR debug log entry about messages meant for
    another
    > session.)
    > >>
    > >> a) The result is an encrypted OTR session that IS
    established
    > for the
    > >> non-problematic side (account with only a single XMPP
    session). The
    > >> sessions is established fully, and it can send encrypted
    > messages. The
    > >> other side (2 active XMPP sessions) eventually decides to
    go with
    > >> plaintext and does not expose the encrypted session, even
    > though it is
    > >> established. It is established because it can decrypt any
    received
    > >> encrypted messages, however ask the OTR Session-instance
    for its
    > >> SessionStatus and it will return PLAINTEXT. Send a
    message from
    > that
    > >> side and it will send a plain text message (not encrypted).
    > NOTE that
    > >> the padlock icon consistently shows an accurate state.
    > >>
    > >> 6. Further more, a small issue which may not actually be a
    > problem. I
    > >> note this here for reference as it may only ever occur if you
    > delay the
    > >> process by debugging (stepping through code): In the OTR
    > plugin, if the
    > >> timeout-scheduler isn't cancelled in time, it will set a
    > "timeout" state
    > >> which is then used and hides the true state of the OTR
    Session
    > instance.
    > >>
    > >> Reproduction recipe for 5.:
    > >> 1. Start some other chat client. Log in the account with
    server
    > support
    > >> message carbons, e.g. @jit.si <http://jit.si>
    <http://jit.si>. This is going to
    > be the shared account.
    > >> 2. Start Jitsi. Log in with same account as in 1. Make
    sure message
    > >> carbons are enabled.
    > >> Using Jitsi, log in with another XMPP account.
    > >>
    > >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
    > other client
    > >> - with message carbons, 1 solely for Jitsi.
    > >>
    > >> 3. Use client from 1. initiate OTR-encrypted session with
    2. using
    > >> @jit.si <http://jit.si> <http://jit.si> account
    > >> 4. Using client from 1. send message to other XMPP account.
    > >> 5. Jitsi popup shows that it received a message. Click
    popup to
    > view
    > >> message. Notice that OTR session is established.
    > >> 6. In Jitsi, select the other session for this account
    (@jit.si <http://jit.si>
    > <http://jit.si>) that is
    > >> available (which accidentally is the Jitsi client's XMPP session)
    > >> 7. Initiate OTR-encrypted session between the 2 accounts,
    both
    > in Jitsi.
    > >>
    > >> -- Notice that session correctly establishes at initiating
    > side, which
    > >> is the 1-session XMPP account solely in use by Jitsi.
    > >>
    > >> 9. Send a message over this newly instantiated OTR session.
    > >> 10. Popup shows for newly received message, click and it
    opens
    > a second
    > >> tab showing the message received on the shared @jit.si
    <http://jit.si>
    > <http://jit.si> account.
    > >>
    > >> -- Notice now that *that* account's OTR-encrypted session
    was not
    > >> recognized. The padlock is open. Sending messages now
    will send
    > them as
    > >> plain text. However, it did just receive the encrypted
    message and
    > >> decrypted it successfully.
    > >>
    > >> When enabling debug logging in OTR one notices that the
    > messages are
    > >> indeed encrypted from the side showing the OTR-encrypted
    > session, and
    > >> plain text for the other side.
    > >>
    > >> Disabling message carbons fixes the problem described above.
    > (At least,
    > >> it does for me.)
    > >>
    > >>
    > >> Sorry for making this such a long post. To conclude: I have
    > been trying
    > >> to get a feel for the state of OTR support in Jitsi. We
    already
    > knew of
    > >> some issues with state mangement. I believe these
    findings may have
    > >> fine-tuned this issue a bit. For now I do not see any big
    problems,
    > >> especially since the UI always showed an accurate state.
    > Confusion is
    > >> mostly caused by XMPP's message carbons together with
    multiple
    > active
    > >> sessions, which also makes the issues local to the XMPP
    > protocol. The
    > >> confusion is focused on using the UI, as OTR seems to do the
    > right thing
    > >> in the background. EXCEPT for this one issue described above
    > where the
    > >> OTR-encrypted session should have been established at both
    > sides. But
    > >> even then, Jitsi showed the correct state as the results were
    > accordingly.
    > >>
    > >> So, if you rely on OTR, make sure that your XMPP accounts
    have
    > message
    > >> carbons disabled. Then you should have a pretty smooth ride.
    > (As far as
    > >> I can tell from these tests.)
    > >>
    > >> Danny
    > >>
    > >>
    > >>
    > >>
    > >> On 26-01-15 10:50, George Politis wrote:
    > >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
    > >>>
    > >>>> Hi all,
    > >>>>
    > >>>> Quick follow-up. I haven't had as much time as I would've
    > liked. I have
    > >>>> found out the following things. (in line ...)
    > >>>>
    > >>>> On 23-01-15 21:34, Danny van Heumen wrote:
    > >>>>> Hi all,
    > >>>>>
    > >>>>> Because of recent remarks about OTR support in Jitsi, I've
    > been trying
    > >>>>> out some cases - all using XMPP as messaging protocol.
    These
    > were
    > >>>>> all in
    > >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
    > accounts also
    > >>>>> logged in on Pidgin.
    > >>>>>
    > >>>>> For now, here's what I've found.
    > >>>>>
    > >>>>> 1. When using multiple sessions, Jitsi doesn't seem to
    correctly
    > >>>>> distinguish and discard the
    messages-for-another-session. I
    > quickly
    > >>>>> looked at the otr4j source and if I read it correctly,
    then
    > the message
    > >>>>> gets returned unchanged. (Only took a quick look, so
    may not be
    > >>>>> accurate.) In that case the Jitsi client will just
    show the
    > >>>>> base64(encrypted) content. ... at least in this test ...
    > (So, send from
    > >>>>> Jitsi client to Pidgin client, while Jitsi also
    connected to
    > same
    > >>>>> account as Pidgin's is logged on to.)
    > >>>> It is just slightly different than I've stated above. It
    > turns out that
    > >>>> the 2nd session "listening in" (not in the malicious way)
    > does not have
    > >>>> an OTR session established. So, as a consequence this
    session
    > receives
    > >>>> encrypted messages as if they were normal messages.
    > >>>>
    > >>>> This is likely not an issue in the OTR4J library, but
    rather
    > in Jitsi
    > >>>> not including OTR4J, since it isn't enabled. I believe that
    > if OTR4J was
    > >>>> "in the loop" it would have handled this message. Maybe by
    > dropping a
    > >>>> system message saying what is happening. Need to look into
    > that further.
    > >>>>
    > >>> There seems to be an issue here. You're talking about
    > >>> OtrTransformLayer:149, right? Where this code fragment is
    > executed:
    > >>>
    > >>> f (!policy.getEnableManual()
    > >>> && sessionStatus != ScSessionStatus.ENCRYPTED
    > >>> && sessionStatus != ScSessionStatus.FINISHED)
    > >>> return evt;
    > >>>
    > >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
    > message it
    > >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
    > at Pidgin
    > >>>>> side. (Though javascript doesn't get executed :-P)
    > >>>> This one's a bit tricky. We receive a text message which is
    > encrypted.
    > >>>> Once decrypted, we need to discover whether it is
    intended as
    > HTML or
    > >>>> plain text. I'm not sure how another OTR-capable chat
    client
    > makes this
    > >>>> distinction, though looking at Pidgin's behaviour, I
    suspect
    > they may
    > >>>> simply have assumed HTML. (Otherwise it wouldn't have
    been as
    > simple to
    > >>>> inject styling in the message sent to Pidgin client.)
    > >>> Other clients, like Miranda, have the exact same problem
    when they
    > >>> communicate with Pidgin
    > (https://developer.pidgin.im/ticket/8453). I
    > >>> suppose the messages that Pidgin is sending don't have their
    > >>> contentType set correctly, right? In that case, one way
    to fix it
    > >>> would be to assume HTML if the remote client is Pidgin.
    > >>>
    > >>>>> 3. Jitsi does not unescape html received from Pidgin. So
    > "<dude>" sent
    > >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
    > >>>> Same as above.
    > >>>>> All should be fairly easy to fix.
    > >>>> I should've known better ... saying things like that :stuck_out_tongue:
    > >>>>
    > >>>>> (Assuming Pidgin is the one behaving
    > >>>>> as expected, which I am at the moment but will try to
    check
    > before
    > >>>>> fixing things in Jitsi.)
    > >>>>>
    > >>>>> I haven't found a case yet where I get to see the actual
    > HTML that is
    > >>>>> being sent as was described in
    > >>>>>
    >
     http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
    > >>>>> understand correctly that is ...)
    > >>>> Still same. I have only seen html entities up to now. If
    > anyone knows
    > >>>> otherwise, plz let me know.
    > >>>>
    > >>>> As an added bonus I found out that plain text messages
    aren't
    > correctly
    > >>>> escaped in the notification popup, so at least that's fixed
    > now :slight_smile:
    > >>>>
    > >>>> Danny
    > >>>>
    > >>>>> Danny
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>> _______________________________________________
    > >>>>> dev mailing list
    > >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>>> Unsubscribe instructions and other list options:
    > >>>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>>> _______________________________________________
    > >>>> dev mailing list
    > >>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>> Unsubscribe instructions and other list options:
    > >>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>> _______________________________________________
    > >>> dev mailing list
    > >>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>> Unsubscribe instructions and other list options:
    > >>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>
    > >>
    > >> _______________________________________________
    > >> dev mailing list
    > >> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >> Unsubscribe instructions and other list options:
    > >> http://lists.jitsi.org/mailman/listinfo/dev
    > >
    > >
    > >
    > > _______________________________________________
    > > dev mailing list
    > > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > > Unsubscribe instructions and other list options:
    > > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#19

Hi all,

Okay, so after lots of code juggling, I have found a method to get all
the information to the places where I needed it.
It turns out that going the plugin component isn't the way to go here ...

I've now modified the code so it will have the following behaviour:

1. The OTR session switcher is always visible, but disabled in case of
only a single session.
There's a simple reason for doing this. This at least shows that there
is such a thing. It saves a lot of confusions if people see the thing
and also makes it easier to point to it in case you want to know its
state. The switcher gets enabled if more than 1 session is available.
The icon of the session switcher always reflects the current state, AFAICT.

2. I've passed on the events w.r.t. chat transport selection such that
the OTR session switcher actually gets a chance to act upon transport
selection changes. Previously it didn't get these changes at all, so it
only acted upon the very basic contact switches which are of nearly no
concern for the session switcher. (Note the 'nearly' ...)

3. I have confirmed that at least my own discovered issue is now fixed.
I cannot say anything for others' issues.

Also, (this is 4. I guess ...) a recent commit I made should fix the
outstanding issue with not acting on received OTR whitespace tags from
another OTR-capable client. So clients using the opportunistic setting
(I think, from top of my head) should now automatically initiate an OTR
session again.

So, PLEASE TEST this change. Let me know if you have identified any
other bad behaviour.
At the very least you should be able to trust the state that the OTR UI
reflects a bit more.

Danny

···

On 01-03-15 20:52, Danny van Heumen wrote:

Hi Marin and others,

Okay, so I think I've pinpointed the cause ... ... that is, with
emphasis on *think* here :stuck_out_tongue:

It seems that multiple instances aren't recognized, because
OTRv3OutgoingSessionSwitcher does not get updates w.r.t. selected
session (chat transport changes). The method
'OTRv3OutgoingSessionSwitcher#setCurrentContact(contact, resourceName)'
never gets called. As a result, only the contact is ever known, so you
get a different session which does not contain the instances. (So
dude@jit.si, instead of dude@jit.si/jitsi-a3e89f.)

Just to be clear, '#setContact(contact)' is called. But that doesn't
specify the resource, so it becomes too general and points to a
different session.

'MainToolBar#currentChatTransportChanged' should call the instance of
OTRv3OutgoingSessionSwitcher, but it isn't registered as this type of
plugin component. I think I'm quite close to the solution, but currently
I'm trying to figure out on-the-fly how UI component plugins work, so
I'm not quite there yet. Any help would be appreciated.

Once this is fixed, it should also again show the OTR instances menu at
appropriate times.

Danny

On 27-02-15 08:08, Marin Dzhigarov wrote:

Hi Danny,

    As I understand it now, that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

That is completely correct. Or at least it is supposed to work that way.

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

Also correct. Please look at
the net.java.sip.communicator.plugin.otr.authdialog.OTRv3OutgoingSessionSwitcher class.
If I recall correctly, one could also use the Secure Chat menu in
order to switch between slave sessions but I'm not completely sure
about that.

     None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

Since an incoming message gets decrypted that means you have a slave
session in ENCRYPTED state which is good - otr was established. All
incoming messages will get decrypted correctly. But you can use this
slave session to encrypt outgoing messages aswell. You just have to
select it. An open padlock means that the slave session is not
currently selected, or better said - the current outgoing session is
in PLAINTEXT state.

    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

Yes, correct. Also, please note that with the current implementation
you could never establish ENCRYPTED session with the bare jid. That's
because jids are mapped to instance id's (or sth like that). So even
if one Jitsi client (Alice) tries to send an OTR initiation request to
his buddy (Bob) using his Bob's bare jid, what happens is that
actually when Bob receives Alice's message he'll respond with his
actual JID. Then, when Alice receive Bob's response she'll create a
slave session since Bob's response doesn't come from a bare jid but
from an actual one. I hope that makes sense.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

Yes, you are!
Thank you very much for the effort. I know from experience how
frustrating that could be. Debugging OTR issues in combination with
XMPP is very exhausting as it may often seem indeterministic.

Best regards,
Marin

On Thu, Feb 26, 2015 at 9:56 PM, Danny van Heumen >> <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi Marin,

    Thanks for your quite detailed response. I'll add my comments in-line.
    Hopefully that clarifies what I think my issue is about.

    On 26-02-15 14:06, Marin Dzhigarov wrote:
    > Hello Danny,
    >
    > Thank you for your findings but...
    >
    > RESULT:
    > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > 2. Fully established ENCRYPTED slave session. Will be reachable
    > for decrypting messages, however it is completely off-the-radar
    > when querying the status of a session.
    > 3. Received messages get routed by their sender instance ID and
    > arrive at the slave session, get processed appropriately and
    hence
    > get returned decrypted to Jitsi.
    > 4. Sent messages get sent in plain text according to the Master
    > session's status. Client at other end will received a plain text
    > message even though it has an OTR session established.
    >
    >
    > I still don't see anything wrong with this behaviour. Actually, I
    > implemented it that way so I'm glad it's still working :smiley:
    > You can use the icon in the left-down corner in order to switch
    > between carbons. When you do, the "active" carbon is going to change
    > and you will see that the padlock is closed. (Or at least it should
    > work that way if I remember correctly).
    So, when I'm talking about carbons, I'm referring to the actual
    messages
    themselves being replicated to other clients of the same account. I am
    assuming here that you mean the various "sessions", one session
    for each
    of the logged in clients of that account, right?

    So, after the session is established, I can indeed switch these
    sessions
    using that drop down menu. None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

    > Addionally, you may have an icon in the right-down corner that
    > switches between active slave sessions but I don't remember the
    > details for that one. So you might end up having to choose between a
    > combination of [carbon - otr session] from the two down corners in
    > order to send proper messages.
    I have not found this right-bottom menu. Never seen it as far as I can
    remember.

    I think this might be related to my issue. As I understand it now,
    that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

    > I remember that I also put some logic so that Jitsi can automacally
    > switch between carbons (down-left icon) depending on the received
    > message. The idea was that if one receives a message from a certain
    > jid, the default carbon and thus the active otr slave session
    (used to
    > encrypt outgoing messages) is switched.
    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

    >
    > ​
    >
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    >
    > Also, again if I remember correctly, there is no way to have an
    > ENCRYPTED master session because master sessions delegate session
    > initiation requests to slave sessions.
    Okay, sure, that makes sense. I did check logging I produce and it
    shows
    that the same session instance that had old status 'plaintext' and new
    status 'encrypted' has isMasterSession == true. So it seems that
    this is
    possible.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

    I'm going to look into getting these slave sessions to the surface ...

    Danny

    > ​
    >
    > I hope that helps.
    >
    > Best regards,
    > Marin
    >
    > On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen >> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> >> <mailto:danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>>> >> wrote:
    >
    >
    > A quick addition ... I was thinking about which combinations are
    > possible for Master - Slave session combinations.
    >
    > * Master session: PLAINTEXT + Slave session: ENCRYPTED --
    possible as
    > this is the current problem.
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    > * Both PLAINTEXT shouldn't be an issue in any case, i.e. no
    encrypted
    > sessions established.
    >
    > * Both ENCRYPTED: not sure if this makes sense, but in any
    case we
    > would
    > sent an encrypted message. It might get delivered to the wrong
    > address,
    > but it wouldn't unintentionally be sent PLAINTEXT, so not an
    issue(?)
    >
    > Danny
    >
    >
    >
    > On 25-02-15 23:43, Danny van Heumen wrote:
    > > Hi all,
    > >
    > > So, here's another follow up with what I found out
    yesterday. I
    > think
    > > I may have an explanation of what happens. It's pretty
    interesting
    > > interplay of features, I think ...
    > >
    > > A FEW FACTS:
    > > * When message carbons are activated, the messages sent by one
    > client
    > > are repeated to the other clients as message delivered
    events. (I'm
    > > quite sure, but please correct me if I'm wrong here ...)
    > > * Jitsi's OTR implementation does not process message
    delivered
    > > events. (The only exception to this is to check if a
    message is
    > > injected such that the user is not bothered with OTR
    interaction
    > > inside the client.)
    > > * I found out that the session status gets updated in another
    > instance
    > > of SessionImpl than where the instance where we query for the
    > current
    > > session status. This explains both:
    > >
    > > 1. Why the statuses deviate - between session
    establishment (in log
    > > messages) and session status querying, and
    > > 2. Why messages till get decrypted when received even
    though the
    > > status is PLAINTEXT.
    > >
    > > FLOW OF EVENTS: Here's where it gets interesting ...
    > >
    > > Say we have:
    > > * An account a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> on server jit.si <http://jit.si>
    > <http://jit.si> which supports message carbons.
    > > * An account b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> on server
    > gmail.com <http://gmail.com> <http://gmail.com> which does
    not support
    > > message carbons.
    > > * Client A, a Jitsi client, with account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - with message
    > > carbons enabled - and account b@gmail.com
    <mailto:b@gmail.com> <mailto:b@gmail.com <mailto:b@gmail.com>>.
    > > * Client B, another client with account a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - without message
    > > carbons enabled.
    > >
    > > 1. We initiate an OTR session with client A to account
    > b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>.
    > > This means that B sends the OTR v3 query message.
    > > -- a) client A receives the request on account b@gmail.com
    <mailto:b@gmail.com>
    > <mailto:b@gmail.com <mailto:b@gmail.com>>
    > > -- b) client A receives a carbon of the request on a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>. This
    > > message isn't processed by otr4j, so effectively gets ignored.
    > >
    > > 2. Client A receives OTR v3 query message, answers with
    D-H commit
    > > message.
    > > -- a) client B receives the request on account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>.
    > > -- b) client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives the message
    > carbon and sets a master
    > > session for this sender instance id, however it does not
    expect the
    > > D-H commit message so does not respond.
    > >
    > > 3. Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>) and client B
    > (b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>) finish up OTR
    > > protocol and establish a secure session.
    > >
    > > Now Client A (b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>>) wants to
    > establish an OTR session with
    > > Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>), so it sends initial OTR
    > v3 query message.
    > >
    > > 4. Client A on b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> sends message to
    > a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> for client A
    > > (that is, that specific session id).
    > > -- a) Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives this message,
    > however it contains a
    > > different sender instance id than the message before, so a
    slave
    > > session is established. The received message gets passed
    through to
    > > slave session. Slave session handles message.
    > >
    > > 5. Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> responds and continues
    > establishing OTR encrypted
    > > session. Now Client A a@jit.si <mailto:a@jit.si>
    <mailto:a@jit.si <mailto:a@jit.si>> has 2 sessions
    > available:
    > > * Master session: PLAINTEXT, received some OTR messages but
    > nothing to
    > > establish a connection with.
    > > * Slave session: ENCRYPTED, did full processing of OTR session
    > > establishment and has a full, completed ENCRYPTED session.
    > >
    > > Now that an encrypted session is established, we call
    listeners to
    > > inform of a sessionStatusChanged(OtrContact). However, a
    call of
    > > getStatus(SessionID for OtrContact) will return the session
    > status of
    > > the MASTER session, which is plain text, since it was
    based upon the
    > > message carbons.
    > >
    > > RESULT:
    > >
    > > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > > 2. Fully established ENCRYPTED slave session. Will be
    reachable for
    > > decrypting messages, however it is completely
    off-the-radar when
    > > querying the status of a session.
    > > 3. Received messages get routed by their sender instance
    ID and
    > arrive
    > > at the slave session, get processed appropriately and
    hence get
    > > returned decrypted to Jitsi.
    > > 4. Sent messages get sent in plain text according to the
    Master
    > > session's status. Client at other end will received a
    plain text
    > > message even though it has an OTR session established.
    > >
    > > I hope this makes sense. It is a bit late, so please be
    critical and
    > > check if everything makes sense. I can clarify if there
    are any
    > > questions. (Or replay the problem and/or recheck the logging.)
    > >
    > > Assuming the above is correct, this would also explain my
    earlier
    > > comment regarding disabling message carbons. This would indeed
    > prevent
    > > establishing the early Master session, hence when the OTR
    session is
    > > deliberately initiated, this would become the Master
    session and one
    > > would indeed get the correct Session Status when queried via
    > > getStatus(SessionID).
    > >
    > > So, if this correctly establishes the problem, I am quite
    interested
    > > in how we're going to solve this one. I haven't thought about
    > this one
    > > yet ... :slight_smile:
    > >
    > > Regards,
    > > Danny
    > >
    > >
    > >
    > > On 22-02-15 21:18, Danny van Heumen wrote:
    > >> Okay, so it's time for an update on this topic ...
    > >>
    > >> @George: In case of TL;DR, could you check my commit, just to
    > be sure?
    > >>
    >
     https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
    > >> It's about removing the conditionals so any message
    reaches the
    > otr4j
    > >> library, even if a secure session is not established yet.
    > Basically what
    > >> you suggested before.
    > >> Also, can you explain why at SessionImpl:479 (call to
    > >> setSessionStatus(ENCRYPTED)) the called method resets auth
    > (AuthContext)
    > >> to setIsSecure(false), while the passed parameter is
    > >> SessionStatus.ENCRYPTED? (It may be completely fine, but
    it seems
    > >> contradictory.)
    > >>
    > >> I've been playing around with the whole OTR UI and plugin to
    > see what I
    > >> could discover apart from the stuff we already know. I have
    > been playing
    > >> around for a few hours and this is a quick report of what
    I've
    > been able
    > >> to discover.
    > >>
    > >> 1. The raw OTR-encrypted message I received as described
    below,
    > is due
    > >> to XMPP Carbons being enabled. We receive the message
    sent from
    > another
    > >> client (same account) and we subscribed to carbon copies,
    so we
    > receive
    > >> a carbon of the raw message. This particular message flow is
    > not hooked
    > >> into otr4j, so it gets shown as a plain old message. (@fippo:
    > Thanks for
    > >> pointing out the carbons!)
    > >>
    > >> a) I'm thinking of whether or not we *can* hook that into
    > otr4j. Maybe
    > >> we can process this as a "received" message. I have not done
    > that yet,
    > >> though, because I'm not a 100% sure that there aren't any
    other
    > >> consequences. (It would be nice to see a notification of
    a message
    > >> encrypted for another session, and have the ability to
    drop the
    > message
    > >> itself, since that has no value to us.)
    > >>
    > >> 2. I have seen a mismatching padlock icon, compared to
    the actual
    > >> session and the sessions in the "Secure chat" menu. The
    > sessions listed
    > >> in "Secure chat" menu have always been accurate AFAICT. I
    have
    > not been
    > >> able to reproduce it reliably though -- and I'm starting
    to doubt
    > >> whether session selection isn't the culprit.
    > >>
    > >> 3. About encryption-state mismatches ...
    > >>
    > >> a) I have NOT been able to get a session that was not
    actually
    > >> encrypted even though Jitsi says it IS encrypted. This in
    > itself does
    > >> not prove that there isn't an issue, but it's not so easy to
    > get into
    > >> that state by just clicking buttons (with or without thinking
    > about it).
    > >>
    > >> b) I have been able to send unencrypted messages while an
    > encrypted
    > >> session was set up. HOWEVER, Jitsi accurately showed an open
    > padlock
    > >> when sending the message. The reason for this is that I had
    > selected the
    > >> "root" XMPP session and sent the message via there. If you
    > select this
    > >> session, Jitsi accurately shows an open padlock and messages
    > are sent to
    > >> all session (I think). The chat client on the other side
    accurately
    > >> warns of an unencrypted message being received. If you then
    > select one
    > >> specific XMPP session in the chat window, the padlock updates
    > and indeed
    > >> messages are sent in encrypted form.
    > >>
    > >> As far as I have been able to determine this is all expected
    > behaviour.
    > >> The root session cannot be OTR-encrypted, since it sends to
    > (multiple?)
    > >> sessions and you would need to encrypt differently for every
    > session. So
    > >> you need to select one specific session to send encrypted
    > messages. (OTR
    > >> also stores a new session instance for each XMPP session.)
    > >>
    > >> 4. Given the behaviour above, it would be good to somehow
    warn or
    > >> prevent users from selecting the "root" session if multiple
    > sessions are
    > >> known/active. This should prevent mistakes from being made.
    > >>
    > >> a) We may need to change the UI so that the "active"
    session
    > (last
    > >> message) is selected automatically and users would always
    need
    > to select
    > >> a specific session to switch. (And maybe we should not allow
    > selecting
    > >> this top-most session.)
    > >>
    > >> ... after some more hours of fiddling around and lots of
    confusing
    > >> moments ...
    > >>
    > >> 5. I have now determined that XMPP message carbons can
    > interfere with
    > >> correctly establishing an encrypted OTR sessions at one
    of two
    > sides. I
    > >> am not clear on the details yet (and I am starting to believe
    > that this
    > >> is a bug in the implementation), but this issue seems to
    arise
    > at the
    > >> side where 2 sessions are active and carbons are enabled. (I
    > see the
    > >> occasional OTR debug log entry about messages meant for
    another
    > session.)
    > >>
    > >> a) The result is an encrypted OTR session that IS
    established
    > for the
    > >> non-problematic side (account with only a single XMPP
    session). The
    > >> sessions is established fully, and it can send encrypted
    > messages. The
    > >> other side (2 active XMPP sessions) eventually decides to
    go with
    > >> plaintext and does not expose the encrypted session, even
    > though it is
    > >> established. It is established because it can decrypt any
    received
    > >> encrypted messages, however ask the OTR Session-instance
    for its
    > >> SessionStatus and it will return PLAINTEXT. Send a
    message from
    > that
    > >> side and it will send a plain text message (not encrypted).
    > NOTE that
    > >> the padlock icon consistently shows an accurate state.
    > >>
    > >> 6. Further more, a small issue which may not actually be a
    > problem. I
    > >> note this here for reference as it may only ever occur if you
    > delay the
    > >> process by debugging (stepping through code): In the OTR
    > plugin, if the
    > >> timeout-scheduler isn't cancelled in time, it will set a
    > "timeout" state
    > >> which is then used and hides the true state of the OTR
    Session
    > instance.
    > >>
    > >> Reproduction recipe for 5.:
    > >> 1. Start some other chat client. Log in the account with
    server
    > support
    > >> message carbons, e.g. @jit.si <http://jit.si>
    <http://jit.si>. This is going to
    > be the shared account.
    > >> 2. Start Jitsi. Log in with same account as in 1. Make
    sure message
    > >> carbons are enabled.
    > >> Using Jitsi, log in with another XMPP account.
    > >>
    > >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
    > other client
    > >> - with message carbons, 1 solely for Jitsi.
    > >>
    > >> 3. Use client from 1. initiate OTR-encrypted session with
    2. using
    > >> @jit.si <http://jit.si> <http://jit.si> account
    > >> 4. Using client from 1. send message to other XMPP account.
    > >> 5. Jitsi popup shows that it received a message. Click
    popup to
    > view
    > >> message. Notice that OTR session is established.
    > >> 6. In Jitsi, select the other session for this account
    (@jit.si <http://jit.si>
    > <http://jit.si>) that is
    > >> available (which accidentally is the Jitsi client's XMPP session)
    > >> 7. Initiate OTR-encrypted session between the 2 accounts,
    both
    > in Jitsi.
    > >>
    > >> -- Notice that session correctly establishes at initiating
    > side, which
    > >> is the 1-session XMPP account solely in use by Jitsi.
    > >>
    > >> 9. Send a message over this newly instantiated OTR session.
    > >> 10. Popup shows for newly received message, click and it
    opens
    > a second
    > >> tab showing the message received on the shared @jit.si
    <http://jit.si>
    > <http://jit.si> account.
    > >>
    > >> -- Notice now that *that* account's OTR-encrypted session
    was not
    > >> recognized. The padlock is open. Sending messages now
    will send
    > them as
    > >> plain text. However, it did just receive the encrypted
    message and
    > >> decrypted it successfully.
    > >>
    > >> When enabling debug logging in OTR one notices that the
    > messages are
    > >> indeed encrypted from the side showing the OTR-encrypted
    > session, and
    > >> plain text for the other side.
    > >>
    > >> Disabling message carbons fixes the problem described above.
    > (At least,
    > >> it does for me.)
    > >>
    > >>
    > >> Sorry for making this such a long post. To conclude: I have
    > been trying
    > >> to get a feel for the state of OTR support in Jitsi. We
    already
    > knew of
    > >> some issues with state mangement. I believe these
    findings may have
    > >> fine-tuned this issue a bit. For now I do not see any big
    problems,
    > >> especially since the UI always showed an accurate state.
    > Confusion is
    > >> mostly caused by XMPP's message carbons together with
    multiple
    > active
    > >> sessions, which also makes the issues local to the XMPP
    > protocol. The
    > >> confusion is focused on using the UI, as OTR seems to do the
    > right thing
    > >> in the background. EXCEPT for this one issue described above
    > where the
    > >> OTR-encrypted session should have been established at both
    > sides. But
    > >> even then, Jitsi showed the correct state as the results were
    > accordingly.
    > >>
    > >> So, if you rely on OTR, make sure that your XMPP accounts
    have
    > message
    > >> carbons disabled. Then you should have a pretty smooth ride.
    > (As far as
    > >> I can tell from these tests.)
    > >>
    > >> Danny
    > >>
    > >>
    > >>
    > >>
    > >> On 26-01-15 10:50, George Politis wrote:
    > >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
    > >>>
    > >>>> Hi all,
    > >>>>
    > >>>> Quick follow-up. I haven't had as much time as I would've
    > liked. I have
    > >>>> found out the following things. (in line ...)
    > >>>>
    > >>>> On 23-01-15 21:34, Danny van Heumen wrote:
    > >>>>> Hi all,
    > >>>>>
    > >>>>> Because of recent remarks about OTR support in Jitsi, I've
    > been trying
    > >>>>> out some cases - all using XMPP as messaging protocol.
    These
    > were
    > >>>>> all in
    > >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
    > accounts also
    > >>>>> logged in on Pidgin.
    > >>>>>
    > >>>>> For now, here's what I've found.
    > >>>>>
    > >>>>> 1. When using multiple sessions, Jitsi doesn't seem to
    correctly
    > >>>>> distinguish and discard the
    messages-for-another-session. I
    > quickly
    > >>>>> looked at the otr4j source and if I read it correctly,
    then
    > the message
    > >>>>> gets returned unchanged. (Only took a quick look, so
    may not be
    > >>>>> accurate.) In that case the Jitsi client will just
    show the
    > >>>>> base64(encrypted) content. ... at least in this test ...
    > (So, send from
    > >>>>> Jitsi client to Pidgin client, while Jitsi also
    connected to
    > same
    > >>>>> account as Pidgin's is logged on to.)
    > >>>> It is just slightly different than I've stated above. It
    > turns out that
    > >>>> the 2nd session "listening in" (not in the malicious way)
    > does not have
    > >>>> an OTR session established. So, as a consequence this
    session
    > receives
    > >>>> encrypted messages as if they were normal messages.
    > >>>>
    > >>>> This is likely not an issue in the OTR4J library, but
    rather
    > in Jitsi
    > >>>> not including OTR4J, since it isn't enabled. I believe that
    > if OTR4J was
    > >>>> "in the loop" it would have handled this message. Maybe by
    > dropping a
    > >>>> system message saying what is happening. Need to look into
    > that further.
    > >>>>
    > >>> There seems to be an issue here. You're talking about
    > >>> OtrTransformLayer:149, right? Where this code fragment is
    > executed:
    > >>>
    > >>> f (!policy.getEnableManual()
    > >>> && sessionStatus != ScSessionStatus.ENCRYPTED
    > >>> && sessionStatus != ScSessionStatus.FINISHED)
    > >>> return evt;
    > >>>
    > >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
    > message it
    > >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
    > at Pidgin
    > >>>>> side. (Though javascript doesn't get executed :-P)
    > >>>> This one's a bit tricky. We receive a text message which is
    > encrypted.
    > >>>> Once decrypted, we need to discover whether it is
    intended as
    > HTML or
    > >>>> plain text. I'm not sure how another OTR-capable chat
    client
    > makes this
    > >>>> distinction, though looking at Pidgin's behaviour, I
    suspect
    > they may
    > >>>> simply have assumed HTML. (Otherwise it wouldn't have
    been as
    > simple to
    > >>>> inject styling in the message sent to Pidgin client.)
    > >>> Other clients, like Miranda, have the exact same problem
    when they
    > >>> communicate with Pidgin
    > (https://developer.pidgin.im/ticket/8453). I
    > >>> suppose the messages that Pidgin is sending don't have their
    > >>> contentType set correctly, right? In that case, one way
    to fix it
    > >>> would be to assume HTML if the remote client is Pidgin.
    > >>>
    > >>>>> 3. Jitsi does not unescape html received from Pidgin. So
    > "<dude>" sent
    > >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
    > >>>> Same as above.
    > >>>>> All should be fairly easy to fix.
    > >>>> I should've known better ... saying things like that :stuck_out_tongue:
    > >>>>
    > >>>>> (Assuming Pidgin is the one behaving
    > >>>>> as expected, which I am at the moment but will try to
    check
    > before
    > >>>>> fixing things in Jitsi.)
    > >>>>>
    > >>>>> I haven't found a case yet where I get to see the actual
    > HTML that is
    > >>>>> being sent as was described in
    > >>>>>
    >
     http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
    > >>>>> understand correctly that is ...)
    > >>>> Still same. I have only seen html entities up to now. If
    > anyone knows
    > >>>> otherwise, plz let me know.
    > >>>>
    > >>>> As an added bonus I found out that plain text messages
    aren't
    > correctly
    > >>>> escaped in the notification popup, so at least that's fixed
    > now :slight_smile:
    > >>>>
    > >>>> Danny
    > >>>>
    > >>>>> Danny
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>> _______________________________________________
    > >>>>> dev mailing list
    > >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>>> Unsubscribe instructions and other list options:
    > >>>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>>> _______________________________________________
    > >>>> dev mailing list
    > >>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>> Unsubscribe instructions and other list options:
    > >>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>> _______________________________________________
    > >>> dev mailing list
    > >>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>> Unsubscribe instructions and other list options:
    > >>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>
    > >>
    > >> _______________________________________________
    > >> dev mailing list
    > >> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >> Unsubscribe instructions and other list options:
    > >> http://lists.jitsi.org/mailman/listinfo/dev
    > >
    > >
    > >
    > > _______________________________________________
    > > dev mailing list
    > > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > > Unsubscribe instructions and other list options:
    > > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#20

Hi Danny,
thank you VERY much for your highly valuable impact and help to solve
this nasty issue!!!

I will for sure provide feedback.

kind regards
MS

PGP.sig (489 Bytes)

···

On 3/7/15 12:17 AM, Danny van Heumen wrote:

* PGP Signed: 3/7/15 at 12:17:11 AM

Hi all,

Okay, so after lots of code juggling, I have found a method to get all
the information to the places where I needed it.
It turns out that going the plugin component isn't the way to go here ...

I've now modified the code so it will have the following behaviour:

1. The OTR session switcher is always visible, but disabled in case of
only a single session.
There's a simple reason for doing this. This at least shows that there
is such a thing. It saves a lot of confusions if people see the thing
and also makes it easier to point to it in case you want to know its
state. The switcher gets enabled if more than 1 session is available.
The icon of the session switcher always reflects the current state, AFAICT.

2. I've passed on the events w.r.t. chat transport selection such that
the OTR session switcher actually gets a chance to act upon transport
selection changes. Previously it didn't get these changes at all, so it
only acted upon the very basic contact switches which are of nearly no
concern for the session switcher. (Note the 'nearly' ...)

3. I have confirmed that at least my own discovered issue is now fixed.
I cannot say anything for others' issues.

Also, (this is 4. I guess ...) a recent commit I made should fix the
outstanding issue with not acting on received OTR whitespace tags from
another OTR-capable client. So clients using the opportunistic setting
(I think, from top of my head) should now automatically initiate an OTR
session again.

So, PLEASE TEST this change. Let me know if you have identified any
other bad behaviour.
At the very least you should be able to trust the state that the OTR UI
reflects a bit more.

Danny

On 01-03-15 20:52, Danny van Heumen wrote:

Hi Marin and others,

Okay, so I think I've pinpointed the cause ... ... that is, with
emphasis on *think* here :stuck_out_tongue:

It seems that multiple instances aren't recognized, because
OTRv3OutgoingSessionSwitcher does not get updates w.r.t. selected
session (chat transport changes). The method
'OTRv3OutgoingSessionSwitcher#setCurrentContact(contact, resourceName)'
never gets called. As a result, only the contact is ever known, so you
get a different session which does not contain the instances. (So
dude@jit.si, instead of dude@jit.si/jitsi-a3e89f.)

Just to be clear, '#setContact(contact)' is called. But that doesn't
specify the resource, so it becomes too general and points to a
different session.

'MainToolBar#currentChatTransportChanged' should call the instance of
OTRv3OutgoingSessionSwitcher, but it isn't registered as this type of
plugin component. I think I'm quite close to the solution, but currently
I'm trying to figure out on-the-fly how UI component plugins work, so
I'm not quite there yet. Any help would be appreciated.

Once this is fixed, it should also again show the OTR instances menu at
appropriate times.

Danny

On 27-02-15 08:08, Marin Dzhigarov wrote:

Hi Danny,

    As I understand it now, that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

That is completely correct. Or at least it is supposed to work that way.

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

Also correct. Please look at
the net.java.sip.communicator.plugin.otr.authdialog.OTRv3OutgoingSessionSwitcher class.
If I recall correctly, one could also use the Secure Chat menu in
order to switch between slave sessions but I'm not completely sure
about that.

     None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

Since an incoming message gets decrypted that means you have a slave
session in ENCRYPTED state which is good - otr was established. All
incoming messages will get decrypted correctly. But you can use this
slave session to encrypt outgoing messages aswell. You just have to
select it. An open padlock means that the slave session is not
currently selected, or better said - the current outgoing session is
in PLAINTEXT state.

    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

Yes, correct. Also, please note that with the current implementation
you could never establish ENCRYPTED session with the bare jid. That's
because jids are mapped to instance id's (or sth like that). So even
if one Jitsi client (Alice) tries to send an OTR initiation request to
his buddy (Bob) using his Bob's bare jid, what happens is that
actually when Bob receives Alice's message he'll respond with his
actual JID. Then, when Alice receive Bob's response she'll create a
slave session since Bob's response doesn't come from a bare jid but
from an actual one. I hope that makes sense.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

Yes, you are!
Thank you very much for the effort. I know from experience how
frustrating that could be. Debugging OTR issues in combination with
XMPP is very exhausting as it may often seem indeterministic.

Best regards,
Marin

On Thu, Feb 26, 2015 at 9:56 PM, Danny van Heumen >>> <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>> wrote:

    Hi Marin,

    Thanks for your quite detailed response. I'll add my comments in-line.
    Hopefully that clarifies what I think my issue is about.

    On 26-02-15 14:06, Marin Dzhigarov wrote:
    > Hello Danny,
    >
    > Thank you for your findings but...
    >
    > RESULT:
    > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > 2. Fully established ENCRYPTED slave session. Will be reachable
    > for decrypting messages, however it is completely off-the-radar
    > when querying the status of a session.
    > 3. Received messages get routed by their sender instance ID and
    > arrive at the slave session, get processed appropriately and
    hence
    > get returned decrypted to Jitsi.
    > 4. Sent messages get sent in plain text according to the Master
    > session's status. Client at other end will received a plain text
    > message even though it has an OTR session established.
    >
    >
    > I still don't see anything wrong with this behaviour. Actually, I
    > implemented it that way so I'm glad it's still working :smiley:
    > You can use the icon in the left-down corner in order to switch
    > between carbons. When you do, the "active" carbon is going to change
    > and you will see that the padlock is closed. (Or at least it should
    > work that way if I remember correctly).
    So, when I'm talking about carbons, I'm referring to the actual
    messages
    themselves being replicated to other clients of the same account. I am
    assuming here that you mean the various "sessions", one session
    for each
    of the logged in clients of that account, right?

    So, after the session is established, I can indeed switch these
    sessions
    using that drop down menu. None of the menu entries has a closed
    padlock. (Again, if I send a message from the other side, it correctly
    gets decrypted, so the OTR-session is still "encrypted".)
    Additionally,
    the "Secure chat" menu shows a list of session, right? Also there,
    every
    session has an open padlock.

    > Addionally, you may have an icon in the right-down corner that
    > switches between active slave sessions but I don't remember the
    > details for that one. So you might end up having to choose between a
    > combination of [carbon - otr session] from the two down corners in
    > order to send proper messages.
    I have not found this right-bottom menu. Never seen it as far as I can
    remember.

    I think this might be related to my issue. As I understand it now,
    that
    is what I can derive from your comments about the implementation, is
    that there is supposed to be a menu for selecting slave sessions, like
    you said. These slave sessions are for each of the different sender
    instances encountered by otr4j. Going into the implementation, do I
    understand correctly that the variable 'outgoingSession' contains an
    instance of the available slave sessions that is selected as the
    outgoing session? So, in other words, the outgoingSession variable
    always contains an instance that is also found in the
    slaveSessions map?

    If you are supposed to switch slave sessions manually, then the user
    should be able to manually switch to the encrypted slave session. I
    haven't seen this menu though, so that would explain a lot. I'm
    guessing
    it does not do this automatically, e.g. after a new encrypted
    session is
    established? ... I guess that would make sense, since it could
    frustrate
    users trying to send a message.

    > I remember that I also put some logic so that Jitsi can automacally
    > switch between carbons (down-left icon) depending on the received
    > message. The idea was that if one receives a message from a certain
    > jid, the default carbon and thus the active otr slave session
    (used to
    > encrypt outgoing messages) is switched.
    Correct, it switches ... although I think it stops switching if I
    select
    this "root" (bare?) session. Could that be right?

    >
    > ​
    >
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    >
    > Also, again if I remember correctly, there is no way to have an
    > ENCRYPTED master session because master sessions delegate session
    > initiation requests to slave sessions.
    Okay, sure, that makes sense. I did check logging I produce and it
    shows
    that the same session instance that had old status 'plaintext' and new
    status 'encrypted' has isMasterSession == true. So it seems that
    this is
    possible.

    I think I'm getting there ... given that it is possible to select
    slave
    sessions, that would mean that the encrypted session can be looked up
    manually. So in that case it could be merely a UI issue - and a lot of
    confusing messages like "Private conversation with ... lost.",
    immediately after establishing an encrypted session.

    I'm going to look into getting these slave sessions to the surface ...

    Danny

    > ​
    >
    > I hope that helps.
    >
    > Best regards,
    > Marin
    >
    > On Thu, Feb 26, 2015 at 12:50 AM, Danny van Heumen >>> > <danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl> >>> <mailto:danny@dannyvanheumen.nl <mailto:danny@dannyvanheumen.nl>>> >>> wrote:
    >
    >
    > A quick addition ... I was thinking about which combinations are
    > possible for Master - Slave session combinations.
    >
    > * Master session: PLAINTEXT + Slave session: ENCRYPTED --
    possible as
    > this is the current problem.
    >
    > * Master session: ENCRYPTED + Slave session: PLAINTEXT --
    should be
    > possible, but should not be a problem. Given that the slave
    > sessions are
    > about decrypting received messages. Sending encrypted messages
    > wouldn't
    > be a problem, since the master session is ENCRYPTED. Also,
    the session
    > status reflects the status of the Master sessions which also
    sends, so
    > the status is accurate.
    >
    > * Both PLAINTEXT shouldn't be an issue in any case, i.e. no
    encrypted
    > sessions established.
    >
    > * Both ENCRYPTED: not sure if this makes sense, but in any
    case we
    > would
    > sent an encrypted message. It might get delivered to the wrong
    > address,
    > but it wouldn't unintentionally be sent PLAINTEXT, so not an
    issue(?)
    >
    > Danny
    >
    >
    >
    > On 25-02-15 23:43, Danny van Heumen wrote:
    > > Hi all,
    > >
    > > So, here's another follow up with what I found out
    yesterday. I
    > think
    > > I may have an explanation of what happens. It's pretty
    interesting
    > > interplay of features, I think ...
    > >
    > > A FEW FACTS:
    > > * When message carbons are activated, the messages sent by one
    > client
    > > are repeated to the other clients as message delivered
    events. (I'm
    > > quite sure, but please correct me if I'm wrong here ...)
    > > * Jitsi's OTR implementation does not process message
    delivered
    > > events. (The only exception to this is to check if a
    message is
    > > injected such that the user is not bothered with OTR
    interaction
    > > inside the client.)
    > > * I found out that the session status gets updated in another
    > instance
    > > of SessionImpl than where the instance where we query for the
    > current
    > > session status. This explains both:
    > >
    > > 1. Why the statuses deviate - between session
    establishment (in log
    > > messages) and session status querying, and
    > > 2. Why messages till get decrypted when received even
    though the
    > > status is PLAINTEXT.
    > >
    > > FLOW OF EVENTS: Here's where it gets interesting ...
    > >
    > > Say we have:
    > > * An account a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> on server jit.si <http://jit.si>
    > <http://jit.si> which supports message carbons.
    > > * An account b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> on server
    > gmail.com <http://gmail.com> <http://gmail.com> which does
    not support
    > > message carbons.
    > > * Client A, a Jitsi client, with account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - with message
    > > carbons enabled - and account b@gmail.com
    <mailto:b@gmail.com> <mailto:b@gmail.com <mailto:b@gmail.com>>.
    > > * Client B, another client with account a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>> - without message
    > > carbons enabled.
    > >
    > > 1. We initiate an OTR session with client A to account
    > b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>.
    > > This means that B sends the OTR v3 query message.
    > > -- a) client A receives the request on account b@gmail.com
    <mailto:b@gmail.com>
    > <mailto:b@gmail.com <mailto:b@gmail.com>>
    > > -- b) client A receives a carbon of the request on a@jit.si <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>. This
    > > message isn't processed by otr4j, so effectively gets ignored.
    > >
    > > 2. Client A receives OTR v3 query message, answers with
    D-H commit
    > > message.
    > > -- a) client B receives the request on account a@jit.si
    <mailto:a@jit.si>
    > <mailto:a@jit.si <mailto:a@jit.si>>.
    > > -- b) client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives the message
    > carbon and sets a master
    > > session for this sender instance id, however it does not
    expect the
    > > D-H commit message so does not respond.
    > >
    > > 3. Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>) and client B
    > (b@gmail.com <mailto:b@gmail.com> <mailto:b@gmail.com
    <mailto:b@gmail.com>>) finish up OTR
    > > protocol and establish a secure session.
    > >
    > > Now Client A (b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>>) wants to
    > establish an OTR session with
    > > Client A (a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>>), so it sends initial OTR
    > v3 query message.
    > >
    > > 4. Client A on b@gmail.com <mailto:b@gmail.com>
    <mailto:b@gmail.com <mailto:b@gmail.com>> sends message to
    > a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> for client A
    > > (that is, that specific session id).
    > > -- a) Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> receives this message,
    > however it contains a
    > > different sender instance id than the message before, so a
    slave
    > > session is established. The received message gets passed
    through to
    > > slave session. Slave session handles message.
    > >
    > > 5. Client A a@jit.si <mailto:a@jit.si> <mailto:a@jit.si
    <mailto:a@jit.si>> responds and continues
    > establishing OTR encrypted
    > > session. Now Client A a@jit.si <mailto:a@jit.si>
    <mailto:a@jit.si <mailto:a@jit.si>> has 2 sessions
    > available:
    > > * Master session: PLAINTEXT, received some OTR messages but
    > nothing to
    > > establish a connection with.
    > > * Slave session: ENCRYPTED, did full processing of OTR session
    > > establishment and has a full, completed ENCRYPTED session.
    > >
    > > Now that an encrypted session is established, we call
    listeners to
    > > inform of a sessionStatusChanged(OtrContact). However, a
    call of
    > > getStatus(SessionID for OtrContact) will return the session
    > status of
    > > the MASTER session, which is plain text, since it was
    based upon the
    > > message carbons.
    > >
    > > RESULT:
    > >
    > > 1. Plain text Master session. Will answer calls to
    > getStatus(SessionID).
    > > 2. Fully established ENCRYPTED slave session. Will be
    reachable for
    > > decrypting messages, however it is completely
    off-the-radar when
    > > querying the status of a session.
    > > 3. Received messages get routed by their sender instance
    ID and
    > arrive
    > > at the slave session, get processed appropriately and
    hence get
    > > returned decrypted to Jitsi.
    > > 4. Sent messages get sent in plain text according to the
    Master
    > > session's status. Client at other end will received a
    plain text
    > > message even though it has an OTR session established.
    > >
    > > I hope this makes sense. It is a bit late, so please be
    critical and
    > > check if everything makes sense. I can clarify if there
    are any
    > > questions. (Or replay the problem and/or recheck the logging.)
    > >
    > > Assuming the above is correct, this would also explain my
    earlier
    > > comment regarding disabling message carbons. This would indeed
    > prevent
    > > establishing the early Master session, hence when the OTR
    session is
    > > deliberately initiated, this would become the Master
    session and one
    > > would indeed get the correct Session Status when queried via
    > > getStatus(SessionID).
    > >
    > > So, if this correctly establishes the problem, I am quite
    interested
    > > in how we're going to solve this one. I haven't thought about
    > this one
    > > yet ... :slight_smile:
    > >
    > > Regards,
    > > Danny
    > >
    > >
    > >
    > > On 22-02-15 21:18, Danny van Heumen wrote:
    > >> Okay, so it's time for an update on this topic ...
    > >>
    > >> @George: In case of TL;DR, could you check my commit, just to
    > be sure?
    > >>
    >
     https://github.com/jitsi/jitsi/commit/b05ec79695e1fd4bd31d8963a2b808eb84fd473a
    > >> It's about removing the conditionals so any message
    reaches the
    > otr4j
    > >> library, even if a secure session is not established yet.
    > Basically what
    > >> you suggested before.
    > >> Also, can you explain why at SessionImpl:479 (call to
    > >> setSessionStatus(ENCRYPTED)) the called method resets auth
    > (AuthContext)
    > >> to setIsSecure(false), while the passed parameter is
    > >> SessionStatus.ENCRYPTED? (It may be completely fine, but
    it seems
    > >> contradictory.)
    > >>
    > >> I've been playing around with the whole OTR UI and plugin to
    > see what I
    > >> could discover apart from the stuff we already know. I have
    > been playing
    > >> around for a few hours and this is a quick report of what
    I've
    > been able
    > >> to discover.
    > >>
    > >> 1. The raw OTR-encrypted message I received as described
    below,
    > is due
    > >> to XMPP Carbons being enabled. We receive the message
    sent from
    > another
    > >> client (same account) and we subscribed to carbon copies,
    so we
    > receive
    > >> a carbon of the raw message. This particular message flow is
    > not hooked
    > >> into otr4j, so it gets shown as a plain old message. (@fippo:
    > Thanks for
    > >> pointing out the carbons!)
    > >>
    > >> a) I'm thinking of whether or not we *can* hook that into
    > otr4j. Maybe
    > >> we can process this as a "received" message. I have not done
    > that yet,
    > >> though, because I'm not a 100% sure that there aren't any
    other
    > >> consequences. (It would be nice to see a notification of
    a message
    > >> encrypted for another session, and have the ability to
    drop the
    > message
    > >> itself, since that has no value to us.)
    > >>
    > >> 2. I have seen a mismatching padlock icon, compared to
    the actual
    > >> session and the sessions in the "Secure chat" menu. The
    > sessions listed
    > >> in "Secure chat" menu have always been accurate AFAICT. I
    have
    > not been
    > >> able to reproduce it reliably though -- and I'm starting
    to doubt
    > >> whether session selection isn't the culprit.
    > >>
    > >> 3. About encryption-state mismatches ...
    > >>
    > >> a) I have NOT been able to get a session that was not
    actually
    > >> encrypted even though Jitsi says it IS encrypted. This in
    > itself does
    > >> not prove that there isn't an issue, but it's not so easy to
    > get into
    > >> that state by just clicking buttons (with or without thinking
    > about it).
    > >>
    > >> b) I have been able to send unencrypted messages while an
    > encrypted
    > >> session was set up. HOWEVER, Jitsi accurately showed an open
    > padlock
    > >> when sending the message. The reason for this is that I had
    > selected the
    > >> "root" XMPP session and sent the message via there. If you
    > select this
    > >> session, Jitsi accurately shows an open padlock and messages
    > are sent to
    > >> all session (I think). The chat client on the other side
    accurately
    > >> warns of an unencrypted message being received. If you then
    > select one
    > >> specific XMPP session in the chat window, the padlock updates
    > and indeed
    > >> messages are sent in encrypted form.
    > >>
    > >> As far as I have been able to determine this is all expected
    > behaviour.
    > >> The root session cannot be OTR-encrypted, since it sends to
    > (multiple?)
    > >> sessions and you would need to encrypt differently for every
    > session. So
    > >> you need to select one specific session to send encrypted
    > messages. (OTR
    > >> also stores a new session instance for each XMPP session.)
    > >>
    > >> 4. Given the behaviour above, it would be good to somehow
    warn or
    > >> prevent users from selecting the "root" session if multiple
    > sessions are
    > >> known/active. This should prevent mistakes from being made.
    > >>
    > >> a) We may need to change the UI so that the "active"
    session
    > (last
    > >> message) is selected automatically and users would always
    need
    > to select
    > >> a specific session to switch. (And maybe we should not allow
    > selecting
    > >> this top-most session.)
    > >>
    > >> ... after some more hours of fiddling around and lots of
    confusing
    > >> moments ...
    > >>
    > >> 5. I have now determined that XMPP message carbons can
    > interfere with
    > >> correctly establishing an encrypted OTR sessions at one
    of two
    > sides. I
    > >> am not clear on the details yet (and I am starting to believe
    > that this
    > >> is a bug in the implementation), but this issue seems to
    arise
    > at the
    > >> side where 2 sessions are active and carbons are enabled. (I
    > see the
    > >> occasional OTR debug log entry about messages meant for
    another
    > session.)
    > >>
    > >> a) The result is an encrypted OTR session that IS
    established
    > for the
    > >> non-problematic side (account with only a single XMPP
    session). The
    > >> sessions is established fully, and it can send encrypted
    > messages. The
    > >> other side (2 active XMPP sessions) eventually decides to
    go with
    > >> plaintext and does not expose the encrypted session, even
    > though it is
    > >> established. It is established because it can decrypt any
    received
    > >> encrypted messages, however ask the OTR Session-instance
    for its
    > >> SessionStatus and it will return PLAINTEXT. Send a
    message from
    > that
    > >> side and it will send a plain text message (not encrypted).
    > NOTE that
    > >> the padlock icon consistently shows an accurate state.
    > >>
    > >> 6. Further more, a small issue which may not actually be a
    > problem. I
    > >> note this here for reference as it may only ever occur if you
    > delay the
    > >> process by debugging (stepping through code): In the OTR
    > plugin, if the
    > >> timeout-scheduler isn't cancelled in time, it will set a
    > "timeout" state
    > >> which is then used and hides the true state of the OTR
    Session
    > instance.
    > >>
    > >> Reproduction recipe for 5.:
    > >> 1. Start some other chat client. Log in the account with
    server
    > support
    > >> message carbons, e.g. @jit.si <http://jit.si>
    <http://jit.si>. This is going to
    > be the shared account.
    > >> 2. Start Jitsi. Log in with same account as in 1. Make
    sure message
    > >> carbons are enabled.
    > >> Using Jitsi, log in with another XMPP account.
    > >>
    > >> -- So now 2 XMPP accounts are active, 1 shared by Jitsi and
    > other client
    > >> - with message carbons, 1 solely for Jitsi.
    > >>
    > >> 3. Use client from 1. initiate OTR-encrypted session with
    2. using
    > >> @jit.si <http://jit.si> <http://jit.si> account
    > >> 4. Using client from 1. send message to other XMPP account.
    > >> 5. Jitsi popup shows that it received a message. Click
    popup to
    > view
    > >> message. Notice that OTR session is established.
    > >> 6. In Jitsi, select the other session for this account
    (@jit.si <http://jit.si>
    > <http://jit.si>) that is
    > >> available (which accidentally is the Jitsi client's XMPP session)
    > >> 7. Initiate OTR-encrypted session between the 2 accounts,
    both
    > in Jitsi.
    > >>
    > >> -- Notice that session correctly establishes at initiating
    > side, which
    > >> is the 1-session XMPP account solely in use by Jitsi.
    > >>
    > >> 9. Send a message over this newly instantiated OTR session.
    > >> 10. Popup shows for newly received message, click and it
    opens
    > a second
    > >> tab showing the message received on the shared @jit.si
    <http://jit.si>
    > <http://jit.si> account.
    > >>
    > >> -- Notice now that *that* account's OTR-encrypted session
    was not
    > >> recognized. The padlock is open. Sending messages now
    will send
    > them as
    > >> plain text. However, it did just receive the encrypted
    message and
    > >> decrypted it successfully.
    > >>
    > >> When enabling debug logging in OTR one notices that the
    > messages are
    > >> indeed encrypted from the side showing the OTR-encrypted
    > session, and
    > >> plain text for the other side.
    > >>
    > >> Disabling message carbons fixes the problem described above.
    > (At least,
    > >> it does for me.)
    > >>
    > >>
    > >> Sorry for making this such a long post. To conclude: I have
    > been trying
    > >> to get a feel for the state of OTR support in Jitsi. We
    already
    > knew of
    > >> some issues with state mangement. I believe these
    findings may have
    > >> fine-tuned this issue a bit. For now I do not see any big
    problems,
    > >> especially since the UI always showed an accurate state.
    > Confusion is
    > >> mostly caused by XMPP's message carbons together with
    multiple
    > active
    > >> sessions, which also makes the issues local to the XMPP
    > protocol. The
    > >> confusion is focused on using the UI, as OTR seems to do the
    > right thing
    > >> in the background. EXCEPT for this one issue described above
    > where the
    > >> OTR-encrypted session should have been established at both
    > sides. But
    > >> even then, Jitsi showed the correct state as the results were
    > accordingly.
    > >>
    > >> So, if you rely on OTR, make sure that your XMPP accounts
    have
    > message
    > >> carbons disabled. Then you should have a pretty smooth ride.
    > (As far as
    > >> I can tell from these tests.)
    > >>
    > >> Danny
    > >>
    > >>
    > >>
    > >>
    > >> On 26-01-15 10:50, George Politis wrote:
    > >>> On 25 Jan 2015, at 23:14, Danny van Heumen wrote:
    > >>>
    > >>>> Hi all,
    > >>>>
    > >>>> Quick follow-up. I haven't had as much time as I would've
    > liked. I have
    > >>>> found out the following things. (in line ...)
    > >>>>
    > >>>> On 23-01-15 21:34, Danny van Heumen wrote:
    > >>>>> Hi all,
    > >>>>>
    > >>>>> Because of recent remarks about OTR support in Jitsi, I've
    > been trying
    > >>>>> out some cases - all using XMPP as messaging protocol.
    These
    > were
    > >>>>> all in
    > >>>>> the following set up: 2 XMPP accounts on Jitsi + 1 of the
    > accounts also
    > >>>>> logged in on Pidgin.
    > >>>>>
    > >>>>> For now, here's what I've found.
    > >>>>>
    > >>>>> 1. When using multiple sessions, Jitsi doesn't seem to
    correctly
    > >>>>> distinguish and discard the
    messages-for-another-session. I
    > quickly
    > >>>>> looked at the otr4j source and if I read it correctly,
    then
    > the message
    > >>>>> gets returned unchanged. (Only took a quick look, so
    may not be
    > >>>>> accurate.) In that case the Jitsi client will just
    show the
    > >>>>> base64(encrypted) content. ... at least in this test ...
    > (So, send from
    > >>>>> Jitsi client to Pidgin client, while Jitsi also
    connected to
    > same
    > >>>>> account as Pidgin's is logged on to.)
    > >>>> It is just slightly different than I've stated above. It
    > turns out that
    > >>>> the 2nd session "listening in" (not in the malicious way)
    > does not have
    > >>>> an OTR session established. So, as a consequence this
    session
    > receives
    > >>>> encrypted messages as if they were normal messages.
    > >>>>
    > >>>> This is likely not an issue in the OTR4J library, but
    rather
    > in Jitsi
    > >>>> not including OTR4J, since it isn't enabled. I believe that
    > if OTR4J was
    > >>>> "in the loop" it would have handled this message. Maybe by
    > dropping a
    > >>>> system message saying what is happening. Need to look into
    > that further.
    > >>>>
    > >>> There seems to be an issue here. You're talking about
    > >>> OtrTransformLayer:149, right? Where this code fragment is
    > executed:
    > >>>
    > >>> f (!policy.getEnableManual()
    > >>> && sessionStatus != ScSessionStatus.ENCRYPTED
    > >>> && sessionStatus != ScSessionStatus.FINISHED)
    > >>> return evt;
    > >>>
    > >>>>> 2. Jitsi does not escape html, so when Pidgin receives the
    > message it
    > >>>>> gets interpreted as html. <b>dude</b> shows "dude" in bold
    > at Pidgin
    > >>>>> side. (Though javascript doesn't get executed :-P)
    > >>>> This one's a bit tricky. We receive a text message which is
    > encrypted.
    > >>>> Once decrypted, we need to discover whether it is
    intended as
    > HTML or
    > >>>> plain text. I'm not sure how another OTR-capable chat
    client
    > makes this
    > >>>> distinction, though looking at Pidgin's behaviour, I
    suspect
    > they may
    > >>>> simply have assumed HTML. (Otherwise it wouldn't have
    been as
    > simple to
    > >>>> inject styling in the message sent to Pidgin client.)
    > >>> Other clients, like Miranda, have the exact same problem
    when they
    > >>> communicate with Pidgin
    > (https://developer.pidgin.im/ticket/8453). I
    > >>> suppose the messages that Pidgin is sending don't have their
    > >>> contentType set correctly, right? In that case, one way
    to fix it
    > >>> would be to assume HTML if the remote client is Pidgin.
    > >>>
    > >>>>> 3. Jitsi does not unescape html received from Pidgin. So
    > "<dude>" sent
    > >>>>> at Pidgin-side, shows up as "&lt;dude&gt;" at Jitsi-side.
    > >>>> Same as above.
    > >>>>> All should be fairly easy to fix.
    > >>>> I should've known better ... saying things like that :stuck_out_tongue:
    > >>>>
    > >>>>> (Assuming Pidgin is the one behaving
    > >>>>> as expected, which I am at the moment but will try to
    check
    > before
    > >>>>> fixing things in Jitsi.)
    > >>>>>
    > >>>>> I haven't found a case yet where I get to see the actual
    > HTML that is
    > >>>>> being sent as was described in
    > >>>>>
    >
     http://lists.jitsi.org/pipermail/users/2015-January/008515.html (if I
    > >>>>> understand correctly that is ...)
    > >>>> Still same. I have only seen html entities up to now. If
    > anyone knows
    > >>>> otherwise, plz let me know.
    > >>>>
    > >>>> As an added bonus I found out that plain text messages
    aren't
    > correctly
    > >>>> escaped in the notification popup, so at least that's fixed
    > now :slight_smile:
    > >>>>
    > >>>> Danny
    > >>>>
    > >>>>> Danny
    > >>>>>
    > >>>>>
    > >>>>>
    > >>>>> _______________________________________________
    > >>>>> dev mailing list
    > >>>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>>> Unsubscribe instructions and other list options:
    > >>>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>>> _______________________________________________
    > >>>> dev mailing list
    > >>>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>>> Unsubscribe instructions and other list options:
    > >>>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>> _______________________________________________
    > >>> dev mailing list
    > >>> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >>> Unsubscribe instructions and other list options:
    > >>> http://lists.jitsi.org/mailman/listinfo/dev
    > >>
    > >>
    > >> _______________________________________________
    > >> dev mailing list
    > >> dev@jitsi.org <mailto:dev@jitsi.org>
    <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
    > >> Unsubscribe instructions and other list options:
    > >> http://lists.jitsi.org/mailman/listinfo/dev
    > >
    > >
    > >
    > > _______________________________________________
    > > dev mailing list
    > > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > > Unsubscribe instructions and other list options:
    > > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org> <mailto:dev@jitsi.org
    <mailto:dev@jitsi.org>>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev
    >
    >
    >
    >
    > _______________________________________________
    > dev mailing list
    > dev@jitsi.org <mailto:dev@jitsi.org>
    > Unsubscribe instructions and other list options:
    > http://lists.jitsi.org/mailman/listinfo/dev

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

* Danny van Heumen <danny@dannyvanheumen.nl>
* 0x911958D0:0xB82BC76A

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev