[jitsi-users] Linux: chatting with more than one client of the same person gives encrypted txt messages sometimes


#1

System: Fedora 21 x86_64 8 GB Nvidia

Problem: chatting with more than one client of the same person gives
encrypted messages.

This happens most of the time, if one partner is online with Jitsi for
Android (i know, it's alpha ).

But instead of sending each client connection the correct encrypted
message (with that specific key),
jitsi sends a one-key-encrypted message to all, which leads to the
confusing encrypted messages for the other connections.

Workaround:

Select the direct connection(resource) for the person you wanne chat to,
so that only that channel is used.

best regards,
Marius

BTW: a real bugtracker would be easier :slight_smile:


#2

Hi Marius,

That's not actually a work around, but the solution to your problem,
isn't it?

The global resource is meant to be used for sending to all clients. This
is normal behaviour and provided that only the one client with the
secret key can decrypt an encrypted message, the others will only be
able to:
1. In case OTR is not supported, show the raw message, which is
encrypted - base64 encoded. Or
2. In case OTR is supported, show the message saying that the received
encrypted message is meant for another OTR session.

AFAICT this is normal behaviour.

Danny

···

On 29-04-15 23:43, Marius wrote:

System: Fedora 21 x86_64 8 GB Nvidia

Problem: chatting with more than one client of the same person gives
encrypted messages.

This happens most of the time, if one partner is online with Jitsi for
Android (i know, it's alpha ).

But instead of sending each client connection the correct encrypted
message (with that specific key),
jitsi sends a one-key-encrypted message to all, which leads to the
confusing encrypted messages for the other connections.

Workaround:

Select the direct connection(resource) for the person you wanne chat to,
so that only that channel is used.

best regards,
Marius

BTW: a real bugtracker would be easier :slight_smile:

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


#3

How can that be the indented behaviour, if it leads to messages being
unreadable ?

It may be normal, but it's wrong.

I think, this is how it should be done :

    forall(connections -> connection) {
            channelmsg = encrypt(msg, connection.key);
            sendmsg(connection, channelmsg)
    }

That way, all clients can read messages send to them. Which is the
userfriendly way, as it is expected by users/customers with multiply
devices. OR the message really gets encrypted with a multikey for this
session, which would be harder to handle.

i.e. Skype handles messages this way. Maybe not excatly in technical
terms, but the user expiriences lets it look like this.
My personal optionen is, thats the way to go.

Marius

···

Am 30.04.2015 um 00:16 schrieb Danny van Heumen:

Hi Marius,

That's not actually a work around, but the solution to your problem,
isn't it?

The global resource is meant to be used for sending to all clients. This
is normal behaviour and provided that only the one client with the
secret key can decrypt an encrypted message, the others will only be
able to:
1. In case OTR is not supported, show the raw message, which is
encrypted - base64 encoded. Or
2. In case OTR is supported, show the message saying that the received
encrypted message is meant for another OTR session.

AFAICT this is normal behaviour.

Danny


#4

How can that be the indented behaviour, if it leads to messages being
unreadable ?

It may be normal, but it's wrong.

I think, this is how it should be done :

    forall(connections -> connection) {
            channelmsg = encrypt(msg, connection.key);
            sendmsg(connection, channelmsg)
    }

That way, all clients can read messages send to them. Which is the
userfriendly way, as it is expected by users/customers with multiply
devices. OR the message really gets encrypted with a multikey for this
session, which would be harder to handle.

i.e. Skype handles messages this way. Maybe not excatly in technical
terms, but the user expiriences lets it look like this.
My personal optionen is, thats the way to go.

Marius

···

Am 30.04.2015 um 00:16 schrieb Danny van Heumen:

Hi Marius,

That's not actually a work around, but the solution to your problem,
isn't it?

The global resource is meant to be used for sending to all clients. This
is normal behaviour and provided that only the one client with the
secret key can decrypt an encrypted message, the others will only be
able to:
1. In case OTR is not supported, show the raw message, which is
encrypted - base64 encoded. Or
2. In case OTR is supported, show the message saying that the received
encrypted message is meant for another OTR session.

AFAICT this is normal behaviour.

Danny


#5

Hi Marius,

Reply in line ...

Hi Marius,

That's not actually a work around, but the solution to your problem,
isn't it?

The global resource is meant to be used for sending to all clients. This
is normal behaviour and provided that only the one client with the
secret key can decrypt an encrypted message, the others will only be
able to:
1. In case OTR is not supported, show the raw message, which is
encrypted - base64 encoded. Or
2. In case OTR is supported, show the message saying that the received
encrypted message is meant for another OTR session.

AFAICT this is normal behaviour.

Danny

How can that be the indented behaviour, if it leads to messages being
unreadable ?

Only to those clients that you didn't direct the message to. The message
only becomes completely unreadable once the client you were originally
chatting to disconnects or finishes the OTR session.

It may be normal, but it's wrong.

I think, this is how it should be done :

    forall(connections -> connection) {
            channelmsg = encrypt(msg, connection.key);
            sendmsg(connection, channelmsg)
    }

That way, all clients can read messages send to them. Which is the
userfriendly way, as it is expected by users/customers with multiply
devices. OR the message really gets encrypted with a multikey for this
session, which would be harder to handle.

Given that we're talking about private conversations using an encryption
protocol, I think we should also consider a (hypothetical) adversary.
Say that you left open a chat client somewhere. If you immediately start
broadcasting your messages to all clients (maybe even establishing OTR
sessions on the fly) then you cannot be sure that there isn't someone
somewhere who read your message. (Also, even if you do not establish
sessions on the fly, someone could establish an OTR session with an idle
chat client and hook into your existing conversation.)

I agree that there might be cases where you would want to send/receive
messages on multiple devices. However, I think just broadcasting a
message over any available session for this client, without being able
to verify its role (if any) sounds somewhat overkill to me. Even if it
is just an idle chat client, then it might be somewhere where people can
read its content.

i.e. Skype handles messages this way. Maybe not excatly in technical
terms, but the user expiriences lets it look like this.
My personal optionen is, thats the way to go.

So, what's your use case exactly? Is it simplicity of communications? Is
it to accomodate users who switch device often? ... something else?

I'm not against it per se, but I think the implementation should be such
that a user error discloses too little rather than too much.

Danny

···

On 30-04-15 01:07, Marius wrote:

Am 30.04.2015 um 00:16 schrieb Danny van Heumen:

Marius

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


#6

How can that be the indented behaviour, if it leads to messages being
unreadable ?
Only to those clients that you didn't direct the message to. The message
only becomes completely unreadable once the client you were originally
chatting to disconnects or finishes the OTR session.

See, this behavior is unexpected by users of any other chat software
with multiply devices connected at the same time.

The question is, is this really necessary for OTR to work correctly, or
is it (like in my eyes) a bug, due to incorrect message sending and
encoding.

If i want to send the message only to one specific device, i can choose
to do this. But if don't do and use the "destionation user" as target,
which implies all it's devices, than expect all his devices to be
displaying this message.

Simple example, 3x devices are online, you don't know on which the
target works atm, and you want to send a message to him.

How shall you know the correct device to choose ?
Do you send an unencrypted message ahead to announce your encrypted ? (No)

Given that we're talking about private conversations using an
encryption protocol, I think we should also consider a (hypothetical)
adversary. Say that you left open a chat client somewhere. If you
immediately start broadcasting your messages to all clients (maybe
even establishing OTR sessions on the fly) then you cannot be sure
that there isn't someone somewhere who read your message. (Also, even
if you do not establish sessions on the fly, someone could establish
an OTR session with an idle chat client and hook into your existing
conversation.) I agree that there might be cases where you would want
to send/receive messages on multiple devices. However, I think just
broadcasting a message over any available session for this client,
without being able to verify its role (if any) sounds somewhat
overkill to me. Even if it is just an idle chat client, then it might
be somewhere where people can read its content.

Get what you mean, valid point from the extrem cautiousness faction, but
i believe those guys to turn on and lock the screensaver before they
move away from the pc :wink:

The most common usecase would be a phone and a pc connection. Phones
tend to be in pockets ( or on desks at home ), and pcs should have
screenlocks when they idle. Both devices are theoretically under
physical accessibilty by attackers, but it's unlikely to happen. The
phone gets stolen, because it's there, not because it's specially yours.
A thief takes all he can, which will end his life early sometimes, but
that's a different story :slight_smile: . Pcs get hacked, because they can, not
because it's yours.

If you are the target of an agency around the world, an open device is
your least problem.

Logically, if both parties use multiply devices, the rate of successfull
transfered messages gets lower and lower with each new device.
Which also means, the practically use of the system gets lower and lower.

Solution: Give the user a choice.

Jitsi did, as you can select to send to all, or to one device ( resource
). With only one problem, "to all" isn't working :slight_smile:

Can someone now add it to the issue list :slight_smile:

.

So, what's your use case exactly? Is it simplicity of communications? Is
it to accomodate users who switch device often? ... something else?

Yes, my usecase has multiply devices for the same account. I own a
phone,a tablet, a laptop and serveral pc workstations.

I want jitsi to be the new communication system i ( and others i will
take with me ) use. Because it has all it should have,
has no american company behind the infrastructure, and offers more
features than skype does.

It's not, that i did not have a beta test running, but those tests show
more users with multiply devices, mostly pc and tablets. I'm not the
only one, and with phones everywhere, this profile will be the normal
one for millions of users. Of course you can solve it by using one
account per device, but that's not the intention.

I'm not against it per se, but I think the implementation should be such
that a user error discloses too little rather than too much.

If you have real secrets to protect, you are free to limit yourself to
one account and extreme safty, because you can do this.
But if you ignore the needs of the masses, your standing in the way of
your own success. (learned that the hard way)

The masses want, from my experience with people in all ages, it to be as
simple as it could be. This includes one account for all devices they
own. We are talking about people who can't find the correct box of
username/password, even if you send them a screenshot of jitsi with a
red mark next to the jabber box. But they wanne be free from company
control in communications too, thats why they need a smoothly working
client. As long as the transmission of the message can't be evesdropped
because is stronly encrypted, everything is fine for them.

Given more "security" to advanced users is fine and recommended, but it
should not limit the mass market to use a product.

Unfortunately, it's exactly those tiny little decisions, that decide
about mass success or failure.

Marius

···

Am 30.04.2015 um 23:08 schrieb Danny van Heumen:


#7

Zitat von Marius <jitsi@benderirc.de>:

How can that be the indented behaviour, if it leads to messages being
unreadable ?
Only to those clients that you didn't direct the message to. The message
only becomes completely unreadable once the client you were originally
chatting to disconnects or finishes the OTR session.

See, this behavior is unexpected by users of any other chat software
with multiply devices connected at the same time.

The question is, is this really necessary for OTR to work correctly, or
is it (like in my eyes) a bug, due to incorrect message sending and
encoding.

My 2 cents:

Yes, unfortunately, at the moment it is the behaviour that will happen. OTR is not designed to handle multiple devices, as there is no notion of "device" in OTR itself. It´s just a way to encrypt between 2 parties with a very high degree of robustness, key length and easy of use (since key exchange is automatic etc.).

OTR is already a leap forward, as before (in old times) opportunistic encryption was not available to instant messaging as such.

But, I agree, myself is trouble with that multiple device thingy. I often receive a message from a friend "intended for a different connection" and, of course, unreadable. Since somehow OTR was not properly terminated.

Also this happens:

"Sometimes whenever one of the clients looses it's OTR session state whenever one clients transmits OTR encrypted messages, the other client replies with an "message unreadable" response which triggers an session refresh. During this refresh is in progress the other client seems to trigger an refresh too which leads to another unreadable message which leads to continuous refreshing of client states (which can only be aborted by terminating the OTR session - sometimes it's necassary to do this twice)
Additional Information It's possible that one of the clients has "Force OTR" enabled (not determineable currently).

Sometimes the same effect happens if the other user forgets to take down a second online client that's capable of OTR too (of course caused by both clients responding to OTR session initialization)"

(taken from an internal ticket of my group of testers)

So, OTR is not 100% "end-user-ready", but I think it´s the right way to go. If you want to join a small group of testers I would welcome your feedback :wink: - We are trying to really find those comfort/end-user issues to better direct them into the development pipeline (most end-users will not come to this mailing list for example).

BR Florian

···

Am 30.04.2015 um 23:08 schrieb Danny van Heumen:


#8

Hi Marius,

You make some good points. Especially your question of how to iniate a
session directed at a specific client if you don't know which XMPP
(transport) session to pick is something that's not really possible
without any a priori information. At least I don't think it is.

So, yeah, I think we should make it an official issue :slight_smile:
Issue https://github.com/jitsi/jitsi/issues/115 created. Feel free to
add your remarks if you have any. I refer to your last email in the
issue itself.

Danny

···

On 04-05-15 10:10, Marius wrote:

Am 30.04.2015 um 23:08 schrieb Danny van Heumen:

How can that be the indented behaviour, if it leads to messages being
unreadable ?
Only to those clients that you didn't direct the message to. The message
only becomes completely unreadable once the client you were originally
chatting to disconnects or finishes the OTR session.

See, this behavior is unexpected by users of any other chat software
with multiply devices connected at the same time.

The question is, is this really necessary for OTR to work correctly, or
is it (like in my eyes) a bug, due to incorrect message sending and
encoding.

If i want to send the message only to one specific device, i can choose
to do this. But if don't do and use the "destionation user" as target,
which implies all it's devices, than expect all his devices to be
displaying this message.

Simple example, 3x devices are online, you don't know on which the
target works atm, and you want to send a message to him.

How shall you know the correct device to choose ?
Do you send an unencrypted message ahead to announce your encrypted ? (No)

Given that we're talking about private conversations using an
encryption protocol, I think we should also consider a (hypothetical)
adversary. Say that you left open a chat client somewhere. If you
immediately start broadcasting your messages to all clients (maybe
even establishing OTR sessions on the fly) then you cannot be sure
that there isn't someone somewhere who read your message. (Also, even
if you do not establish sessions on the fly, someone could establish
an OTR session with an idle chat client and hook into your existing
conversation.) I agree that there might be cases where you would want
to send/receive messages on multiple devices. However, I think just
broadcasting a message over any available session for this client,
without being able to verify its role (if any) sounds somewhat
overkill to me. Even if it is just an idle chat client, then it might
be somewhere where people can read its content.

