[jitsi-dev] Jitsi send message intended for another session (?)


#1

Dear Devs,
After starting a chat with jit.si account with my college (OTR with green
hook) I received following message from him, where it is unclear if the
"real" message was sent somewhere else or not:

"jitsi-lh94b2 sent you a message that was intended for another session. If
you are logged in multiple times another session may have received this
message."

I am currently only using one laptop (Macbook) with latest nb jitsi 5051
with several XMPP/SIP accounts - how to interpret this message?

kind regards, MS


#2

Hello Mr. Smith,

This message indicates that your buddy has established multiple sessions
with you because you are logged in multiple times and you have received a
message from your buddy that was intended for a different session.

However, what you are experiencing is an unexpected behaviour because with
Jabber we treat different jids as a separate contacts.
Did this happen only one time? Were you able to receive any messages from
jitsi-lh94b2?

Also could you please send me logs to marin@jitsi.org for investigation.

Thanks in advance!

Best regards,
Marin

···

On Thu, Jan 23, 2014 at 11:07 AM, Mr Smith <mr.smith476@gmail.com> wrote:

Dear Devs,
After starting a chat with jit.si account with my college (OTR with green
hook) I received following message from him, where it is unclear if the
"real" message was sent somewhere else or not:

"jitsi-lh94b2 sent you a message that was intended for another session. If
you are logged in multiple times another session may have received this
message."

I am currently only using one laptop (Macbook) with latest nb jitsi 5051
with several XMPP/SIP accounts - how to interpret this message?

kind regards, MS

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


#3

Also could you please tell whether you have changed your default jid
generating settings?
Do you think that it is possible that you have the same jid as with some
previous connection?

If that's the case please let me know.

Thanks again!

Best regards,
Marin

···

On Thu, Jan 23, 2014 at 11:19 AM, Marin Dzhigarov <marin@jitsi.org> wrote:

Hello Mr. Smith,

This message indicates that your buddy has established multiple sessions
with you because you are logged in multiple times and you have received a
message from your buddy that was intended for a different session.

However, what you are experiencing is an unexpected behaviour because with
Jabber we treat different jids as a separate contacts.
Did this happen only one time? Were you able to receive any messages from
jitsi-lh94b2?

Also could you please send me logs to marin@jitsi.org for investigation.

Thanks in advance!

Best regards,
Marin

On Thu, Jan 23, 2014 at 11:07 AM, Mr Smith <mr.smith476@gmail.com> wrote:

Dear Devs,
After starting a chat with jit.si account with my college (OTR with
green hook) I received following message from him, where it is unclear if
the "real" message was sent somewhere else or not:

"jitsi-lh94b2 sent you a message that was intended for another session.
If you are logged in multiple times another session may have received this
message."

I am currently only using one laptop (Macbook) with latest nb jitsi 5051
with several XMPP/SIP accounts - how to interpret this message?

kind regards, MS

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


#4

When I was logged into the same account with both Gmail chat and
Jitsi, I experienced this issue and report it to you. Gmail chat and
Jitsi are very unlikely to generate one and the same resource, yet the
remote party in my case established an OTR session with my Jitsi and
then managed to send a message to my Gmail chat (which I couldn't
ready, of course, because the message was OTR encrypted). (Obviously,
the subject of OTR is very complicated for me to understand and I
haven't been able to grasp your previous explanations on multiple
JIDs, sessions, and what we do and do not support)

···

2014/1/23 Marin Dzhigarov <marin@jitsi.org>:

However, what you are experiencing is an unexpected behaviour because with
Jabber we treat different jids as a separate contacts.
Did this happen only one time? Were you able to receive any messages from
jitsi-lh94b2?


#5

I believe that in the case of Gmail there's an extra difficulty coming
from the fact that they route everything to everyone, regardless of
whom it was actually sent to.

Emil

···

On Thu, Jan 23, 2014 at 10:38 AM, Lyubomir Marinov <lyubomir.marinov@jitsi.org> wrote:

2014/1/23 Marin Dzhigarov <marin@jitsi.org>:

