[jitsi-dev] OTR test request


#1

Hello all,

A few days ago we did a major update in the OTR plugin.

I would very much appreciate if you could play with the OTR a bit and see
if you could find anything that does not seem ordinary or suspicious. You
can report it here.

Thanks in advance!

Best regards,
Marin


#2

Hello, Marin!

OTR on the desktop (as opposed to Android) has started acted up again.
It automatically enables itself upon starting a conversation and I
have to click on the lock icon in the chat window to stop it.

Additionally, it does not seem to me to act properly when I'm logged
in with the same account at multiple locations. I start a conversation
with a contact in Jitsi on the desktop, OTR kicks in by itself without
me requesting that and we successfully exchange messages. After some
time, that same contact send me a message and I receive it in Gmail
chat on the desktop or Hangouts on Android but it's encrypted there
and I cannot read it. Given the fact that these use different JID
resources, I'm not sure why the messages they receive are encrypted
given that I cannot possible start OTR from there. Please excuse my
lack of understanding on the subject.

Regards,
Lyubomir


#3

A few days ago we did a major update in the OTR plugin.

I would very much appreciate if you could play with the OTR a bit and see

if

you could find anything that does not seem ordinary or suspicious. You can
report it here.

I just had something unexpected when chatting with Emil:
OTR initiated itself automatically and the padlock was closed. At some point
Emil quit Jitsi and the destination resource changed automatically to
another endpoint which was signed in at a non-OTR capable endpoint. Jitsi
switched back to non-encrypted messaging without giving any notice. I'm not
sure who sent the first message after the resource-change, but I think it
was Emil.

The padlock was open though, but you need actively look at this.

Thanks in advance!

Best regards,
Marin

Ingo


#4

We just had a very annoying situation with Lyubomir. I'd start chatting with him and OTR will automatically kick in. As soon as the session is established however, something bad happened and my messages could no longer be sent. I'd get a "message not sent" error. I'd turn off OTR in order to continue but then it would auto kick in once more and then repeat the entire thing again and again and again ...

I think there are three issues here:

1. There's nothing that I see or not even in the logs, that helps me understand why it is exactly that the send operation failed. We should add some sort of a reason.

2. When reporting the failure we should also print the message text so that I could copy paste it in my subsequent attempt.

3. We shouldn't auto reconnect in a window/chat where OTR has been manually turned off.

Emil

···

On 16.01.14, 10:19, Marin Dzhigarov wrote:

Hello all,

A few days ago we did a major update in the OTR plugin.

I would very much appreciate if you could play with the OTR a bit and
see if you could find anything that does not seem ordinary or
suspicious. You can report it here.

Thanks in advance!

Best regards,
Marin

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

--
https://jitsi.org


#5

Hello Lyubomir,

OTR on the desktop (as opposed to Android) has started acted up again.

It automatically enables itself upon starting a conversation and I
have to click on the lock icon in the chat window to stop it.

Yes, that's correct. The expected default behaviour is for the OTR to start
automatically when possible.
If one wants though, he could either disable OTR with the respective
Contact from Secure chat -> uncheck Enable private conversations or
he could uncheck Secure chat -> "Automatically start private conversations
with Contact/All Contacts".
However, with the second/third option one would not prevent others to start
OTR with him, but he will stop attaching the so called "otr whitespace
tags" to every message he sends. The semantics of these "whitespace tags"
are expressing the desire of the sender to establish an encrypted session
with the remote party.

After some

time, that same contact send me a message and I receive it in Gmail
chat on the desktop or Hangouts on Android but it's encrypted there
and I cannot read it.

Do you know whether the remote party is also logged in the latest Jitsi's
desktop? If yes then this is probably a bug.
If not, however, then this behaviour is expected. As we know, your contact
had previously established otr session with you. Most of the instant
messengers out there (including Adium, Pidgin and Jitsi before the update)
do not support establishing separate OTR sessions for separete jids of the
same contact. This means that if your contact has changed his outgoing jid
for some reason then he would have encrypted the message with the
previously established session keys and your Andoid device would not be
able to read it.

I hope this clears things up a bit.
If you have any further questions feel free to ask