Get what you mean, valid point from the extrem cautiousness faction, but
i believe those guys to turn on and lock the screensaver before they
move away from the pc :wink:

The most common usecase would be a phone and a pc connection. Phones
tend to be in pockets ( or on desks at home ), and pcs should have
screenlocks when they idle. Both devices are theoretically under
physical accessibilty by attackers, but it's unlikely to happen. The
phone gets stolen, because it's there, not because it's specially yours.
A thief takes all he can, which will end his life early sometimes, but
that's a different story :slight_smile: . Pcs get hacked, because they can, not
because it's yours.

If you are the target of an agency around the world, an open device is
your least problem.

Logically, if both parties use multiply devices, the rate of successfull
transfered messages gets lower and lower with each new device.
Which also means, the practically use of the system gets lower and lower.

Solution: Give the user a choice.

Jitsi did, as you can select to send to all, or to one device ( resource
). With only one problem, "to all" isn't working :slight_smile:

Can someone now add it to the issue list :slight_smile:

.

So, what's your use case exactly? Is it simplicity of communications? Is
it to accomodate users who switch device often? ... something else?

Yes, my usecase has multiply devices for the same account. I own a
phone,a tablet, a laptop and serveral pc workstations.

I want jitsi to be the new communication system i ( and others i will
take with me ) use. Because it has all it should have,
has no american company behind the infrastructure, and offers more
features than skype does.

