I'm probably jumping the gun somewhat given this week's giveaway here, but I thought I'd ask this as soon as it occurred to me. My current employer works on a military base, and as part of our security requirements, we're not allowed to run instant messaging clients due to the insecurity in communicating through an off-site server. This complicates things oftentimes, since the members of the project that we're working on (from several contractors and the government) are spread out across several buildings. I did start writing a Jabber client at my former employer, but we didn't need to have it secure. Is there a way to build a secure (SSL or other encryption) Jabber-protocol client/server application that would allow us to host our own messaging service on-base, in such a way that it would pass muster? (I do realize that we could implement our own central server - just need to know if SSL would be implementable with it.) Thanks!
Theodore Jonathan Casser
SCJP/SCSNI/SCBCD/SCWCD/SCDJWS/SCMAD/SCEA/MCTS/MCPD... and so many more letters than you can shake a stick at!
Hi, Security and Jabber is a hot topic these days. Jabber was initially intended for consumer IM where only the most basic security was needed. So I'd rate Jabber as it stands today as having a very low level of security. The Jabber protocols do currently define a standard port for connecting via SSL to a Jabber server that supports SSL (the open reference implementation jabberd hosted at www.jabber.org supports SSL). This secures the underlying transport for client-server communication. However, standard Jabber authentication (how the client proves its acting on behalf of a user) uses "homebrew" authentication protocols that have not been rigorously review for security and would not pass most military/business/government requirements. There are currently standardization efforts underway within the Jabber community to change basic client-server security to SASL. SASL is an IETF standard that allows implementors to plug in standard security providers for both authentication and transport level security. So a SASL server could tell attaching clients that it only allows connections using SSL as a transport layer, and kerberos authentication. SASL is quickly becoming a standard authentication front end to many internet services (secure HTTP, SMTP, etc) so this move will let Jabber interoperate with existing security systems. Unfortunately, client-server security is only half the battle. Next, regardless of transport security Jabber messages are exposed as plain text to the server. So clients must trust the server to be secure. This may or may not be an issue depending on your needs. The common "gotcha" with this setup is when you wish to transport confidential information over insecure servers, or when you cannot trust all intermediate servers. In this case, you should use standard encryption to secure the message payloads. Since Jabber employs XML, XML based standards for encryption, signatures, can be used (see www.w3c.org). Jabber standardization work is also underway to establish Jabber bindings to these w3c standards most likely as part of a Jabber-SOAP effort. note that you will not be able to disguise the routing information of message packets. The Jabber servers must be able to read this information to deliver the packets. if you must disguise the source and destination of messages, you'll have to work around the Jabber systems itself. In many cases, you can use Jabber IM to coordinate communication, but conduct actual secure message passing directly between clients. The Jabber out-of-band protocols can be especially useful for this. As a shameless promotion, my book covers these issues in greater depth and discusses them in the context of Jabber Instant Messaging in Java. If you want to see what's going on with Jabber security standardization efforts you should read the archives for the jabber standards mailing list (see www.jabber.org). Even better subscribe and participate! Jabber security is really an open issue right now and I'd be very interested in hearing from anyone that has already created work arounds. Hmm... Sorry about the round about answer. Since Jabber is open, I guess the basic answer is that it is possible to create a secure Jabber system. However there is no standard way of doing it. So anything that exists today uses a non-standard extension to Jabber in order to accomplish it. Jabber is designed to be easily extensible and I would imagine that there are already Jabber implementations that do have various additional security layers in place. Thoughts? -iain
Cool. I'd be interested in hearing what the outcome of that conversation is. There are many small 3rd party vendors stepping in to plug these security holes in proprietary products so it may be worthwhile to check them out. Even the big players like AOL are starting to offer enterprise services with more secure IM. New players like Sprint are also getting into offering enterprise IM services with a variety of security options. I prefer open technologies but I also like to buy a solution rather than build it myself. laziness rules. -iain