From ian@cypherpunks.ca Sun Apr 1 00:04:24 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sat, 31 Mar 2007 19:04:24 -0400 Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd In-Reply-To: <200703301528.54920.ogoffart@kde.org> References: <200703301528.54920.ogoffart@kde.org> Message-ID: <20070331230424.GE5791@yoink.cs.uwaterloo.ca> On Fri, Mar 30, 2007 at 03:28:49PM +0200, Olivier Goffart wrote: > Hello, > > I have developed a module for ejabberd (A widely used Jabber server) that do > the man in the middle attack on OTR messages. Cool! I remember a long time ago people were talking about doing this for Trillian's SecureIM (which has no way at all to authenticate users), but I think (at least at the time) Trillian's SecureIM only worked on AIM, not Jabber. > I made this module to show that it is not possible to make e2e encryption user > friendly. (for those who want an easy-to-use enabled-by-default e2e > encryption) > Lamda user (who doesn't really care about security) will not check > fingerprint. But also remember that even if OTR is turned on by default, and Lambda user doesn't know anything about checking fingerprints, he's no worse off than if OTR weren't there to begin with, and is better off against at least some kinds of attackers. > So now, check your fingerprints :-) Yes, please do. :-) - Ian From donny.viszneki@gmail.com Sun Apr 1 00:44:36 2007 From: donny.viszneki@gmail.com (Donny Viszneki) Date: Sat, 31 Mar 2007 19:44:36 -0400 Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd In-Reply-To: References: <200703301528.54920.ogoffart@kde.org> Message-ID: <44acbb800703311644u6addd811n7924e8e22fa62432@mail.gmail.com> On 3/31/07, Paul Wouters wrote: > On Fri, 30 Mar 2007, Olivier Goffart wrote: > > I made this module to show that it is not possible to make e2e encryption user > > friendly. > I would call OTR pretty userfriendly.... Please distinguish between user-friendly and idiot-friendly. If "it is not possible to make e2e encryption user-friendly" because you choose to lump complete morons in with the rest of the computer-using world, how far are you from saying that password authentication isn't safe? (Think about it -- even some of the most inane phishing scams can see quite a bit of success.) However, I do acknowledge that the idea of the fingerprint is not one that has experienced a great deal of penetration into the collective of mainstream computer users. I don't think this is the same as being user-unfriendly. However in my personal experience, many mainstream users are impatient when it comes to learning new ideas, and therefore it may be best to attack the problem of mainstream penetration head-on. I have a strange idea of how to do that which I'm sure others have thought of, but I have been sitting on it for the better part of a decade and so I figure I might as well throw it out there now that the discussion has begun: I have been rolling around an idea in my mind for a long time to improve the utility of fingerprint/checksum mechanisms by making fingerprints more memorable. What if the output of a hash weren't such tightly packed, seemingly random data? What if you plugged fingerprints into a dictionary file and got out a couple of words instead? What if you plugged it into a clipart library? Or the library of congress? Your encryption fingerprint could be the face of George Washington, five red-and-white striped ponies, or a line from a poem by Edgar Allen Poe. The more coherent and meaningful fingerprints/checksums are, the more memorable they are, and IMHO that makes them more useful. One challenge would be getting everyone to agree on what fingerprinting mechanism / service to use. A much more interesting challenge though would be studying what characteristics make a "humanistic fingerprinting" mechanism most effective. With the basic idea out of the way, here are a few elaborations: Using familiar graphical transformations such as recoloring, contorting, flipping, or tiling, you can increase the total output potential of any graphical media library perahps a hundred fold. Maybe the hash of the file you're looking for can be represented as a multi-colored and tiled (like a Warhol) George Bush Sr. Or maybe it is the upside-down silouette of a pine tree masked over the colors of the rainbow. Another idea would be to use a "generative" mechanism which would constitute its own humanistic representation algorithmically without requiring a multimedia library to draw from. It might produce anything from something reminiscent of modern art, to techno music authored by a psyconaut nearing the end of a four-day trip, or even the rorschac you might get during a psychological evaluation: but it does have the advantage of potentially being implemented with a small footprint and wouldn't require access to an enormous media library to draw upon. As mentioned earlier, I'm sure a lot of research could be invested in determining which techniques produce the most effective output. I have more to say on the subject but I just spent 6 minutes typing that I really should be spending working! If anyone has any comments feel free to email me. I really think that making fingerprinting a visual experience would garner more attention from the mainstream as well as developers for mainstream applications (I'd love to see the tiled shape of a turtle like a work by Escher the next time a "Could not verify SSL certificate" dialog pops up in Firefox ;) From paul@cypherpunks.ca Mon Apr 2 07:04:07 2007 From: paul@cypherpunks.ca (Paul Wouters) Date: Mon, 2 Apr 2007 08:04:07 +0200 (CEST) Subject: [OTR-dev] mod_otr: man in the middle implementation for ejabberd In-Reply-To: <44acbb800703311644u6addd811n7924e8e22fa62432@mail.gmail.com> References: <200703301528.54920.ogoffart@kde.org> <44acbb800703311644u6addd811n7924e8e22fa62432@mail.gmail.com> Message-ID: On Sat, 31 Mar 2007, Donny Viszneki wrote: > However, I do acknowledge that the idea of the fingerprint is not one > that has experienced a great deal of penetration into the collective > of mainstream computer users. Using the "session id" is easier for "non computer experts". I have been thinking how to make it more friendly towards "non computer experts". Perhaps we could permanently display the session-id somewhere. Another issue is that no non-expert will even realise to right-click the OTR button. The alternative via pop-ups though is also not a good way, and annoys the heck out of the more expert users. > I have been rolling around an idea in my mind for a long time to > improve the utility of fingerprint/checksum mechanisms by making > fingerprints more memorable. What if the output of a hash weren't such > tightly packed, seemingly random data? What if you plugged > fingerprints into a dictionary file and got out a couple of words > instead? What if you plugged it into a clipart library? Or the library > of congress? Similar things have been done before, such as bubble-babble. > As mentioned earlier, I'm sure a lot of research could be invested in > determining which techniques produce the most effective output. I'm not sure how that all fits into the fingerprint of the *other* user.... Paul From paul@xelerance.com Tue Apr 17 04:52:16 2007 From: paul@xelerance.com (Paul Wouters) Date: Tue, 17 Apr 2007 05:52:16 +0200 (CEST) Subject: [OTR-dev] Re: IMPORTANT: gaim renamed to pidgin In-Reply-To: <462442AC.9070204@redhat.com> References: <462442AC.9070204@redhat.com> Message-ID: On Mon, 16 Apr 2007, Warren Togami wrote: > I have e-mailed you because you are listed as owners of gaim-* plugin packages > in Extras. Your action is now required to fix your plugins and rename them so Upstream for gaim-otr will not rename, at least not at this point. Is it okay to just fix the plugin's dependancies? I don't think I would like to see a "pidgin-otr" package rename where the original upstream package is still called "gaim-otr". > that deps will resolve and upgrade automatically. Please file an Extras > package review ticket with your new package, and assign it to me so that I may > expedite replacement of these packages. In which case this all does not apply to gaim-otr (apart from just fixing my package tomorrow when pidgin is available in the repository) Paul -- Building and integrating Virtual Private Networks with Openswan: http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155 From mail@scottellis.com.au Sun Apr 29 06:47:46 2007 From: mail@scottellis.com.au (Scott Ellis) Date: Sun, 29 Apr 2007 15:47:46 +1000 Subject: [OTR-dev] session termination Message-ID: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> ------=_Part_92308_17879270.1177825666237 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Had the following bug report from a miranda user talking to a gaim user (thx Zeffel): "Scenario: Chat "blabla". Miranda user goes offline. Gaim OTR doesn't seem to notice this. Gaim user sends Miranda user offline message. When Miranda user goes back online, he receives: '[OTR Message] The encrypted message received from Gaim user is unreadable, as you are not currently communicating privately.' So Gaim OTR still sends an encrypted message, though Miranda user went offline. Miranda user can't decrypt the message any more." >From the OTR protocol description: "MSGSTATE_FINISHEDThis state indicates that outgoing messages are not delivered at all. This state is entered only when the other party indicates he has terminated his side of the OTR conversation. For example, if Alice and Bob are having an OTR conversation, and Bob instructs his OTR client to end its private session with Alice (for example, by logging out), Alice will be notified of this, and *her* client will switch to MSGSTATE_FINISHED mode. This prevents Alice from accidentally sending a message to Bob in plaintext. (Consider what happens if Alice was in the middle of typing a private message to Bob when he suddenly logs out, just as Alice hits Enter.)"My question is this: does the fact that Bob went offline not qualify as an indication that he has terminated his side of the OTR converstaion? Shouldn't the client call the 'otrl_force_finished' function in this situation, rather than requiring the reception of a termination message? It seems to me there are a few problems with the method if this is not the case, when compared to the alternative of ending sessions when either the client detects that the user on the other side has gone offline *or* it gets a session termination message: 1) the bug described above will still happen if the user is disconnected 'involantarily', e.g. due to network problems, or (heaven forbid) their client crashes, etc. 2) it doesn't seem to solve the problem described in the spec any better than the alternative 3) it can add unwanted delays when the user is attempting to switch status, e.g. when using a protocol with full message acknowledgement 4) protocol implementations may well discard pending messages when going offline, if their specification provides no guarantees of delivery 5) it causes problems with protocols that allow offline messages, such as ICQ and Jabber 6) it's problematic coping with system shutdown The only benefit of using a termination message is that you can go offline and back online without renogotiating the session if you don't quit the client, as far as i can see. Obviously not worth it, imo. Currently the miranda plugin is using the alternative method and does not send an OTR termination message when going offline (which is the source of the bug). I'm in the process of finding a way to comply with the spec in terms of sending the message before going offline (and will do if that is a better option than changing the gaim plugin), but I thought I'd leave in the logic regarding the status of the other end anyway. I thought I'd bring it up in case someone can point out something I'm missing, or any problems with using the user's status change to offline to initiate the OTR state change to MSGSTATE_FINISHED. Scott ------=_Part_92308_17879270.1177825666237 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