Best regards,
Marin

···

On Fri, Jan 17, 2014 at 6:32 PM, Lyubomir Marinov < lyubomir.marinov@jitsi.org> wrote:

Hello, Marin!

OTR on the desktop (as opposed to Android) has started acted up again.
It automatically enables itself upon starting a conversation and I
have to click on the lock icon in the chat window to stop it.

Additionally, it does not seem to me to act properly when I'm logged
in with the same account at multiple locations. I start a conversation
with a contact in Jitsi on the desktop, OTR kicks in by itself without
me requesting that and we successfully exchange messages. After some
time, that same contact send me a message and I receive it in Gmail
chat on the desktop or Hangouts on Android but it's encrypted there
and I cannot read it. Given the fact that these use different JID
resources, I'm not sure why the messages they receive are encrypted
given that I cannot possible start OTR from there. Please excuse my
lack of understanding on the subject.

Regards,
Lyubomir

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


#6

OTR on the desktop (as opposed to Android) has started acted up again.
It automatically enables itself upon starting a conversation and I
have to click on the lock icon in the chat window to stop it.

Yes, that's correct. The expected default behaviour is for the OTR to start
automatically when possible.
If one wants though, he could either disable OTR with the respective Contact
from Secure chat -> uncheck Enable private conversations or
he could uncheck Secure chat -> "Automatically start private conversations
with Contact/All Contacts".
However, with the second/third option one would not prevent others to start
OTR with him, but he will stop attaching the so called "otr whitespace tags"
to every message he sends. The semantics of these "whitespace tags" are
expressing the desire of the sender to establish an encrypted session with
the remote party.

Thank you very much, Marin!

After some
time, that same contact send me a message and I receive it in Gmail
chat on the desktop or Hangouts on Android but it's encrypted there
and I cannot read it.

Do you know whether the remote party is also logged in the latest Jitsi's
desktop? If yes then this is probably a bug.
If not, however, then this behaviour is expected. As we know, your contact
had previously established otr session with you. Most of the instant
messengers out there (including Adium, Pidgin and Jitsi before the update)
do not support establishing separate OTR sessions for separete jids of the
same contact. This means that if your contact has changed his outgoing jid
for some reason then he would have encrypted the message with the previously
established session keys and your Andoid device would not be able to read
it.

I hope this clears things up a bit.
If you have any further questions feel free to ask

Please let me bother you a bit more with that.

I read the following at
http://osdir.com/ml/security.otr.user/2008-06/msg00005.html:

···

2014/1/17 Marin Dzhigarov <marin@jitsi.org>:
-----
This all having been said, the "multiple logins" problem is one that's
been bothering us for a really long time, and I'm happy to say that
we've now got someone working on fixing exactly that issue. It won't be
in the (imminent) 3.2.0 release, but will almost certainly be in v4.
-----

I went to https://otr.cypherpunks.ca and read the following excerpt of
news published on September 4th, 2012:
-----
pidgin-otr 4.0.0 and libotr 4.0.0 released

The long-awaited version 4.0.0 of pidgin-otr and libotr are finally here!

The main new features in 4.0.0:

- The plugin now supports multiple OTR conversations with the same
buddy who is logged in at multiple locations. In this case, a new OTR
menu will appear, which allows you to select which session an outgoing
message is intended for. Note that concurrent SMP authentications with
the same buddy who is logged in multiple times is not yet supported
(starting a second authentication will end the first).

libotr API changes:

- instance tags, to support multiple simultaneous logins
-----

What does that mean?


#7

Hello,

libotr API changes:

- instance tags, to support multiple simultaneous logins
-----

What does that mean?

You are thinking in the right direction - the instance tags are used for
managing your buddy's multiple logins and distinguishing between his
sessions. This is a new feature introduced by the newest version of the OTR
protocol. However, with the Jabber protocol we already have the jids that
uniquely identify each login of the remote party so we could use them.

That's right, in Jitsi we create different sessions as soon as we realize
that the remote party have multiple jids instead of waiting for instance
tags and such (in the Jabber case only). If we didn't do this we would have
to use the instance tags in order to switch from session to session. But we
also have the resource switch menu in the chat panel that switches between
jids. Imagine we had both - resource switch menu and instance tag switch
menu. Users would get very confused. What could also happen is that users
would choose a some resource from the menu but then choose an instance tag
that corresponds to a different session.

