[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
implications:
* 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
though).
* 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.
peace!
More information about the Messaging
mailing list