Had the following bug report from a miranda user talking to a gaim user (thx Zeffel):

"Scenario:

Chat "blabla".
Miranda user goes offline.
Gaim OTR doesn't seem to notice this.
Gaim user sends Miranda user offline message.
When Miranda user goes back online, he receives: '[OTR Message] The encrypted message received from Gaim user is unreadable, as you are not currently communicating privately.'

So Gaim OTR still sends an encrypted message, though Miranda user went offline. Miranda user can't decrypt the message any more."

From the OTR protocol description:

"MSGSTATE_FINISHED
This state indicates that outgoing messages are not delivered at all. This state is entered only when the other party indicates he has terminated his side of the OTR conversation. For example, if Alice and Bob are having an OTR conversation, and Bob instructs his OTR client to end its private session with Alice (for example, by logging out), Alice will be notified of this, and her client will switch to MSGSTATE_FINISHED mode. This prevents Alice from accidentally sending a message to Bob in plaintext. (Consider what happens if Alice was in the middle of typing a private message to Bob when he suddenly logs out, just as Alice hits Enter.)"
My question is this: does the fact that Bob went offline not qualify as an indication that he has terminated his side of the OTR converstaion? Shouldn't the client call the 'otrl_force_finished' function in this situation, rather than requiring the reception of a termination message? It seems to me there are a few problems with the method if this is not the case, when compared to the alternative of ending sessions when either the client detects that the user on the other side has gone offline *or* it gets a session termination message:

1) the bug described above will still happen if the user is disconnected 'involantarily', e.g. due to network problems, or (heaven forbid) their client crashes, etc.
2) it doesn't seem to solve the problem described in the spec any better than the alternative
3) it can add unwanted delays when the user is attempting to switch status, e.g. when using a protocol with full message acknowledgement
4) protocol implementations may well discard pending messages when going offline, if their specification provides no guarantees of delivery
5) it causes problems with protocols that allow offline messages, such as ICQ and Jabber
6) it's problematic coping with system shutdown

The only benefit of using a termination message is that you can go offline and back online without renogotiating the session if you don't quit the client, as far as i can see. Obviously not worth it, imo.

Currently the miranda plugin is using the alternative method and does not send an OTR termination message when going offline (which is the source of the bug). I'm in the process of finding a way to comply with the spec in terms of sending the message before going offline (and will do if that is a better option than changing the gaim plugin), but I thought I'd leave in the logic regarding the status of the other end anyway. I thought I'd bring it up in case someone can point out something I'm missing, or any problems with using the user's status change to offline to initiate the OTR state change to MSGSTATE_FINISHED.

Scott
------=_Part_92308_17879270.1177825666237-- From ian@cypherpunks.ca Sun Apr 29 20:43:43 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 29 Apr 2007 15:43:43 -0400 Subject: [OTR-dev] session termination In-Reply-To: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> References: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> Message-ID: <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> One problem with dropping to FINISHED when you notice the other side goes offline is that that notification is unauthenticated. An adversary can trivially spoof a "Bob went offline" message, and it would be unfortunate if that caused Alice to forget her session keys. I also note that most IM networks, I'm pretty sure, don't tell Alice when Bob goes offline if Bob isn't Alice's buddy, but I don't know how often people chat with non-buddies in practice. - Ian From bfordham@socialistsushi.com Sun Apr 29 22:33:26 2007 From: bfordham@socialistsushi.com (Bryan L. Fordham) Date: Sun, 29 Apr 2007 17:33:26 -0400 Subject: [OTR-dev] session termination In-Reply-To: <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> References: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> Message-ID: <46350F26.2090001@socialistsushi.com> > I also note that most IM networks, I'm pretty sure, don't tell Alice > when Bob goes offline if Bob isn't Alice's buddy, but I don't know how > often people chat with non-buddies in practice. > Another scenario: my brother uses an IM service that allows him to appear offline. We chat all the time, but to me he's always offline. I'm not sure how you'd handle a situation like that. From marti@juffo.org Mon Apr 30 01:46:08 2007 From: marti@juffo.org (Marti Raudsepp) Date: Mon, 30 Apr 2007 03:46:08 +0300 Subject: [OTR-dev] session termination In-Reply-To: <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> References: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> Message-ID: <2a12af650704291746p5e27b5f5m5ed0928fe5c172ee@mail.gmail.com> On 4/29/07, Ian Goldberg wrote: > One problem with dropping to FINISHED when you notice the other side > goes offline is that that notification is unauthenticated. An adversary > can trivially spoof a "Bob went offline" message, and it would be > unfortunate if that caused Alice to forget her session keys. But does it really matter? When the attacker already has the capability of spoofing messages on behalf of the IM network, then surely they could also just disrupt (deny) communication between the parties -- which is effectively the same as far as I can tell. Marti From mail@scottellis.com.au Mon Apr 30 01:53:01 2007 From: mail@scottellis.com.au (Scott Ellis) Date: Mon, 30 Apr 2007 10:53:01 +1000 Subject: Fwd: [OTR-dev] session termination In-Reply-To: <96e269140704291638s2bb04186w2b8ba5279ed5a3f4@mail.gmail.com> References: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> <46350F26.2090001@socialistsushi.com> <96e269140704291638s2bb04186w2b8ba5279ed5a3f4@mail.gmail.com> Message-ID: <96e269140704291753j45da4caelaeba6b0cc8414639@mail.gmail.com> ------=_Part_99410_21827988.1177894381940 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It seems to me that the 'proper' way to handle this would be to do what a lot of protocols do, and have a periodic 'continue session' message, ending the session when nothing is received after a certain amount of time...? ------=_Part_99410_21827988.1177894381940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline It seems to me that the 'proper' way to handle this would be to do what a lot of protocols do, and have a periodic 'continue session' message, ending the session when nothing is received after a certain amount of time...? ------=_Part_99410_21827988.1177894381940-- From ian@cypherpunks.ca Mon Apr 30 02:24:47 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 29 Apr 2007 21:24:47 -0400 Subject: Fwd: [OTR-dev] session termination In-Reply-To: <96e269140704291753j45da4caelaeba6b0cc8414639@mail.gmail.com> References: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> <46350F26.2090001@socialistsushi.com> <96e269140704291638s2bb04186w2b8ba5279ed5a3f4@mail.gmail.com> <96e269140704291753j45da4caelaeba6b0cc8414639@mail.gmail.com> Message-ID: <20070430012447.GL10564@yoink.cs.uwaterloo.ca> On Mon, Apr 30, 2007 at 10:53:01AM +1000, Scott Ellis wrote: > It seems to me that the 'proper' way to handle this would be to do what a > lot of protocols do, and have a periodic 'continue session' message, ending > the session when nothing is received after a certain amount of time...? OTR does in fact support such a "heartbeat" message, but for the most part, the underlying IM networks don't. For example, if you try to send a "heartbeat" message to someone who's just logged off AIM, the user will get an annoying popup error message (with gaim), which is Bad. - Ian From ian@cypherpunks.ca Mon Apr 30 02:26:22 2007 From: ian@cypherpunks.ca (Ian Goldberg) Date: Sun, 29 Apr 2007 21:26:22 -0400 Subject: [OTR-dev] session termination In-Reply-To: <2a12af650704291746p5e27b5f5m5ed0928fe5c172ee@mail.gmail.com> References: <96e269140704282247j28650c70tdbebc99d8fb49eba@mail.gmail.com> <20070429194343.GJ10564@yoink.cs.uwaterloo.ca> <2a12af650704291746p5e27b5f5m5ed0928fe5c172ee@mail.gmail.com> Message-ID: <20070430012622.GM10564@yoink.cs.uwaterloo.ca> On Mon, Apr 30, 2007 at 03:46:08AM +0300, Marti Raudsepp wrote: > On 4/29/07, Ian Goldberg wrote: > >One problem with dropping to FINISHED when you notice the other side > >goes offline is that that notification is unauthenticated. An adversary > >can trivially spoof a "Bob went offline" message, and it would be > >unfortunate if that caused Alice to forget her session keys. > > But does it really matter? When the attacker already has the > capability of spoofing messages on behalf of the IM network, then > surely they could also just disrupt (deny) communication between the > parties -- which is effectively the same as far as I can tell. Yes, an attacker can always cause a DoS by making the network stop working. But allowing him to easily force Alice to forget her session keys seems worse to me. - Ian