It's not, that i did not have a beta test running, but those tests show
more users with multiply devices, mostly pc and tablets. I'm not the
only one, and with phones everywhere, this profile will be the normal
one for millions of users. Of course you can solve it by using one
account per device, but that's not the intention.

I'm not against it per se, but I think the implementation should be such
that a user error discloses too little rather than too much.

If you have real secrets to protect, you are free to limit yourself to
one account and extreme safty, because you can do this.
But if you ignore the needs of the masses, your standing in the way of
your own success. (learned that the hard way)

The masses want, from my experience with people in all ages, it to be as
simple as it could be. This includes one account for all devices they
own. We are talking about people who can't find the correct box of
username/password, even if you send them a screenshot of jitsi with a
red mark next to the jabber box. But they wanne be free from company
control in communications too, thats why they need a smoothly working
client. As long as the transmission of the message can't be evesdropped
because is stronly encrypted, everything is fine for them.

Given more "security" to advanced users is fine and recommended, but it
should not limit the mass market to use a product.

Unfortunately, it's exactly those tiny little decisions, that decide
about mass success or failure.

Marius

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


#9

Hi Florian,

Replies in line ...

Danny

Zitat von Marius <jitsi@benderirc.de>:

How can that be the indented behaviour, if it leads to messages being
unreadable ?
Only to those clients that you didn't direct the message to. The
message
only becomes completely unreadable once the client you were originally
chatting to disconnects or finishes the OTR session.