I just had something unexpected when chatting with Emil:

OTR initiated itself automatically and the padlock was closed. At some
point
Emil quit Jitsi and the destination resource changed automatically to
another endpoint which was signed in at a non-OTR capable endpoint. Jitsi
switched back to non-encrypted messaging without giving any notice. I'm not
sure who sent the first message after the resource-change, but I think it
was Emil.

The padlock was open though, but you need actively look at this.

This is due to the reason that the outgoing resource has changed.
Should we make some kind of extra indication in such cases? Isn't the open
padlock enough already?

Best regards,
Marin

···

On Fri, Jan 17, 2014 at 9:51 PM, Lyubomir Marinov < lyubomir.marinov@jitsi.org> wrote:

2014/1/17 Marin Dzhigarov <marin@jitsi.org>:
>> OTR on the desktop (as opposed to Android) has started acted up again.
>> It automatically enables itself upon starting a conversation and I
>> have to click on the lock icon in the chat window to stop it.
>
>
> Yes, that's correct. The expected default behaviour is for the OTR to
start
> automatically when possible.
> If one wants though, he could either disable OTR with the respective
Contact
> from Secure chat -> uncheck Enable private conversations or
> he could uncheck Secure chat -> "Automatically start private
conversations
> with Contact/All Contacts".
> However, with the second/third option one would not prevent others to
start
> OTR with him, but he will stop attaching the so called "otr whitespace
tags"
> to every message he sends. The semantics of these "whitespace tags" are
> expressing the desire of the sender to establish an encrypted session
with
> the remote party.

Thank you very much, Marin!

>> After some
>> time, that same contact send me a message and I receive it in Gmail
>> chat on the desktop or Hangouts on Android but it's encrypted there
>> and I cannot read it.
>
>
> Do you know whether the remote party is also logged in the latest Jitsi's
> desktop? If yes then this is probably a bug.
> If not, however, then this behaviour is expected. As we know, your
contact
> had previously established otr session with you. Most of the instant
> messengers out there (including Adium, Pidgin and Jitsi before the
update)
> do not support establishing separate OTR sessions for separete jids of
the
> same contact. This means that if your contact has changed his outgoing
jid
> for some reason then he would have encrypted the message with the
previously
> established session keys and your Andoid device would not be able to read
> it.
>
> I hope this clears things up a bit.
> If you have any further questions feel free to ask

Please let me bother you a bit more with that.

I read the following at
http://osdir.com/ml/security.otr.user/2008-06/msg00005.html:
-----
This all having been said, the "multiple logins" problem is one that's
been bothering us for a really long time, and I'm happy to say that
we've now got someone working on fixing exactly that issue. It won't be
in the (imminent) 3.2.0 release, but will almost certainly be in v4.
-----

I went to https://otr.cypherpunks.ca and read the following excerpt of
news published on September 4th, 2012:
-----
pidgin-otr 4.0.0 and libotr 4.0.0 released

The long-awaited version 4.0.0 of pidgin-otr and libotr are finally here!

The main new features in 4.0.0:

- The plugin now supports multiple OTR conversations with the same
buddy who is logged in at multiple locations. In this case, a new OTR
menu will appear, which allows you to select which session an outgoing
message is intended for. Note that concurrent SMP authentications with
the same buddy who is logged in multiple times is not yet supported
(starting a second authentication will end the first).

libotr API changes:

- instance tags, to support multiple simultaneous logins
-----

What does that mean?


#8

Actually, we seem to already have such indication. It says:

"The message was received unencrypted"

However we are only using it when an unencrypted message arrives within an OTR session. I think the easiest way of addressing this would be to have colour codes for encrypted and plain messages but that would probably be better implemented once we integrate chromium.

Emil

···

On 20.01.14, 08:43, Marin Dzhigarov wrote:

This is due to the reason that the outgoing resource has changed.
Should we make some kind of extra indication in such cases? Isn't the
open padlock enough already?

--
https://jitsi.org