Part 1 of our XMPP Mini-Series listed the 7 Advantages of XMPP and Part 2 focused on How Google Wave Uses XMPP. This third and final part of our mini-series will talk about XMPP Security.
Server-to-server (s2s) connections (which is how XMPP is used in Google Wave) basically follows this pattern: after opening a connection to the host serving XMPP, the sending server needs to authenticate itself before it is allowed to send a message. Without authentication, any server would be able to pretend that it is responsible for a given domain, and could send messages in the name of any user in that domain (this is called domain spoofing).
Servers also use Simple Authentication and Security Layer (SASL) (RFC 4422) to authenticate themselves. The SASL mechanisms most commonly used by clients require the user to register in some way with the server and then reference the registered credentials when authenticating. This is impractical for server-to-server connections because XMPP promotes a distributed network where servers don’t need to have prior knowledge about each other (this dynamic federation model is similar to email but different from the formal “peering” model public telecommunication networks use).
You might therefore think that SASL cannot be used for inter-domain federation. However, one SASL mechanism comes in handy here: the EXTERNAL mechanism. For server-to-server connections, SASL EXTERNAL is used in conjunction with Transport Layer Security. During the TLS negotiation, the servers exchange certificates in both directions. After the negotiation completes, the servers can then simply refer to the certificates provided via TLS for mutual authentication.
Thus, all users are authenticated. Moreover, the sender addresses are not merely asserted, the server actually stamps the user’s “from” address. This address is their Wave Address and not their IP address, so the IP does not get exposed. Then the server stores your User name in his “list of users” and broadcasts your presence, but only to subscribers you have authored. Since all traffic goes through the server, the server excepts only true XML and rejects any malformed XML. Servers can validate traffic against schemas making it very difficult to inject binary objects or propagate malware.
For this reason spam is kept in check on a XMPP network. Mainly because it is very hard to spoof addressees and send inline binary. User approval is required for file transfer and the user can block unwanted users. On a proactive network these addresses, once reported, can quickly become black-listed.
But users beware and be smart. This whole system is based on the fact that you must accept somebody onto your secure island. If you don’t let them in, it is very difficult to get in.
Until Google Wave, using the SASL EXTERNAL was not widely used. Couple this together with Operational Transforms and you have an extremely ingenious architecture!
Thus ends our small mini-series on XMPP. We hope you found this benficial and are curious to learn more.
Of note: references used were:
O’Reilly: XMPP The Definitive Guide
Google Wave Federation Protocol
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
Why I am using the Thesis Wordpress Theme
Thesis makes my site look very professional, clean and has an easy-to-read layout. Thesis delivers unmatched SEO, cross-browser compatibility, and top-notch HTML + CSS architecture. Visit this site to find out more and get the Thesis Theme for WordPress Get your Thesis Theme today!
Why I host my blog with DreamHost
DreamHost gives me unlimited Disk Storage, unlimited monthly bandwidth, unlimited domain hosting, MySQL 5, PHP5, Subversion Repository, SSL Security server, 24/7 Technical support, One-click installs (Wordpress, Gallery, ZenCart, PHPGedView, Pigg, dotProject, Moodle, Joomla, phpBB, MediaWiki, WebCalendar, Advanced Poll and Trac) and much, much more. Visit DreamHost today!.
