One of the most troubling aspects of using legacy instant messaging services is their lack of dedication to security, specifically encryption. XMPP plugs this hole beautifully and even has plans on extending the specification, but I’ll get into all of that in a minute.
Encryption is one of my most passionate topics. I’ve blogged about it several times, and I’ve given encryption-related presentations many times over. I don’t consider myself an expert, but I do feel that I have a good grasp since being introduced to it in 2001 when generating my GnuPG key. Because encryption is such a part of my everyday life, it’s important to me to use a protocol that takes advantage of it natively. That is yet another reason why I chose Jabber and the XMPP spec. Let’s look at it in more detail, and paint a scary picture while we’re at it.
First, the scary picture. Imagine that you’re at work just plugging along getting the things done that you need to get done. At work, you have to use ICQ to keep in contact with other coworkers and even clients outside. During the day, you bang heads with one of your coworkers. You don’t agree with how she is executing a project, and she’s just as upset with your style of execution. Now, both of you are fuming at each other. This coworker you’ve never really gotten along with, and she has some friends who back her up no matter what. Knowing that ICQ messages are transferred over the wire in plain text, you pull up Wire Shark, and sniff out all the ICQ packets watching what she is saying about you to her friends. Yes, you can see everything in clear text after cleaning the TCP dump.
Now, I don’t condone sniffing out packets on the corporate wire. Talk about getting fired if you get caught (unless you are IT staff yourself). But, the lesson needs to be taught. Using conventional packet sniffing tools, you can sniff out usernames, passwords and the entire conversation on IM protocols that are not using encryption. This includes MSN, AIM, ICQ, Yahoo! and most others. Talk about a security hole. Anything that is not encrypted on the wire, in my book, is a security hole. So, using IM protocols that do not encrypt their traffic, is just asking for trouble.
This is where Jabber steps in. When the Jabber protocol was first introduced, SSL was a top priority. Every account that connects to a Jabber server should be connecting via an encrypted stream. Initially, as mentioned, SSL was the default encryption method. Now, with the introduction of TLS, Jabber now supports TLS as the default. Some Jabber servers run both SSL and TLS for maximum backwards compatibility. In either case, you can be rest assured that your traffic is 100% encrypted between you and the server. This means no amount of energy put into Wire Shark or other packet sniffing tools are going to be an effective means of getting the message text or account info.
Unfortunately, all the encryption and decryption happens in two instances- at the client and at the server. This means that both the computer your Jabber client is installed on and the server that you have an account with could hold logs in plain text of your conversations. To illustrate an example, if you use Gmail for your Jabber IM, there is a “Chats” link in the Gmail interface. By default, Gmail logs all of your chats, and stores them in your Gmail account (you can turn this off, by the way). They are stored in plain text after the server has decrypted the messages. To me, and luckily the core XMPP team, this is troubling. Why can’t we have a client-to-client encryption method, rather than just client-to-server and server-to-server encryption (yes, server-to-server communication is also encrypted on the wire)? That’s the exact question that is being asked, and hopefully in a future release of the XMPP core spec, this will be a reality. However, at least you’re encrypted on the wire, and a bothered employee can’t sniff your packets seeing what you are saying about him to your friends.
The XMPP specification on encrypting data is just scratching the surface. Many clients include 3rd party plugins or tools to make client-to-client encryption a reality, regardless of protocol. I have also blogged about this before, hoping for some sort of standard in this arena. However, even these tools are just encrypting message text, leaving the IP in the packet exposed. Imagine encrypting the entire packet from top to bottom, leaving no rock unturned. Again, this is being worked on with the core XMPP team.
Because Jabber is decentralized, as mentioned in my previous XMPP article, installing Jabber in a local intranet is another way to achieve security. Not only encrypting packets, but isolating your packets is another level of security that most don’t think about. Using legacy providers means that you need to rely on two things for IM to be successful: your Internet needs to be up and running, and the IM service needs to be up an running. Utilizing an intranet installation means you don’t need to rely on others to have a working IM session. You are in control, and to me, this is a level of security that you just can’t get any other way. Why send packets out to the Internet when they’re coming right back into your network? Jabber makes this possible.
Hopefully, this is the straw that breaks the camel’s back when it comes to convincing anyone to move to Jabber and ditch their proprietary accounts. Security just makes sense, and why other services haven’t utilized it is beyond me. Coupled with 3rd party plugins and corporate installs, you can make your Jabber service pretty tight security-wise. And, to put the icing on the cake, with the XMPP team working on tightening that security further, Jabber should be the only IM you or anyone else uses. It just puts things into perspective, no?