[messaging] Secure messaging over insecure chat frameworks

George Kadianakis desnacked at riseup.net
Tue Feb 11 14:01:19 PST 2014

While thinking of secure overlay (on top of IRC/XMPP/etc.) messaging
protocols, I started pondering the security implications that the
underlying chat frameworks have on them.

For example, when we think of a secure multiparty messaging protocol
over IRC, we usually think of using IRC channels to transfer messages
between chat participants. This has a few engineering and security

* The server learns the participants of each channel.  Depending on
  the messaging protocol the server might also learn the public key of
  each participant, or other info.

* The server learns various metadata about the participants: typing
  speed, volume of chat, WHOIS, CTCP actions, etc.

* Users are vulnerable to information leaking on the chat framework
  layer. For example, using the ridiculous CTCP TIME command in IRC
  that leaks your timestamp to other parties.

* Any user of the IRC server can attempt to /join the "secure"
  channel. You can block this by password-protecting the channel, or
  making it invite-only.

  Each messaging framework has different ways of blocking unexpected
  joins: IRC has the +k channel mode, XMPP MUCs have the <password>
  field in the presence stanza. Of course in both cases, the server
  knows the password of the channel.

  Secure messaging protocols will probably need to implement these
  modes for all the chat frameworks they support, since if the
  channels are not locked any user can join the room; and even if they
  can't read the messages (because of end-to-end security), they can
  still gather metadata on what is being said.

  I can imagine protocols that use private messages instead of
  channels, but that will probably not work very nicely with protocols
  that use broadcast primitives (might work OK for pairwise ones

* Any user of IRC can see the channels of other users by doing a
  WHOIS. Messaging protocols can block this by setting the channel
  mode to +s.

Of course, many of the above points are inherent weakenesses of
server-based protocols and can only be solved with decentralized P2P
chat frameworks specifically designed for secure messaging. I don't
know of any such protocols that have been deployed in the real world;
PSYC from the secushare people might be promising (http://psyc.eu)

Anyway, these are just some captain-obvious thoughts I had generated
and thought about archiving them somewhere.


More information about the Messaging mailing list