First message is sent unencrypted

[Moritz Naumann]

Binary package hint: pidgin-otr

A friend I communicate with encrypted regularly uses multiple computers running Ubuntu 11.04 and Ubuntu 10.04 with Pidgin and its OTR plugin on them (all packages are installed from official Ubuntu package repositories) and different OTR keys on these computers. I use bitlbee and bitlbee-otr on Ubuntu 11.04 on a single computer when communicating with him.

When he sends me an encrypted message, then takes a break for several hours (not sure whether this is required to trigger this behaviour), then changes computers (not sure whether this is required to trigger this behaviour), then sends me another message, I receive this first message unencrypted. Bitlbee/bitlbee-otr/libotr report:

<root> otr: The following message received from [friends' XMPP account] was not encrypted: [[unencrypted message]]

This has happened several times now. Either the timing factor (session timeout) or the multiple OTR keys factor seem to trigger it - this is difficult to diagnose.

This may be a bug in pidgin-otr or in libotr itself.

Possibly related:
https://bugs.kde.org/show_bug.cgi?id=274099 :: Kopete OTR leaks unencrypted messages (Kubuntu 11.04)
http://bugs.bitlbee.org/bitlbee/ticket/759 :: OTR messages in query window (Ubuntu 10.10)

[Ted (tedks)]

I'm removing the classification as a security vulnerability, because the expected behavior currently for OTR sessions is that they'll be either manually initiated or automatically initiated once a client detects that a chat partner is also OTR-capable.

This is a feature request, but one that I doubt will be implemented on any client, since OTR is all in-band, and it would require sending a message that non-OTR'd clients would see bare.

[Moritz Naumann (mnaumann)]

On 08.06.2011 17:23 Ted wrote:
> I'm removing the classification as a security vulnerability, because the
> expected behavior currently for OTR sessions is that they'll be either
> manually initiated or automatically initiated once a client detects that
> a chat partner is also OTR-capable.
>
> This is a feature request, but one that I doubt will be implemented on
> any client, since OTR is all in-band, and it would require sending a
> message that non-OTR'd clients would see bare.
>
> ** Changed in: libotr (Ubuntu)
> Status: New => Confirmed
>
> ** This bug is no longer flagged as a security vulnerability
>

Thanks for your comment, Ted. I assume I may not have properly explained
this, though, which may have caused a misunderstanding on the impact of
this issue.

It is not just the first message ever sent to a person which goes
unencrypted, but the first message every new day you send to someone
whom you have defined you only want to exchange encrypted messages with.
So even when both sides did the key exchange and are set to encrypt, the
first message a pidgin-otr user sends on any new day (or after an IP
address change or ... I'm not sure what exactly the trigger is) still
goes over the wire unencrypted, with no warnig given to the sending user.

I hope this explanation is better. So I wonder:

Is this how you understood my report in the first place?

Do you not think this is a security vulnerability then?

Thanks,

Moritz

[Ted (tedks)]

On Wed, 2011-06-08 at 22:24 +0000, Moritz Naumann wrote:
> On 08.06.2011 17:23 Ted wrote:
> > I'm removing the classification as a security vulnerability, because the
> > expected behavior currently for OTR sessions is that they'll be either
> > manually initiated or automatically initiated once a client detects that
> > a chat partner is also OTR-capable.
> >
> > This is a feature request, but one that I doubt will be implemented on
> > any client, since OTR is all in-band, and it would require sending a
> > message that non-OTR'd clients would see bare.
> >
> > ** Changed in: libotr (Ubuntu)
> > Status: New => Confirmed
> >
> > ** This bug is no longer flagged as a security vulnerability
> >
>
> Thanks for your comment, Ted. I assume I may not have properly explained
> this, though, which may have caused a misunderstanding on the impact of
> this issue.
>
> It is not just the first message ever sent to a person which goes
> unencrypted, but the first message every new day you send to someone
> whom you have defined you only want to exchange encrypted messages with.
> So even when both sides did the key exchange and are set to encrypt, the
> first message a pidgin-otr user sends on any new day (or after an IP
> address change or ... I'm not sure what exactly the trigger is) still
> goes over the wire unencrypted, with no warnig given to the sending user.
>
> I hope this explanation is better. So I wonder:
>
> Is this how you understood my report in the first place?
>
> Do you not think this is a security vulnerability then?
>
> Thanks,
>
> Moritz
>

This isn't a security vulnerability; this is by design.

Without an OTR session already being in place, the sender has no way of
knowing whether their peer supports OTR. As such, pidgin-otr won't try
to set up an OTR session before the first message is sent.

If the sending user wants to try to set up an OTR session manually
before a message is sent, they can do that -- the software won't make
that decision, because it'll send an ugly message to peers that don't
have OTR.

OTR sessions are not designed to be permanent, and in fact are more
secure if they aren't. If you and someone want to always talk over OTR,
always manually initiate OTR sessions before talking.

It would be nice to have a configuration option to try to set up OTR
sessions before the first message is actually sent, for people who
aren't conservative about what they send, and that would solve this bug,
so this is really a feature request. I've confirmed it, and eventually
someone who has the permission to do so should mark this as wishlist.

You should also submit this report upstream -- I don't know if the
pidgin-otr maintainer reads this bug tracker.

[Moritz Naumann (mnaumann)]

Ted, thanks for your explanations and point of view.

I think the reason we think differently about whether or not this is a security issue is that you are argumenting from a protocol and implementation design point of view while I'm argumenting from a user experience point of view, assuming the user does not know the inner workings of the protocol but sticks to the graphical user interface and, ideally, to available documentation.

It is my impression that the current user interface design causes an unsuspecting user to assume that any message sent to a remote contact whose connection she has set to be encrypted with OTR will be transferred encrypted. Basically it is the same as for an SSL/TLS encrypted connection (to the server), where the user would likely make the same assumptions about message security.

Based on my findings and the technical explanations you have kindly provided, not all messages sent to a contact whom an OTR setup exists for (keys have been exchanged and identities confirmed) is always actually encrypted. In my opinion this property of OTR sessions is not currently adequately presented to users, enticing them to falsely assume that any message they send to an OTR contact will be encrypted.

It is my opinion that the lack transporting this special property of OTR is not currently adequately presented on the GUI. Nor is it currently documented (by what I could tell). To me, this still means it is a security bug, since it leads unsuspecting users to send possibly sensitive information as cleartext over the wire.

I also agree that the improvement you suggest (adding a configuration option to try to set up OTR sessions before the first message is sent) would be a good way to handle this, if it either defaults to on or it defaults to off and a warning indicating that messages may be sent unencrypted is displayed on first use.

Finally, I will also notify upstream. Thanks for the hint about notifying them.

[Zooko Wilcox-O'Hearn (zooko)]

I'd just like to say Thank You to Moritz for explaining the security problem (resulting from the user experience) so well.

[Zooko Wilcox-O'Hearn (zooko)]

If anybody knows of an upstream bug report about this, could you give the link to it here?