See, this behavior is unexpected by users of any other chat software
with multiply devices connected at the same time.

The question is, is this really necessary for OTR to work correctly, or
is it (like in my eyes) a bug, due to incorrect message sending and
encoding.

My 2 cents:

Yes, unfortunately, at the moment it is the behaviour that will
happen. OTR is not designed to handle multiple devices, as there is no
notion of "device" in OTR itself. It´s just a way to encrypt between 2
parties with a very high degree of robustness, key length and easy of
use (since key exchange is automatic etc.).

For completeness, I want to add that OTRv3 does have a notion of
"instances". Each instance represents a different client/session, so in
that sense there is a limited notion of a device - or at least a way to
distinguish messages from different devices that all have OTR-encrypted
sessions active simultaneously.

OTR is already a leap forward, as before (in old times) opportunistic
encryption was not available to instant messaging as such.

But, I agree, myself is trouble with that multiple device thingy. I
often receive a message from a friend "intended for a different
connection" and, of course, unreadable. Since somehow OTR was not
properly terminated.

The other use case, the one I had recently, is where a friend (re)uses
his previous OTR session at a later moment, when I already ended the
session and consequently lost my encryption secret.

Also this happens:

"Sometimes whenever one of the clients looses it's OTR session state
whenever one clients transmits OTR encrypted messages, the other
client replies with an "message unreadable" response which triggers an
session refresh. During this refresh is in progress the other client
seems to trigger an refresh too which leads to another unreadable
message which leads to continuous refreshing of client states (which
can only be aborted by terminating the OTR session - sometimes it's
necassary to do this twice)
Additional Information It's possible that one of the clients has
"Force OTR" enabled (not determineable currently).

I am quite sure that this is one of the use cases that is supposed to be
solved with OTRv3 with the introduction of instance tags. (What I
already referred to in my response above.)

···

On 04-05-15 12:45, flori@bin.org.in wrote:

Am 30.04.2015 um 23:08 schrieb Danny van Heumen:

Sometimes the same effect happens if the other user forgets to take
down a second online client that's capable of OTR too (of course
caused by both clients responding to OTR session initialization)"

(taken from an internal ticket of my group of testers)

So, OTR is not 100% "end-user-ready", but I think it´s the right way
to go. If you want to join a small group of testers I would welcome
your feedback :wink: - We are trying to really find those comfort/end-user
issues to better direct them into the development pipeline (most
end-users will not come to this mailing list for example).

BR Florian

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