Musings from

Sun, 16 Feb 2014

In Support of Instant Messaging Communications Freedom

by on :

As recent news events have driven home time after time, secure communications is a difficult yet important aspect of modern life. What “secure” may mean differs from person to person and from topic to topic, but certainly the typical person is somewhat uncomfortable with the idea that anyone — and in particular, large corporations or the government — might be eavesdropping on their casual communications. There are exceptions, and there are people who believe that only criminals should have something to hide, but for the moment let's assume that some measure of secrecy in private communications is warranted and/or desirable. This post is a commentary on some of the technologies that make it possible (or difficult or impossible, in many cases) to achieve secure communications on an instant messaging (IM) network.

I'm going to play a little bit fast and loose with terminology to help keep it understandable, but I also want it to be accurate. In particular, when I say that communication is secure, I mean private, specifically. For the purposes of this post, that effectively means encrypted and using some sort of authentication protocol to ensure that it's encrypted to the right person. The details are out of scope. Please contact me if you notice any particular discrepancies or incorrect statements, either arising from loose terminology or other errors.

First, where I'm coming from: I believe that essentially all communications should be secured, and I believe that that security should be very strong. By “very strong,“ I mean that it should be effectively impossible for any third party to eavesdrop without the acquiescence of a party participating in the communication. I have a fair amount of history in computer communications. I am a long time developer on the Pidgin instant messaging client and related software. I am on the board of directors for Instant Messaging Freedom, Inc., a non-profit organization “whose goal is to support free instant messaging software.” Instant messaging is important to me as a communication technology filling the gap between real-time spoken communication and e-mail.

Types of IM security

