While the XSF may not be mentoring a project in this years Google’s Summer of Code 2014 - we sure can celebrate and shout about the fact that some of the projects include XMPP as part of their project ideas!
The Jitsi project has several projects relating to WebRTC, XMPP and the Jitsi Videobridge.
XMPP/Jingle/WebRTC also plays a role in Mozilla’s project ideas for InstantBird.
To name just a few…
We are really looking forward to seeing many of these exciting projects get implemented by students around the world!
Another update to Pontarius XMPP, a client XMPP library for Haskell, has now been released, courtesy of Philonous.
In addition to a bunch of general improvements and bugfixes, this new version supports plugins (the possibility to transform incoming and outgoing stanzas) and lenses (allowing users to access XMPP-related types more conveniently and composably). Since one of the bugs fixed is quite major (Pontarius XMPP didn’t check the JID of IQResult stanzas), we recommend that all Pontarius XMPP users upgrade.
The Pontarius project will use this new plugin feature to build end-to-end security on top of Pontarius XMPP.
Stay tuned for further updates!
There has been a lot of buzz recently around Whatsapp acquisition by Facebook and the record price paid for the company. FastCompany’s Ainsley O’Connell wrote Inside Erlang, The Rare Programming Language Behind WhatsApp’s Success, giving some technical background around the story.
As the founder of leading instant messaging technology provider developed in Erlang, I want to had a few words on my perspective of this story.
I discovered Erlang in 1998 when it was release as Open Source and I was hooked. I was exploring the potential of the technology and how I could apply it to my internet project.
ICQ was a big thing at that time. Yahoo!, AOL, MSN were launching their own instant messaging service. Jeremy Miller started working in 1999 on an open and federated protocol for instant messaging called Jabber. I started getting interested in that protocol since the very beginning and got the chance with my company at that time to work on early commercial Jabber projects. At that time, the collision between Erlang and XMPP already happened as my company was working on an Erlang layer to turning Jabber first C server into a large scale cluster.
In 2002, I joined Alexey Shchepin that just started building an XMPP server fully in Erlang. We work together for all this years and when I felt the time had come, I founded ProcessOne in 2005. ProcessOne is an Erlang company selling technology and expertise to build large scale realtime messaging services.
We worked across the world with major brands to build messaging services in Erlang with ejabberd. We expanded during the passed years to all kind of messaging realtime application. We have a large scale Push notification service build in Erlang, that is sending billions of notifications. We have build the most used XMPP messaging server, the reference implementation that nearly everyone is using. And we are getting further, building even larger scale platforms for the Internet of Things.
During that time we have seen big companies and small companies embrace our vision. Facebook chat started from our vision: Why was Erlang chosen for use in Facebook chat?:
Facebook chat started out as a hackathon project in January 2007, by mid 2007 it became an official project with a dedicated team. Facebook engineers choose to use ejabberd since back in 2007 it was the only chat server which had clustering built in for free. As you can imagine at Facebook’s traffic every service needs to scale horizontally and ejabberd was solving an important problem for them.
Funny thing is that a couple of year laters in june 2009, Whatsapp team is building its own platform sharing the same vision. Here is a post of Jan Koum on ejabberd mailing list: client access control:
hi there, i installed ejabberd today, got it work with adium/ichat and wanted to ask you all a couple of things: …
I remember the call that followed with Brian Acton and Jan Koum, talking about our technology and our vision.
And here is the most interesting piece: when Facebook acquires Whatsapp, they also buy a technology that they know fits well with their existing messaging platform.
Finally, this is just two of the success stories our vision, expertise and technology helped sparkled. I would not be surprised that more such success stories arise in the coming months and years.
It all started with ejabberd and we are proud of it !
For us, this is business as usual and just the beginning of a great story.
Zurl is a gateway that converts between ZeroMQ messages and outbound HTTP requests or WebSocket connections. It gives you powerful access to these protocols from within a message-oriented architecture. The following diagram shows how Zurl may fit in among the entities involved:
Any number of workers can contact any number of HTTP or WebSocket servers, and Zurl will perform conversions to/from ZeroMQ messages as necessary. It uses libcurl under the hood.
The format of the messages exchanged between workers and Zurl is described by the ZHTTP protocol. ZHTTP is an abstraction of HTTP using JSON-formatted or TNetString-formatted messages. The protocol makes it easy to work with HTTP at a high level, without needing to worry about details such as persistent connections or chunking. Zurl takes care of those things for you when gatewaying to the servers.
This Saturday (February 22, 2014), XMPP site operators are again flipping the “encrypt all traffic” switch.
This is the second of four test days kicked off by the manifesto first published last fall. The aim is to encrypt all traffic between servers and clients on the public, federated XMPP network.
You can take part, too: ensure you have valid certificates on your server and that encryption is properly set up (see http://wiki.xmpp.org/web/Securing_XMPP along with the documentation for your XMPP server software), then test your configuration using the tools at the IM Observatory running at XMPP.net.
The manifesto team has managed to push the encryption level up to 12.5% of XMPP server-to-server traffic (see https://xmpp.net/reports.php#starttls). The test days help to keep nudging this value up and to prepare for an “everything is encrypted…or else” day in May of this year (some operators have not flipped back to unencrypted traffic and are now running 100% encrypted servers).
To join the team running the manifesto and thus help to secure the communications of XMPP users everywhere:
It’s that easy!
jp ad-hoc remote -g flatmates -- amarok
once the command entered, SàT fill look in D-Bus's Session bus to find buses which have "vlc" in their names, and add commands which don't need arguments. The output show what has been found.
Now, let's see how we can use the remote in Libervia (web interface of SàT):
As usual, to watch the video you can use a recent browser (the last Firefox/Iceweasel for example).
You can also use VLC (version >=1.1 only), by using the "Media/Open Netword Stream" menu and by entering this URL: http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_7_t%c3%a9l%c3%a9commande_universelle.webm
Last but not least, you can use mplayer:: mplayer "http://www.goffi.org/videos/pr%c3%a9sentation_S%c3%a0T_7_t%c3%a9l%c3%a9commande_universelle.webm"
this video is licenced under Creative Common BY-SA
In the past couple of years, a number of attacks have been found on “TLS”, but often those attacks were only shown with HTTPS. The majority of TLS encrypted traffic is probably HTTPS, but it’s important to understand which of these attacks can be translated to other protocols. I’ll use XMPP, but I’ll try to get the attacks down to the core features the used protocol needs to support to help others determine which other protocols are also vulnerable.
I shall mostly assume that the attacker knows your full JID and is therefore capable of routing stanzas to you. This may not always be realistic, but targeted attacks do happen.
First of all, there needs to be something that is going to be extracted. Something secret that was transmitted which the attacker wants to obtain. For HTTPS, this is often cookies: they are transmitted often, an attacker can cause them to be retransmitted whenever they want, and they (often) give full access to your account. Other attacks attempt to extract data from the body of a page, like email addresses.
On XMPP, possible targets include:
BEAST exploits a problem with CBC mode in TLS which leads to predictable IVs. CBC mode is a block cipher mode that xors a plain text block with the previous cipher text block before encrypting it, to ensure equal plain text blocks do not turn into the same cipher text blocks. However, TLS 1.0 also does this when that block has already been transmitted. This means the attacker can observe that block and pick the next block to be encrypted based on that information.
In other words, suppose
P[i] are the plain text blocks the client sends and
C[i] are the cipher text blocks. Then
C[i] := AES(P[i] XOR C[i-1]). Suppose
C[a] was the last block of a packet. Then, if the server could somehow convince the client to send
P[a+1] = C[a] XOR Q, then the encrypted packet will be
C[a] = AES(P[a+1] XOR C[a]) = AES(C[a] XOR Q XOR C[a]). If you recall the properties of
XOR, this is equal to
AES(Q). So the attacker can obtain the encryption of any block
This is what’s known as an encryption oracle. The attacker can pick any value
Q and obtain its encryption, but it can not decrypt anything. But by making clever guesses, the attacker might be able to obtain the decryption of specific blocks, if they guessed correctly. Suppose the attacker is interested in the contents of the
bth block, then the attacker must make a guess of what that block was, lets call its guess
B, and it will make the client send
B XOR C[b-1] (to account for the CBC mode). If
AES(B XOR C[b-1]) was equal to
C[b], then the attacker knows their guess was correct and that
P[b] = B. If the guess was wrong, the attacker will have to try a different value instead of
B and continue until the encryption is equal.
Now, guessing even a 10 character cookie or password correctly is going to take a long time, so BEAST uses another trick: it will insert content before the cookie to make sure the first character of the cookie falls in one block, but the rest of the cookie in the next. If the attacker does know the rest of the block, it only needs to guess one character, which can be done quite quickly. For the next connection, the attacker will insert one character less, so two characters of the cookie fall in the first block. It already knows the first one of the two, so it again needs to guess only one character. It can continue this until it has the entire cookie. This means the attacker is able to guess a long cookie in quite a low number of guesses.
Attacking the password on XMPP is much harder, as the attacker can not insert new content before the password. It is quite likely the password spans different blocks, but that still leaves a large number of possibilities. The contact list is likely also too hard to guess without any prior information. Guessing the JID might be possible if the attacker has a list of all users on the server, but if the attacker didn’t know the JID, it would be much harder for them to actually do this attack.
Guessing messages is also hard, but obtaining message meta-data might be possible.
Suppose the attacker already has a list of contacts who are on my contact list. I send a packet and the attacker is interested in finding out whether it was a message to one of my contacts, and if so, to whom. Here’s the plain text of the message, shown split at the block boundraries:
1: <message type='c 2: hat' id='purplea 3: 1074a2d' to='jul 4: firstname.lastname@example.org 5: om'><active xmln 6: s='http://jabber 7: .org/protocol/ch ...
The interesting info is spread over blocks 3, 4 and 5. However, block 3 also contains part of
purplea1074a2d. We can guess this (hint: it’s an incrementing counter), but lets suppose we don’t know it, just its length. The attacker can use BEAST to test every person on my contact list to the 4th block, leaving out the first 3 characters and using at most 16 characters of every JID. It might fail (the attacker doesn’t know for sure it’s a message, it could be an
<iq/> stanza or groupchat message), but if the message is for one of my contacts, the attacker will find that.
There is, however, one more requirement on BEAST that we need to satisfy: the attacker must be able to fully specify the first block in a new packet. It won’t work if it’s a later block. In general, the client will only start new packet with a new stanza. So the packet will almost always start with
<presence, and anything the client sends must be valid UTF-8 and valid XML. Therefore, making the client send
B XOR C[b-1] exactly is very hard.
One way the attacker might try to get the client to use certain contents in its first block is by sending the target an
<id/> with the payload in the ‘id’ attribute:
1: <iq id='�u��_$ճH 2: ' type='get' to= ...
The client will then mirror the ‘id’ and send a reply or error back:
1: <iq id='�u��_$ճH 2: ' type='error' t ...
But because of the prefix, the attack can only be successfull when
B XOR C[b-1] happens to start with
<iq id='. The probabilty of that happening is 2-64, which is neglible.
The main requirement for BEAST is that the attacker must be able to choose the block a client will use as the start of a new packet. Additionally, the secret needs to be either easy to guess or it needs to be movable by the attacker so it can be placed on a block boundrary. I do not know of a way to do the former in XMPP, so it is unlikely XMPP is vulnerable.
Finally Tigase XMPP Server 5.2.0, dubbed FTL - Faster Than Light, has landed in it's destination (that is our servers) and it's available for download. As always - binaries are available for download in the files section on the project tracking system. Sources are available in our code repository under the tag tigase-server-5.2.0 - tags/tigase-server-5.2.0. Maven artifacts have been deployed to our maven repository. To put a cherry on top we also run automated tests - successful results are available in our test page.
It could be expected that this version is not only blazing fast but is also packed with features - to recapitulate what has already been mentioned regarding 5.2.0 in previous posts (Tigase XMPP Server 5.2.0 RC2, Tigase XMPP Server 5.2.0 RC1, Tigase XMPP Server 5.2.0 Beta3, Tigase XMPP Server 5.2.0 Beta2, Tigase XMPP Server 5.2.0 - FTL - Beta1):
Major additions to the Tigase XMPP Server in this release:
Other changes which have been made in this release:
On December 20th 2013 the XSF received some very exciting news, to end what had already been a great year – ISOC were awarding the XMPP community an incredibly generous gift to help support the work we are doing in improving privacy and security.
In their own words:
“The Internet Society takes a great interest in projects that will improve our existing mechanisms for on-line privacy and trust and we appreciate the XMPP Standards Foundations leadership in securing XMPP services in the wake of recent events. We know that the XMPP community is working to ensure ubiquitous TLS encryption on the public XMPP network, use DNSSEC and DANE in XMPP, more widely implement the Off-the-Record (OTR) protocol, and support both key pinning and certificate transparency.”
The XSF has already thanked them directly, but we wanted to share the great news with our wider community.
We are confident that 2014 is going to be a great year, and we look forward to sharing what this gift has enabled our community to do.
Here’s to 2014!
We will be upgrading our servers in the coming weeks. There will be some down time this weekend, February 15th-16th. There may be shorter interruptions following that as we tie things together.
Please bear with us and thank you for your continued support!
We have fixed a few bugs and a some minor issues, so it's time for another release!
A summary of changes in this release:
Download instructions for many platforms can be found on our download page
If you have any questions, comments or other issues with this release, let us know!
Hi there, I'm Smack's new maintainer. Some of you may know me already as the maintainer of aSmack, the Android port of Smack. I first like to thank Robin for his work on Smack in the past.
Smack has a long development history. The first recorded commit dates back to Jan 13 2003. Now, over 11 years later, we are going make fundamental changes to Smack in order to ensure that it will last another decade.
Most importantly: Ignite Realtime is applying as Google Summer of Code organization. We propose a project to modernize and modularize Smacks build system. One reason why this is necessary, is that we want Smack to be able to target Java SE and Android. Read more about it here.
Smacks SVN repository has been migrated to git, and the code is now hosted on GitHub. We are currently evaluating hosting the code in our own Atlassian Stash, but that isn't decided yet and is not a high priority right now.
Let's have a look at Smack's contributors of the last 11 years:
513 Gaston Dombiak
474 Matt Tucker
105 Thiago Camargo
104 Florian Schmaus
69 Alex Wenckus
46 Bill Lynch
43 Derek DeMoro
24 Günther Niess
15 Daniel Henninger
12 Henning Staib
7 Michael Will
7 Wolf Posdorfer
6 Holger Bergunde
6 Jeff Williams
5 Jay Kline
4 Marilyn Daum
3 Francisco Vives
1 (no author)
1 Andrew Wright
1 Pete Matern
1 Tim Jentz
Hopefully this list will grow over the time. If you'd like to contribute bigger patches to Smack, please consult the developers. Either via IRC #smack (freenode) or via the developers forum. All patches will be reviewed, since there are usually a few things that should be improved before the commit is ready for Smack's master branch. Make also sure to read the Guidelines for Smack Developers and Contributors.
Besides the GSOC project, there are more goodies in the queue, like XEP-0198 Stream Mangament and Roster Versioning.
We also work on migrating the build system to gradle, including deployments to sonatype/maven central. I expect the next release to be available as jar and via maven central.
Finally, shortly after the 3.4.0 release, a memory leak was reported in the forum. The cause was , and a fixed nighlty release was made availabe shortly after. I am going to use this importand fix as reason to release Smack 3.4.1 today, in order to get familar with the release process of Smack.
A couple of years ago I wrote the buddycloud channel directory as my GSoC’12 project and as my first buddycloud project to go live in production.
The component is running fine in search.buddycloud.org, however the crawler wasn’t crawling as we required. The crawler was designed on top of XEP-0060, and uses smack with its pub-sub extensions to discover Buddycloud channels and items on the Buddycloud channel server.
But then comes a day when you get the guts to look at old code. Reason: the crawler was dumb dumb. It crawled every single item of every single node every time it ran. Stupid, eh? But there’s more: by using smack’s XEP-0060 implementation, the crawler missed an important feature that the Buddycloud XEP specifies - XEP-0059, a.k.a. RSM.
The Buddycloud XEP uses RSM in several occasions, eg.: disco#items and pubsub <items>.
<iq type=’result’ from=’channelserver.example.com’ to=’email@example.com/KillerApp’ id=’items1’>
<entry xmlns=”http://www.w3.org/2005/Atom” xmlns:thr=”http://purl.org/syndication/thread/1.0”>
<content type=”text”>A comment, wondering what all this testing does</content>
<!— [more items…] —>
Thus, we needed to somehow integrate RSM on smack to get the crawler properly working, so that it could page through all results that the channel server provides and avoid looking into the past when not needed.
Finally, we achieved that by creating a class that works as a packet extension called RSMSet and by overriding some of the PubSub classes offered by smack, such as the PubSub class itself. Now, when we need to do RSM, we ask the PubSubManager for a new PubSub packet and then inject the RSMSet extension into it. As in:
DiscoverItems discoRequest = new DiscoverItems(); discoRequest.setTo(discoverInfo.getFrom()); RSMSet rsmSet = new RSMSet(); rsmSet.setAfter(discoverInfo.getRsmSet().getLast()); discoRequest.setRsmSet(rsmSet);
And then, we store the last item crawled in every node inside the directory’s database, so the crawler can be smarter about what to crawl.
Yesterday's release of Openfire 3.9.0 had some problems with packaging of the release. Bouncycastle signed jar files were getting packed, which then caused problems when Openfire attempted to load them. We have hopefully fixed this issue and cleaned up a few other details and are proud to announce a 3.9.1 release!
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
The download page offers these files and here are their md5sums for your comparison.
Please report any issues to us in the forums. We are always looking for developers to help improve Openfire, so please let us know if interested!
The Ignite Realtime community is happy to announce the release of version 3.9.0 of Openfire! Downloads for various platforms are available here.
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache license. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
There are a few important fixes with this release, be sure to checkout the changelog for more details.
As always, we welcome your feedback, suggestions, tips, hints, questions and other contributions in the Ignite Realtime Community pages.
We are also looking for people interested in helping to develop Openfire! If you enjoy hacking at Java code and would like to pitch in, please let us know on the forums.
Update 6 Feb 2014 20 UTC: There was a problem with the initial build of 3.9.0 and the packaging of the bouncycastle libraries. This has been fixed. The following MD5 checksums should be used to check the files you download.
In a post from 2009 I described why XEP-0198: Stream Management is very important for mobile XMPP clients and which client and server applications support it. I have updated the post over the years with links to bug tracker issues and release notes to keep track of the (still rather sad) state of affairs. Short summary:
Servers supporting XEP-0198 with stream resumption: Prosody IM.
Today, with the release of yaxim 0.8.7, the first mobile client actually supporting the specification is available! With yax.im there is also a public XMPP server (based on Prosody) specifically configured to easily integrate with yaxim.
Now is a good moment to recapitulate what we can get from this combination, and where the (mobile) XMPP community should be heading next.
Unfortunately, it is still not that easy. With XEP-0198, you can resume the previous session within some minutes after losing the TCP connection. While you are gone, the server will continue to display you as "online" to your contacts, because the session resumption is transparent to all parties.
However, if you have been gone for too long, it is better to inform your contacts about your absence by showing you as "offline". This is accomplished by destroying your session, making a later resumption impossible. It is a matter of server configuration how much time passes until that happens, and it is an important configuration trade-off. The longer you appear as "online" while actually being gone, the more frustration might accumulate in your buddy about your lack of reaction – on the other hand, if the session is terminated too early and your client reconnects right after that, all the state is gone!
Now what exactly happens to messages sent to you when the server destroys the session? In prosody, all messages pending since you disconnected are destroyed and error responses are sent back. This is perfectly legal as of XEP-0198, but a better solution would be to store them offline for later transmission.
However, offline storage is only useful if you are not connected with a different client at the same time. If you are, should the server redirect the messages to the other client? What if it already got them by means of carbon copies? How is your now-offline mobile client going to see that it missed something?
Even though XEP-0198 is a great step towards mobile messaging reliability, additional mechanisms need to be implemented to make XMPP really ready for mass-market usage (and users).
With XEP-0280: Message Carbons, all messages you send and receive on your desktop are automatically also copied to your mobile client, if it is online at that time. If you have a client like yaxim, that tries to stay online all the time and uses XEP-0198 to resume as fast as possible (on a typical 3G/WiFi change, this takes less than five seconds), you can have a completely synchronized message log on desktop and mobile.
However, if your smartphone is out of coverage for more than some minutes, the XEP-0198 session is destroyed, no message carbons are sent, and further messages are redirected to your desktop instead. When the mobile client finally reconnects, all it receives is suspicious silence.
XMPP was not designed for modern-day smartphone-based instant messaging. However, it is the best tool we have to counter the proprietary silo-based IM contenders like WhatsApp, Facebook Chat or Google Hangouts.
Therefore, we need to seek ways to provide the same (or a better) level of usability, without sacrificing the benefits of federation and open standards.
With XEP-0136: Message Archiving there is an arcane, properly over-engineered draft standard to allow a client to fetch collections of chat messages using a kind of version control system.
An easier, more modern approach is presented in
XEP-0313: Message Archive Management
(MAM). With MAM, it is much easier to synchronize the message log between a
client and a server, as the server extends all messages sent to the client
<archived> tag and an ID. Later it is easily possible to obtain all
messages that arrived since then by issuing a query with the last known
Now it is up to the client implementors to add support for MAM! So far, it has been implemented in the web-based OTalk client, more are to come probably.
In the light of last year's revelations, it should be clear to everybody that end-to-end encryption is an essential part of any modern IM suite. Unfortunately, XMPP is not there yet. The XMPP Ubiquitous Encryption Manifesto is a step into the right direction, enforcing encryption of client-to-server connections as well as server-to-server connections. However, more needs to be done to protect against malicious server operators and sniffing of direct client-to-client transmissions.
There is Off-The Record Messaging (OTR), which provides strong encryption for chat conversations, and at the same time ensures (cryptographic) deniability. Unfortunately, cryptographic deniability provably does not save your ass. The only conclusion from that debacle can be: do not save any logs. This imposes a strong conflict of interest on Android, where the doctrine is: save everything to SQLite in case the OOM killer comes after you.
The other issue with OTR over XMPP (which some claim is solved in protocol version 3) is managing multiple (parallel) logins. OTR needs to keep the state of a conversation (encryption keys, initialization vectors and the like). If your chat buddy suddenly changes from a mobile device to the PC, the OTR state machine is confused, because that PC does not know the latest state. The result is, your conversation degrades into a bidirectional flood of "Can't decrypt this" error messages. This can be solved by storing the OTR state per resource (a resource is the unique identifier for each client you use with your account). This fix must be incorporated into all clients, and such things tend to take time. Ask me about adding OTR to yaxim next year.
Oh, by the way. OTR also does not mix well with archiving or carbons!
There is of course also PGP, which also provides end-to-end encryption, but requires you to store your key on a mobile device (or have a separate key for it). PGP can be combined with all kinds of archiving/copying mechanisms, and you could even store the encrypted messages on your device, requiring an unlock whenever you open the conversation. But PGP is rather heavy-weight, and there is no easy key exchange mechanism (OTR excels here with the Socialist Millionaire approach).
And then there are lolcats1. The Internet was made for them. But the XMPP community kind-of missed the trend. There is XEP-0096: File Transfer and XEP-0166: Jingle to negotiate a data transmission between two clients. Both protocols allow to negotiate in-band or proxy-based data transfers without encryption. "In-band" means that your multimedia file is split into handy chunks of at most 64 kilobytes each, base64-encoded, and sent via your server (and your buddy's server), causing some significant processing overhead and possibly triggering rate limiting on the server. However, if you trust your server administrator(s), this is the most secure way to transmit a file in a standards-compliant way.
You could use PGP to manually encrypt the file, send it using one of the mentioned mechanisms, and let your buddy manually decrypt the file. Besides the usability implications (nobody will use this!), it is a great and secure approach.
But usability is a killer, and so of course there are some proposals for encrypted end-to-end communication.
The browser developers did it right with WebRTC. You can have an end-to-end encrypted video conference between two friggin' browsers! This must have rang some bells, and JSON is cool, so there was a proposal to stack JSON ontop of XMPP for end-to-end encryption. Obviously because security is not complicated enough on its own.
In the OTR specification v3, there is an additional mechanism to exchange a key for symmetric data encryption. This can be used to encrypt a file transmission or stream, in a non-standard way.
This is leveraged by CryptoCat, which is known for its security. CryptoCat is splitting the file into chunks of 64511 bytes (I am sure this is completely reasonable for an algorithm working on 16-byte blocks, so it needs to be applied 4031.9375 times), with the intention to fit them into 64KB transmission units for in-band transmission. AES256 is used in CTR mode and the transmissions are secured by HMAC-SHA512.
In ChatSecure, the OTR key exchange is leveraged even further, stacking HTTP on top of OTR on top of XMPP messages (on top of TLS on top of TCP). This might allow for fast results and a high degree of (library) code reuse, but it makes the protocol hard to understand, and in-the-wild debugging even harder.
All the above only works on devices where you can keep a permanent connection to an XMPP server. Unfortunately, there is a huge walled garden full of devices that fail this simple task2. On Apple iOS, background connections are killed after a short time, the app developer is "encouraged" to use Apple's Push Service instead to notify the user of incoming chat messages.
This feature is so bizarre, you can not even count on the OS to launch your app if a "ping" message is received, you need to send all the content you want displayed in the user notification as part of the push payload. That means that as an iOS IM app author you have the choice between sacrificing privacy (clear-text chat messages sent to Apple's "cloud") or usability (display the user an opaque message in the kind of "Somebody sent you a message with some content, tap here to open the chat app to learn more").
And to add insult to injury, this mechanism is inherently incompatible with XMPP. If you write an XMPP client, your users should have the free choice of servers. However, as a client developer you need to centrally register your app and your own server(s) for Apple's push service to work.
Therefore, the iOS XMPP clients divide into two groups. In the first group there are apps that do not use Apple Push, that maintain your privacy but silently close the connection if the phone screen is turned off or another app is opened.
In the second group, there are apps that use their own custom proxy server, to which they forward your XMPP credentials (yes, your user name and password! They better have good privacy ToS). That proxy server then connects to your XMPP server and forwards all incoming and outgoing messages between your server and the app. If the app is killed by the OS, the proxy sends notifications via Apple Push, ensuring transparent functionality. Unfortunately, your privacy falls by the wayside, leaving a trail of data both with the proxy operators and Apple.
So currently, iOS users wishing for XMPP have the choice between broken security and broken usability – well done, Apple! Fortunately, there is light at the end of the tunnel. The oncoming train is an XEP proposal for Push Notifications (slides with explanation). It aims at separating the XMPP client, server, and push service tasks. The goal is to allow an XMPP client developer to provide their own push service, which the client app can register with any XMPP server. After the client app is killed, the XMPP server will inform the push service about a new message, which in turn informs Apple's (or any other OS vendor's) cloud, which in turn sends a push message to the device, which the user then can use to re-start the app.
This chain reaction is not perfect, and it does not solve the message-content privacy issue inherent to cloud notifications, but it would be a significant step forward. Let us hope it will be specified and implemented soon!
So we have solved connection stability (except on iOS). We know how to tackle synchronization of the message backlogs between mobile and desktop clients. Client connections are encrypted using TLS in almost all cases, server-to-server connections will follow soon (GMail, I am looking at you!).
End-to-end encryption of individual messages is well-handled by OTR, once all clients switch to storing the encryption state per resource. Group chats are out of luck currently.
The next big thing is to create an XMPP standard extension for end-to-end encryption of streaming data (files and real-time), to properly evaluate its security properties, and to implement it into one, two and all the other clients. Ideally, this should also cover group chats and group file sharing (e.g. on top of XEP-0214: File Repository and Sharing plus XEP-0329: File Information Sharing).
If we can manage that, we can also convince all the users of WhatsApp, Facebook and Google Hangouts to switch to an open protocol that is ready for the challenges of 2014.
lolcats, porn, or whatever other kind of multimedia content you want transmitted from one place to another. For the sake of this discussion, streaming content is considered as "multimedia" as much as the transmission of image, video or other files. ↩
the Apple fanboy will object that this is a feature and not a bug, because it prevents evil apps from eating the device battery in the background. I am sure it is a feature indeed – one intended to route all your IM traffic through an infinite loop. ↩
This release comes with some long-awaited features, like Stream Management, proper roster handling, improved error display and better internationalization.
Support for XEP-0198: Stream Management was
planned since 2009 and deferred many
times due to technical challenges and a lack of time. Finally, it is there,
and working well against prosody 0.9
mod_smacks enabled. Whenever your Android switches between
WiFi and 3G, yaxim is interrupted for some seconds, but restores the session
immediately – no messages are lost!
In the future, the code will be merged back into the SMACK library to allow other Android clients to benefit from seamless session resumption.
Prior to 0.8.7, yaxim’s default policy for incoming buddy request was to silently accept them. Yes, you read right. The authors are very ashamed of this fact, and it was due time to change the state of affairs.
With the current release, incoming requests are displayed in the roster, and a dialog pops up when you tap them:
The XEP-0280: Message Carbons support introduced in 0.8.6 made your phone noisy when you were chatting from another client, as it beeped on every incoming message copy. To stop this annoyance, the notification behavior has been changed as follows:
At the same time, the XEP-0184: Delivery Status of copied messages is now also correctly tracked in the chat log.
The exact error message is only displayed in a notification – there is no place for it in the context of the chat message, yet. This will be changed in one of the next releases.
As of 0.8.7, yaxim supports Internationalized Domain Names for server addresses. In earlier releases, you had to manually enter the punycode into the custom server field. In the latest release, IDNA names are supported in the JID field as well as for custom server names.
Right-to-Left languages are also supported as of now for roster entries, messages and the interface. However at the time of writing, the only available RTL translation is Hebrew, thanks to Darlan from Gajim:
Please contribute some more!
From the 0.8.6 release wishlist, only XEP-0198 has been implemented. MUC support will be worked on next, we promise!
HTTP callbacks (aka Webhooks) are great for sending notifications to remote servers in realtime. In most setups, the URLs to contact are provided by foreign entities. All your application needs to do is allow such URLs to be registered, and then hit them whenever interesting things happen. Easy enough, right?
Not so fast. What if someone provides a URL such as "http://localhost:10000/destructive-command/" and you've got an internal web service running that port? Under normal circumstances, you might not expect this service to be accessible from the outside. Perhaps you have a firewall, or perhaps the internal service binds explicitly to the localhost interface. Either way, the HTTP callback pattern provides attackers an avenue to access this service from within your internal network, bypassing these kinds of expected security measures.