However, what you are experiencing is an unexpected behaviour because with
Jabber we treat different jids as a separate contacts.
Did this happen only one time? Were you able to receive any messages from
jitsi-lh94b2?

When I was logged into the same account with both Gmail chat and
Jitsi, I experienced this issue and report it to you. Gmail chat and
Jitsi are very unlikely to generate one and the same resource, yet the
remote party in my case established an OTR session with my Jitsi and
then managed to send a message to my Gmail chat (which I couldn't
ready, of course, because the message was OTR encrypted). (Obviously,
the subject of OTR is very complicated for me to understand and I
haven't been able to grasp your previous explanations on multiple
JIDs, sessions, and what we do and do not support)


#6

I believe that in the case of Gmail there's an extra difficulty coming
from the fact that they route everything to everyone, regardless of
whom it was actually sent to.

Hm, I didn't know this but after a quick test it seems to be true.

yet the

remote party in my case established an OTR session with my Jitsi and
then managed to send a message to my Gmail chat (which I couldn't
ready, of course, because the message was OTR encrypted).

Lyubomir, as stated by Emil in the case of Gmail every message is routed to
everyone. This means that even if you explicitly select to send your
messages to the jitsi-xxxxx resource they will get encrypted and then
routed to everyone. So what you were experiencing is to be expected.

Regards,
Marin

···

On Thu, Jan 23, 2014 at 11:41 AM, Emil Ivov <emcho@jitsi.org> wrote:

On Thu, Jan 23, 2014 at 10:38 AM, Lyubomir Marinov > <lyubomir.marinov@jitsi.org> wrote:
> 2014/1/23 Marin Dzhigarov <marin@jitsi.org>:
>> However, what you are experiencing is an unexpected behaviour because
with
>> Jabber we treat different jids as a separate contacts.
>> Did this happen only one time? Were you able to receive any messages
from
>> jitsi-lh94b2?
>
> When I was logged into the same account with both Gmail chat and
> Jitsi, I experienced this issue and report it to you. Gmail chat and
> Jitsi are very unlikely to generate one and the same resource, yet the
> remote party in my case established an OTR session with my Jitsi and
> then managed to send a message to my Gmail chat (which I couldn't
> ready, of course, because the message was OTR encrypted). (Obviously,
> the subject of OTR is very complicated for me to understand and I
> haven't been able to grasp your previous explanations on multiple
> JIDs, sessions, and what we do and do not support)

I believe that in the case of Gmail there's an extra difficulty coming
from the fact that they route everything to everyone, regardless of
whom it was actually sent to.

Emil

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


#7

(Obviously,
the subject of OTR is very complicated for me to understand and I
haven't been able to grasp your previous explanations on multiple
JIDs, sessions, and what we do and do not support)

I sense a note of sarcasm here and since I wasn't aware of the fact that I
previously didn't explain simple enough how does the OTR work I would be
happy to discuss 'JIDs, sessions and what we do and do not support' with
you and anyone else who is also interested in the subject.

So... Let's get to it...

The OTR creates Sessions. With whom does it create these Sessions? With
OtrContacts... OtrContacts are basicly [Contact, ContactResource] pairs. So
we have a separate OtrContact for every resource that a jabber Contact has,
therefore we have a separate Session for every resource that a jabber
Contact has. Also note that it is very normal to have a session with
OtrContact[Contact, null] - this is the case with all the other protocols.
Also, there is an OtrContact[Contact, null] for the bare jid in the Jabber
case.

Sessions are responsible for encrypting and decrypting plain text messages.
Each session has it's own SessionKeys which are used for encrypting and
decrypting these messages.

Suppose your buddy (lets call him Contact A) is logged in two locations and
happens to have jids A and B.
This would mean that you will have two OtrContacts - OtrContact[Contact A,
ContactResource A] and OtrContact[Contact A, ContactResource B]. Therefore,
you will have two different Sessions with the same Contact.

When your buddy sends you a message from one of his location, the first
thing you do is get the corresponding OtrContact from the
net.java.sip.communicator.plugin.otr.OtrContactManager. The next step is to
get the Session that is mapped to this OtrContact. Then this Session
decrypts the message.

