The folks over at Ars Technica have published a video tutorial on setting up your own XMPP server (using Prosody of course!). If you have been putting off setting up your own server then it's worth watching, the whole process from installation to configuring your client is explained in under 10 minutes.
After watching the tutorial, you might want to read more about some of the topics it touched upon:
Prosody version: Depending on the version of your Debian/Ubuntu server, you may find that it does not yet contain the latest releases of Prosody, but you can always find the latest release in our package repository. Newer releases have improvements in many areas, including performance, usability and security features.
DNS: DNS is usually straightforward, but if you want to learn more about SRV records and their potential uses, you may find our DNS in XMPP article helpful.
Security: To learn more about the various aspects of running a secure XMPP server, see our Security page. Also xmpp.net is a useful service to test the communication security of XMPP servers. Note that your server must be accessible from the internet (i.e. it won't work for LAN-only servers).
Password hashing: The choice between plaintext or hashed storage for passwords can be confusing. The short answer is that if your TLS is well secured, or if you have a modern client that supports the "SCRAM-SHA-1" authentication mechanism, definitely enable hashed credentials. The longer answer can be found in our article, "Plain or hashed password storage?".
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:
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 -- amarokwhere "flatmates" is the name of the group which can control Amarok. You may also want to remote control Okular (e.g. for a talk), or VLC on your phone.Below is an example with VLC.
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.The Target
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 Q!
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.On XMPP
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 <iq, <message or <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.Conclusion
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.