There are a number of ways in which an IM conversation can be "secured", and not all of them have the same properties. First, there is using a secure connection, such as SSL or TLS between your computer and your IM service's computer. Second, there is end-to-end security, such as Off-the-Record Messaging (OTR). Then there are additional, more complicated options that we won't discuss — but they basically break down to a combination of one or the other of the above, or one of the above with a different remote endpoint. (\textit{E.g.,} end-to-end security between you and a remote user's IM server to query her current status.)

Secure IM connections

A secure connection to the server protects your connection from eavesdropping on the local network and the path between you and your IM service (provided that it's done correctly), but it does not protect your conversation from the IM service itself and it does not tell you anything about whether the user you're chatting with is using a secure connection. Despite these weaknesses, a secure connection to the server is critically important, because it protects a large amount of private information. Things like buddy lists, status updates (online, offline, away, etc.) from your buddies, and your own status updates pass through this connection and are not necessarily targeted to any specific other user, which makes end-to-end encryption difficult.

This is the limit of security offered by most commercial IM services. There are a few exceptions, like AIM's encrypted IM, but often they have a similar effective security model — for example, the only proof that the encrypted channel you're talking on is actually terminated at the remote user (and not the IM service's servers) is a certificate signed by ... the IM service itself. (The details of why this is not sufficient are outside the scope of this post. Maybe I'll write some more on that later.)

End-to-end security

End-to-end security protects your communication from eavesdropping all the way to the other user. If some person or organization wants to read your messages, they have to do so at your computer or your interlocutor's computer. There are a small number of protocols that support this directly, but mostly not in a particularly useful way (see the discussion of AIM encrypted IM above).[1]

The usual solution for end-to-end encryption is a third-party protocol carried on top of the IM session. There are several such protocols, but by far the most popular is the previously-mentioned Off-the-Record. OTR provides end-to-end encryption for two-party conversations with authentication of the remote user and a variety of desirable encryption protocol characteristics. (It also provides repudiability for situations where that may be important.)

What end-to-end security cannot provide is protection for all of the stuff that's intended for a very broad audience.[2] Such data (things like away messages, online status, and buddy lists) is typically [3] handled by the service's servers on behalf of its users, in such a way that necessitates more-or-less trusting the servers with the information. (This is a reason not to put sensitive information in your status message!)

Secure connections with end-to-end security

Given the individual limitations of these two forms of data security, we arrive at the inescapable conclusion that, for instant messaging services, they are complementary rather than redundant or simply unrelated. Secure connections to the servers provide best-effort protection for group chats, administrative information, and metadata, while end-to-end security provides strong protection for conversation content.

The pros and cons of federation

Traditional IM networks are monolithic, walled gardens — if you want to chat with a user on the network, you get an account with the single service provider for that network. There have been limited exceptions to this over the years (e.g., MSN Live Messenger and Yahoo! Messenger offer(ed) some degree of interoperability), but for the most part, not only have networks been incompatible, there have been sole providers within those networks.

This kind of structure means that, while your metadata and administrative information are only ever managed by a single entity (the monolithic service provider), that service provider also sees all of the related metadata etc., and it's necessary some giant faceless corporation. That corporation stores your buddy lists, knows when you talk with whom, knows when you're away or idle, and all kinds of other behavioral information. Moreover, it has you in a lock — if you want to talk to your buddies, you have to use its services.

The alternative to the monolithic single-provider network is a federated service. In a federated service, multiple (possibly unrelated) service providers cooperate in a network tied together by a common protocol, allowing users of different service providers to interact with each other without worrying about whose service is provided by whom.

In a federated structure, you still have to trust your service provider with all of your metadata and administrative information, but you don't necessarily have to trust any of the other service providers in the network. In fact, in the general case, most of them don't even know you exist! Some portion of your data will necessarily be shared with the servers your friends and interlocutors are associated with, but you can scope that sharing to a greater or lesser degree. On the other side of the coin, you also have to place at least a small amount of trust in third-party providers with whom you have no specific relationship, if you want to talk to people on those providers' servers.

The quintessential federated network is XMPP, previously known as Jabber. XMPP is a widely federated network, wherein anyone can run an IM server and become a service provider for other users. Conversations between users work a lot like email; if I want to chat with you, I send a message to my server, it forwards it to your server, which forwards it to you. The return path is the same in reverse. Not only can anyone put up an XMPP server, but the protocol is entirely open and well-documented, so there are literally dozens of server software implementations and thousands of providers already in the network. Those providers range from large, commercial entities (such as Google's Google Talk, now known as Hangouts) to tiny servers serving just one user.

The huge benefit of federation is the freedom to choose your service provider. Moreover, to change that service provider. With an open federated network like XMPP, you can even be your own service provider if you so desire. That's a kind of communications freedom that no monolithic provider can ever provide, by definition.

It is my opinion that the federated structure is a superior solution, security, privacy, and freedom-wise, to old-style monolithic IM networks. The majority of your sensitive data (administrative information, complete buddy list, etc.) is kept and managed by only one entity, and is parceled out to third-party entities only as required to provide the services you specifically request. In the specific case of a closed group of users (such as a corporate or organizational server), it may be contained entirely. I am also a strong advocate of open standards which federated solutions tend to require (to make federation possible), and which XMPP certainly provides. The ability to pick up your data and move it to another service provider with limited (or nonexistent) loss of functionality is an extremely powerful argument for the freedom of a federated solution.

Today's best practices

The foregoing basically points to a simple best practices recommendation for IM freedom and security: use XMPP, find a server you trust, ensure that you're using TLS encryption, and employ an end-to-end security solution like OTR when it matters. (Unfortunately, without complete penetration of end-to-end security solutions, “when it matters” is the best we can do. Even then it can be hard to achieve!) Today, with the availability of a number of large XMPP service providers with federation and open registration (Google, DuckDuckGo,, or dozens of others), as well as many fine XMPP clients (including, of course Pidgin, finch, and Adium), getting an XMPP account and finding your friends is relatively painless. Many of them will already be available if you simply add gmail address as a buddy in your XMPP client.

Secure connections are not yet provided by all XMPP servers. Among servers that do provide secure connections to clients, not all provide secure connections to other servers. (If you recall the email-like communication model of XMPP, this means that your communicatiosn with users on other servers would not be secured between servers, even assuming you trust both servers.) The excellent directory of public XMPP servers provides ratings for client-to-server and server-to-server communications security; look for A-rated servers. If you set up your own server, also provides a security validator that can be used to ensure your personal server is up to snuff.

Improving the situation

Going forward, there are a number of efforts underway to further improve the already rather good connection security situation in the XMPP network. Notably, the XMPP manifesto is (documentation of) an effort to transition the entire federated XMPP network to secured connections by May 19, 2014.

The end-to-end security situation is still a little underdeveloped, in my opinion. OTR is great, but its protocol-independent nature leaves it with a level of integration that isn't as complete as it could be. I have some early-draft notes on desirable features for a new XMPP end-to-end encryption protocol, but a lot of work remains to be done on the topic — and much of it by people with stronger crypto chops than I have.

What you can do now

The takeaway from all of this? Ditch your AIM, MSN Live Messenger, Yahoo! Messenger, or whatever other IM services you're currently using, and get on board with a federated XMPP provider. Follow the recommendations in best practices, above. Use a public server or install your own, but do it sooner rather than later. Make sure you're using TLS (or SSL, if you have to) to protect your connections, and consider installing OTR.

Then, when you're done with that, start bringing your friends over. Talk to them about the benefits of freedom in IM services, describe the insecurity of communication on traditional commercial IM services, simply tell them you're not dealing with a closed IM service any more, or whatever. Point them at this article, if you think it will help. XMPP already has critical mass, it's simply a matter of expanding the borders.

If you have the necessary background, consider contacting me about working on an integrated end-to-end encryption and authentication solution for XMPP. Join the XMPP MUC and indicate your interest.


[1] SILC is an example of a service that provides native secure connections and native end-to-end encryption. Unfortunately, it is no longer a maintained codebase, it is not well-supported by IM clients (though libpurple, and thus Pidgin does support it), and it has a problematic federation model.

[2] “Cannot“ is a bit strong here, but I believe that, given the current state of the art of encryption protocols and mechanisms, it's true enough to use for the moment. Secure multiparty broadcasts with hundreds of recipients would be very expensive using standard techniques. The literature may (and probably will) have some answers to this problem in the future, but for now, I'll say cannot.

[3] I say typically here because I know of no non-local-network service that handles this any other way. Local network messaging (like Apple's Bonjour) has other solutions to this problem. Generally, however, you send your status updates to the server and it distributes them (possibly by way of other servers, in a federated protocol) to interested parties on your behalf.

tags: encryption, freedom, im, pidgin, xmpp
path: / | permalink | Comments

[ | | ]