When you send your buddy a message, you kind of do the same thing - you get
the appropriate OtrContact (because you know the jid of your buddy), then
you get it's Session and encrypt the message. If for some reason (like in
the gmail case that Emil mentioned) this message gets routed to your
buddy's gmail chat... that's too bad, he will not be able to decrypt the
content.

Okay, enough for jabber. Let's talk more about OTR specifics.
The newest version of the OTR protocol (OTRv3) supports "instance tags".
A quote from the protocol specification is:

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.

So what happens if the underlying protocol is SIP or anything else that
does not support ContactResources? In this case we have only one OtrContact
for every Contact - that is one [Contact, null] pair for every Contact.
Therefore, we have only one Session for every Contact.
So what if our buddy is logged in multiple times? Well... every Session has
an instance tag that is randomly generated during session creation and this
instance tag remains the same during the life cycle of the Session. Because
of the randomness, it is almost impossible for you to be logged in two
times and have the same instance tag on both places.

So your buddies can recognize you for your instance tag (that you include
in every message if the established Session is OTRv3).

Okay so... imagine this scenario - the protocol is SIP (or anything without
resources) and Person A starts OTRv3 with Person B.
Person A 's Session will remember Person B Session's instance tag and
Person B's Session will remember Person A Session's instance tag. When
these two start to exchange messages they will include [sender instance
tag, intended recipient instance tag] in these messages as stated by the
protocol specification.

So the chat goes on for a while.. then Person B logs in from his mobile
phone.

1] If his phone does not support OTRv3, which is the case with
jitsi-android, then... too bad - the android phone will most probably break
the already existing communication and disturb any further attempts of
re-establishing a new one.

2] If his phone does support OTRv3 then a Session object will be created on
the phone. And it will be almost guaranteed that this Session object will
have a different instance tag.

So as soon as Person A receives a message from Person B's phone A will know
that B is logged in multiple times. Here comes the interesting part... As
soon as Person A realises that B is logged in multiple times A's Session
will create a list of 'slave Sessions' - which will be responsible for
encrypting/decrypting all messages that go/come from these multiple
instances of B.

Okay now... Person A has one OtrContact[B, null] which is mapped to A’s
Session which has a ‘slave session’.
If A decides to send a message to B, A has to choose which of his Sessions
(either the master or the only slave) is going to encrypt the message.
<img src=’/uploads/jitsi/original/2X/a/acbb476d43a457b9278e819d908f58602732f7e8.png’ width=‘554’ height=‘431’>

This is how this looks in the UI. You most probably have never seen this
menu because it is only shown when a slave Session is created. As we know,
in Jabber we have resources so it is very unlikely that creating a slave
session is ever going to happen.

When Person A chooses Session1 (the master session) to encrypt his messages
then Person B's phone will still receive them (because SIP IM providers
route all messages to everyone). However, before trying to decrypt these
messages, which is obviously going to fail, B phone's Session will see
that these messages have different intended recipient instance tags. B
phone's Session will know that these messages are not intended for him. So
the UI displays:

"A sent you a message that was intended for another session. If you are
logged in multiple times another session may have received this message."

I hope this clears thinks up. If you have any questions please ask.

Best regards,
Marin

···

On Thu, Jan 23, 2014 at 12:03 PM, Marin Dzhigarov <marin@jitsi.org> wrote:

I believe that in the case of Gmail there's an extra difficulty coming

from the fact that they route everything to everyone, regardless of
whom it was actually sent to.

Hm, I didn't know this but after a quick test it seems to be true.

yet the

remote party in my case established an OTR session with my Jitsi and
then managed to send a message to my Gmail chat (which I couldn't
ready, of course, because the message was OTR encrypted).

Lyubomir, as stated by Emil in the case of Gmail every message is routed
to everyone. This means that even if you explicitly select to send your
messages to the jitsi-xxxxx resource they will get encrypted and then
routed to everyone. So what you were experiencing is to be expected.

Regards,
Marin

On Thu, Jan 23, 2014 at 11:41 AM, Emil Ivov <emcho@jitsi.org> wrote:

On Thu, Jan 23, 2014 at 10:38 AM, Lyubomir Marinov >> <lyubomir.marinov@jitsi.org> wrote:
> 2014/1/23 Marin Dzhigarov <marin@jitsi.org>:
>> However, what you are experiencing is an unexpected behaviour because
with
>> Jabber we treat different jids as a separate contacts.
>> Did this happen only one time? Were you able to receive any messages
from
>> jitsi-lh94b2?
>
> When I was logged into the same account with both Gmail chat and
> Jitsi, I experienced this issue and report it to you. Gmail chat and
> Jitsi are very unlikely to generate one and the same resource, yet the
> remote party in my case established an OTR session with my Jitsi and
> then managed to send a message to my Gmail chat (which I couldn't
> ready, of course, because the message was OTR encrypted). (Obviously,
> the subject of OTR is very complicated for me to understand and I
> haven't been able to grasp your previous explanations on multiple
> JIDs, sessions, and what we do and do not support)

I believe that in the case of Gmail there's an extra difficulty coming
from the fact that they route everything to everyone, regardless of
whom it was actually sent to.

Emil

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


#8

Greetings Marin,

What's it mean when I receive messages stating that "The message was
received unencrypted." but both parties (both on xmpp jit.si) have green
padlocks. I'm on W7 and wife is on Mac we both use latest nighties.Both
parties show fingerprint verified at options > security > chat

On w7 when I right-click contact in Jitsi list and choose secure chat, I
have no options for anything! Is this expected behavior? How can I make
received messages secure?!

Thanks,
jungle

···

On 23 January 2014 04:47, Marin Dzhigarov <marin@jitsi.org> wrote:

(Obviously,

the subject of OTR is very complicated for me to understand and I
haven't been able to grasp your previous explanations on multiple
JIDs, sessions, and what we do and do not support)

I sense a note of sarcasm here and since I wasn't aware of the fact that I
previously didn't explain simple enough how does the OTR work I would be
happy to discuss 'JIDs, sessions and what we do and do not support' with
you and anyone else who is also interested in the subject.

So... Let's get to it...

The OTR creates Sessions. With whom does it create these Sessions? With
OtrContacts... OtrContacts are basicly [Contact, ContactResource] pairs. So
we have a separate OtrContact for every resource that a jabber Contact has,
therefore we have a separate Session for every resource that a jabber
Contact has. Also note that it is very normal to have a session with
OtrContact[Contact, null] - this is the case with all the other protocols.
Also, there is an OtrContact[Contact, null] for the bare jid in the Jabber
case.

Sessions are responsible for encrypting and decrypting plain text
messages. Each session has it's own SessionKeys which are used for
encrypting and decrypting these messages.

Suppose your buddy (lets call him Contact A) is logged in two locations
and happens to have jids A and B.
This would mean that you will have two OtrContacts - OtrContact[Contact A,
ContactResource A] and OtrContact[Contact A, ContactResource B]. Therefore,
you will have two different Sessions with the same Contact.

When your buddy sends you a message from one of his location, the first
thing you do is get the corresponding OtrContact from the
net.java.sip.communicator.plugin.otr.OtrContactManager. The next step is to
get the Session that is mapped to this OtrContact. Then this Session
decrypts the message.

When you send your buddy a message, you kind of do the same thing - you
get the appropriate OtrContact (because you know the jid of your buddy),
then you get it's Session and encrypt the message. If for some reason (like
in the gmail case that Emil mentioned) this message gets routed to your
buddy's gmail chat... that's too bad, he will not be able to decrypt the
content.

Okay, enough for jabber. Let's talk more about OTR specifics.
The newest version of the OTR protocol (OTRv3) supports "instance tags".
A quote from the protocol specification is:

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.

So what happens if the underlying protocol is SIP or anything else that
does not support ContactResources? In this case we have only one OtrContact
for every Contact - that is one [Contact, null] pair for every Contact.
Therefore, we have only one Session for every Contact.
So what if our buddy is logged in multiple times? Well... every Session
has an instance tag that is randomly generated during session creation and
this instance tag remains the same during the life cycle of the Session.
Because of the randomness, it is almost impossible for you to be logged in
two times and have the same instance tag on both places.

So your buddies can recognize you for your instance tag (that you include
in every message if the established Session is OTRv3).

Okay so... imagine this scenario - the protocol is SIP (or anything
without resources) and Person A starts OTRv3 with Person B.
Person A 's Session will remember Person B Session's instance tag and
Person B's Session will remember Person A Session's instance tag. When
these two start to exchange messages they will include [sender instance
tag, intended recipient instance tag] in these messages as stated by the
protocol specification.

So the chat goes on for a while.. then Person B logs in from his mobile
phone.

1] If his phone does not support OTRv3, which is the case with
jitsi-android, then... too bad - the android phone will most probably break
the already existing communication and disturb any further attempts of
re-establishing a new one.

2] If his phone does support OTRv3 then a Session object will be created
on the phone. And it will be almost guaranteed that this Session object
will have a different instance tag.

So as soon as Person A receives a message from Person B's phone A will
know that B is logged in multiple times. Here comes the interesting part...
As soon as Person A realises that B is logged in multiple times A's Session
will create a list of 'slave Sessions' - which will be responsible for
encrypting/decrypting all messages that go/come from these multiple
instances of B.

Okay now... Person A has one OtrContact[B, null] which is mapped to A's
Session which has a 'slave session'.
If A decides to send a message to B, A has to choose which of his Sessions
(either the master or the only slave) is going to encrypt the message.
[image: Inline image 1]

This is how this looks in the UI. You most probably have never seen this
menu because it is only shown when a slave Session is created. As we know,
in Jabber we have resources so it is very unlikely that creating a slave
session is ever going to happen.

When Person A chooses Session1 (the master session) to encrypt his
messages then Person B's phone will still receive them (because SIP IM
providers route all messages to everyone). However, before trying to
decrypt these messages, which is obviously going to fail, B phone's
Session will see that these messages have different intended recipient
instance tags. B phone's Session will know that these messages are not
intended for him. So the UI displays:

"A sent you a message that was intended for another session. If you are
logged in multiple times another session may have received this message."

I hope this clears thinks up. If you have any questions please ask.

Best regards,
Marin

On Thu, Jan 23, 2014 at 12:03 PM, Marin Dzhigarov <marin@jitsi.org> wrote:

I believe that in the case of Gmail there's an extra difficulty coming

from the fact that they route everything to everyone, regardless of
whom it was actually sent to.

Hm, I didn't know this but after a quick test it seems to be true.

yet the

remote party in my case established an OTR session with my Jitsi and
then managed to send a message to my Gmail chat (which I couldn't
ready, of course, because the message was OTR encrypted).

Lyubomir, as stated by Emil in the case of Gmail every message is routed
to everyone. This means that even if you explicitly select to send your
messages to the jitsi-xxxxx resource they will get encrypted and then
routed to everyone. So what you were experiencing is to be expected.

Regards,
Marin

On Thu, Jan 23, 2014 at 11:41 AM, Emil Ivov <emcho@jitsi.org> wrote:

On Thu, Jan 23, 2014 at 10:38 AM, Lyubomir Marinov >>> <lyubomir.marinov@jitsi.org> wrote:
> 2014/1/23 Marin Dzhigarov <marin@jitsi.org>:
>> However, what you are experiencing is an unexpected behaviour because
with
>> Jabber we treat different jids as a separate contacts.
>> Did this happen only one time? Were you able to receive any messages
from
>> jitsi-lh94b2?
>
> When I was logged into the same account with both Gmail chat and
> Jitsi, I experienced this issue and report it to you. Gmail chat and
> Jitsi are very unlikely to generate one and the same resource, yet the
> remote party in my case established an OTR session with my Jitsi and
> then managed to send a message to my Gmail chat (which I couldn't
> ready, of course, because the message was OTR encrypted). (Obviously,
> the subject of OTR is very complicated for me to understand and I
> haven't been able to grasp your previous explanations on multiple
> JIDs, sessions, and what we do and do not support)

I believe that in the case of Gmail there's an extra difficulty coming
from the fact that they route everything to everyone, regardless of
whom it was actually sent to.

Emil

_______________________________________________
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

--
-------
inum: 883510009902611
sip: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si