Agregador de noticias

Jitsi News: Our JitMeet talk at FOSDEM

Planet Jabber - 7 February, 2014 - 23:00

We gave a talk on meet.jit.si describing Jitsi Videobridge, JitMeet and the other components that we used to build the service. Check it out

buddycloud: Buddycloud Crawler in XEP-0060 and the Buddycloud XEP

Planet Jabber - 7 February, 2014 - 10:17

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=’channeluser@example.com/KillerApp’ id=’items1’>

<pubsub xmlns=’http://jabber.org/protocol/pubsub’>
<items node=’/user/kitteh@example.com/posts’>
<item id=”1291048810046”>
<entry xmlns=”http://www.w3.org/2005/Atom” xmlns:thr=”http://purl.org/syndication/thread/1.0”>
<author>
<name>Dirk</name>
<jid>fahrertuer@example.com</jid>
</author>
<content type=”text”>A comment, wondering what all this testing does</content>
<published>2010-11-29T16:40:10Z</published>
<updated>2010-11-29T16:40:10Z</updated>
<id>/user/channeluser@example.com/posts:1291048810046</id>
</entry>
</item>
<!— [more items…] —>
</items>
<set xmlns=’http://jabber.org/protocol/rsm’>
<first>1291048810046</first>
<last>1131048810046</last>
<count>19827</count>
</set>
</pubsub>
</iq>

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.

Job done.
Next step on performance improvement list: crawl the /firehose when possible.

Ignite Realtime Blog: Openfire 3.9.1 has been released

Planet Jabber - 6 February, 2014 - 22:02

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.

 

md5sum
filename

979c431cbf416d387b2ef7ca5d7f6531

JSopenfire-3.9.1-ALL.pkg.gz7fb231b58d581babd5d7b65e05b9a953openfire-3.9.1-1.i386.rpm0ffbeb206b45538e8f0ff63325026e37openfire-3.9.1-1.src.rpm3ca1d72c5a34b820a5e0ab15ab21ee34openfire_3.9.1_all.deb028af7beb80cd552a4233434e7597729openfire_3_9_1.dmg79c13434815d05d88031b75adcf85275openfire_3_9_1.exef05b0bfbbc6e04a6fc8cbcdd53e79d8copenfire_3_9_1.tar.gz9799c471bed11058c971ed8598ce8449openfire_3_9_1.zip25f716c5497597b59dcce71b7fb0dbb2openfire_src_3_9_1.tar.gz9b7ccb7d1483f62f4da930553c9363c2openfire_src_3_9_1.zip

 

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!

Jabber.org Notices: Distributed Denial of Service Attacks

Planet Jabber - 6 February, 2014 - 00:00
The jabber.org IM service has been under attack over the last several days. As a result, your connectivity might be intermittent and message delivery might be slow. In addition, we have temporarily blocked communication with a number of other XMPP servers on the Internet to protect the jabber.org server. Please see our post at http://mail.jabber.org/pipermail/juser/2014-February/007048.html for further details.

Ignite Realtime Blog: Openfire 3.9.0 has been released

Planet Jabber - 5 February, 2014 - 22:14

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.

 

md5sumfilename

e68c95feba256d8f010682b845a901e2

openfire_3_9_0.dmga5cf6e3121aaf8b8367381db0eddb7e5openfire_3_9_0.exea0b4e5d15e4e9c0ac9f5fb8645a32fafopenfire_3_9_0.tar.gza3088db15e73c884f22ff14842d80642openfire_3_9_0.zipd09cb027cf537c866c2e8896b1f3125dopenfire_src_3_9_0.tar.gz8fffc005508684e2fb23314df8d4f502openfire_src_3_9_0.zip674b86bc209ca51e71fe8fe9f05883f4JSopenfire-3.9.0-ALL.pkg.gz3e883a6c8a8504f6a0934b7054efce66openfire-3.9.0-1.i386.rpm8d661624495d232323ae061246b47ecdopenfire-3.9.0-1.src.rpm48167fb89ba804e297faa70b37da1b95openfire_3.9.0_all.deb

Jitsi News: Learn about Jitsi Videobridge and JitMeet at BlogGeek

Planet Jabber - 30 January, 2014 - 23:00

BlogGeek.me is one of the most renowned sources of WebRTC news, viewpoints, analysis and debates. This week the site is running an article/interview on Jitsi Videobridge. Have a look!

Georg Lukas: Georg Lukas: The (Sad) State of Mobile XMPP in 2014

Planet Jabber - 30 January, 2014 - 17:20

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.

Clients supporting XEP-0198 with stream resumption: Gajim, yaxim.

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.

So I have XEP-0198, am I good now?

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).

Entering Coverage Gaps

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.

Message Synchronization

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 with an <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 archive ID.

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.

End-to-End Encryption

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).

Encrypted Media

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.

WebRTC

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.

XMPP Extensions Graveyard

Then there are ESessions, a deferred XEP from 2007, and Jingle-XTLS, which didn't even make it into an XEP, but looks promising otherwise. Maybe somebody should implement it, just to see if it works.

Custom Extensions

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.

A completely different path is taken by Jitsi, where Jingle VoIP sessions are protected using the Zimmerman RTP encryption scheme. Unfortunately, this mechanism does not transfer to file exchange.

And then iOS...

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!

Summary

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.

Comments on HN

  1. 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. ↩

  2. 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. ↩

yaxim: yaxim 0.8.7 - Stream Management and More

Planet Jabber - 30 January, 2014 - 16:17

A new version of yaxim, 0.8.7, has been released today (ChangeLog, commit history) right in time for the XMPP Summit. Download 0.8.7 now!

This release comes with some long-awaited features, like Stream Management, proper roster handling, improved error display and better internationalization.

Stream Management

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 servers with 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.

Roster Management

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:

Carbon Notifications

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:

  • messages you send from your other client are silently added to yaxim’s log
  • when yaxim receives the first message copy, it makes a sound
  • further message copies are silently added to the log, until you open the chat window
  • messages directly sent to yaxim always cause a sound

At the same time, the XEP-0184: Delivery Status of copied messages is now also correctly tracked in the chat log.

Error Messages

If an error stanza is received for an outgoing message, earlier versions of yaxim silently ignored it. The authors were made aware of the problem by @das_aug, and #108 was promptly fixed:

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.

Internationalization

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!

What’s Next

From the 0.8.6 release wishlist, only XEP-0198 has been implemented. MUC support will be worked on next, we promise!

Other TODOs:

  • a Tablet UI with the contacts list on the side of a chat view
  • end-to-end encryption, either with OTR or with GnuPG.
  • more user-friendlyness! \o/

Fanout Blog: How to safely invoke Webhooks

Planet Jabber - 28 January, 2014 - 22:58

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.

...

Peter Saint-Andre: Self-Organization Man

Planet Jabber - 28 January, 2014 - 00:00
One of the reasons I'm so excited about joining &yet is that Adam Brault is a fellow admirer of Dee Hock. Although Mr. Hock is best known as the founder of VISA, it's his fertile ideas about business that I find most compelling. Here is a brief summary of my understanding, but I encourage you to closely read his book One From Many if you're intrigued by what follows.

...

Alexander Gnauck: Task-based asynchronous MUC room configuration

Planet Jabber - 27 January, 2014 - 09:24

The question on how to change the configuration of a Muc room, or how to make a room persistend comes up very often in our forums and support enquiries.

Here is a small example using MatriX and the task based asynchronous pattern.

In MatriX most of the Muc functionality can be accessed with the MucManager component. We assume that you are familiar with the MucManager and have joined or created Muc rooms already.

In this small example we want to make an existing room persistent.
Four steps are required to achieve this:

  1. Request the current room configuration.
  2. Parse the current room configuration in code or render it to a GUI.
  3. Create the xdata result, either in code or from the user input in the GUI.
  4. Submit the new room configuration.

Here is the code:

private async void MakeRoomPersitent(Jid roomJid) { // Step 1, request the room configuration var iq = await mm.RequestRoomConfigurationAsync(roomJid); if (iq.Type == IqType.result) // only proceed on result { // Step 2 and 3, parsing the current config and // creating the result is done in the same loop here. var xdata = iq.Query.Element<Data>(); var xDataResult = new Data { Type = FormType.submit }; foreach (var field in xdata.GetFields()) { var retField = new Field() { Type = field.Type, // keep the type Var = field.Var // keep the var }; // we are changing the muc#roomconfig_persistentroom only // other fields get copied only with the existing values if (field.Var == "muc#roomconfig_persistentroom") retField.AddValue(true); else retField.AddValues(field.GetValues().ToArray()); xDataResult.AddField(retField); } // Step 4, submit the changed configuration back to the server (room) var submitIq = await mm.SubmitRoomConfigurationAsync(roomJid, xDataResult); if (submitIq.Type == IqType.result) Debug.WriteLine("success"); else Debug.WriteLine("something went wrong"); } }

If you want to render Data froms to UI, and generate responses from the UI input, you can use the sources in the MatriX.Ui project which can we downloaded from here:
http://www.ag-software.net/download-directory/

Jitsi News: Meet us at FOSDEM 2014!

Planet Jabber - 26 January, 2014 - 23:00

As usual, the Jitsi team will be present at FOSDEM 2014: Friday through Sunday, Jan 31 to Feb 02 in Brussels. We will have our usual stand and one lightning talk on Jitsi Videobridge and JitMeet. Looking forward to meeting you all there!

buddycloud: Buddycloud in the Mountains Update

Planet Jabber - 26 January, 2014 - 14:30

We have enough food, drink, wood for the fire, good wifi and it looks like we might be snowed in. We’re in the Austrian mountains working on a really simple and quick way to host a new Buddycloud site.

Some background: We have worked hard to organise our install docs and make buddycloud easy to install with .deb packages. Guilherme has also worked on a protocol tester to check buddycloud instances really are working and installed correctly.

Buddycloud’s design is to be as modular as possible. This gives you choice:

  • Don’t like the media server, slide it out and use a replacement.
  • Don’t like how we do the webclient, slide it out and use your own frontend. 

The problem with this approach is that there are more moving pieces to setup and more places to make a mistake at install time. And this is before you have even decided that Buddycloud is right for your needs.

So we’re building a way for you to get your own Buddycloud and XMPP account. When you grow, you can spin up your own Buddycloud site on your own hardware and migrate your data over.

The hosting platform (at least v0.0.1) will:

  • host your buddycloud on a sub-domain (eg: megacorp.buddycloud.net)

  • your own buddycloud website, API, buddycloud service, media service

  • user management: invite, add, delete, disable users

  • and a nice UI and API to manage everything.

  • tested updates using Docker (helps us ship working code).

Expect more news and code soon.

Rene starting the fire

Doors are not very big

Fanout Blog: Publishing JSON over XMPP

Planet Jabber - 24 January, 2014 - 20:12

At Fanout, we've developed a powerful publish-subscribe system for fronting custom APIs. Sometimes, though, API design is too much to think about and all you want to do is push some JSON.

To address this need, we initially created our own proprietary JSON-publishing protocol (a.k.a. "FPP") and corresponding client library. This made it possible for developers to implement realtime updates in just a few lines of code, transported by magic. While this system worked well enough, it wasn't terribly satisfying to have invented yet-another-protocol in order to accomplish this. Sure, every other pubsub cloud service has done the same thing, but the status quo makes for a bunch of redundant efforts that all achieve more-or-less the same result, and it hampers interoperability. So, lately, we've been looking into how we could adapt an existing standard for pushing JSON.

...

Tigase Blog: Tigase XMPP Server 5.2.0 RC2

Planet Jabber - 24 January, 2014 - 12:15

Second Release Candidate of Tigase XMPP Server 5.2.0 has been published. Binaries are available for download right now in the files section on the project tracking system. Sources are available in our code repository under the tag 5.2.0-rc2 - tags/tigase-server-5.2.0-rc2. Maven artifacts have been deployed to our maven repository.

In addition to changes from previous releases (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) release candidate includes following changes:

  • DynamicRoster API was extended,
  • Lots of clustering-related fixes (duplicate connection records, user connecting twice, forwarding of stanzas),
  • Further improvements in security (Tigase XMPP Server - grade A software),
  • Inclusion of new PubSub 3.0.0 which features performance improvements due to reworked schema (see: PubSub database schema conversion),
  • Improvements in XML DoS protection (#1364),
  • Automatic roster subscription (presence and jabber:iq:roster plugins has new optio: auto-authorize; setting it to true results in automatic, mutual “both” subscription state for both user and contact),

As always all kind of feedback is very welcome. Please feel free to report found bugs in our bugtrack and post questions in the forums.

Tags: serverreleaseTigase server5.2.0release-candidateNew version release

Tigase Blog: Tigase XMPP Server - grade A software

Planet Jabber - 21 January, 2014 - 15:19

We always strive to provide you with the best possible experience while using Tigase therefore we improved Tigase to be on pair with the latest notion of ubiquitous encryption on the XMPP network. This results in the grade A on XMPP Observatory for services that run Tigase and follow configuration guidelines outlined below.

In principle obtaining grade A for a service running Tigase entails:

  • using a correct version of Tigase - 5.2.0 rc2 or later;
  • having a correct certificate - whole guide devoted to the subject, including  obtaining it and configuring Tigase can be found in Creating and loading the server certificate in pem files;
  • enabling a hardened mode - a special mode which configure a few security aspects of Tigase, including disabling of SSLv3 among other things, details can be found in --hardened-mode.

Above will result in grade A on XMPP Observatory, as you can see for our services:

Tags: securitysslTLShardened modeserver

Peter Saint-Andre: Clearing the Decks

Planet Jabber - 20 January, 2014 - 00:00
In preparation for my new gig, I've been actively tuning out extraneous information sources: email discussion lists, Twitter users, blogs, news websites, financial commentators, political pundits -- you name it, I've started to ignore it. Most of it is distracting chatter. More to the point, very little of it helps me improve as a technologist, as a teammate, as a person. Better, I think, to spend my time diving more deeply into real code and APIs; to absorb big ideas through books, specs, and papers; to interact directly with people who are important to me and to the goals we're achieving together; to devote longer blocks of time to actual work.

...

Swift Blog: Sluift Interactive Console

Planet Jabber - 18 January, 2014 - 23:00

Sluift, our Swiften-based XMPP script tool, comes with an interactive mode that lets you type your commands directly in a console. Until now, this console was actually the standard one that comes with the Lua distribution, a very bare bones “REPL” loop. However, we recently replaced this simple implementation with our own, which allowed us to do some usability enhancements such as tab completion, integrated help, and much more. These enhancements make it easier to execute commands, play around with Sluift, and help you writing Sluift scripts. In this post, we describe these new improvements in more detail.

If you want to try any of these new Sluift features yourself, just check out a development version from the Swift Git repository, or get it from homebrew using brew install --HEAD libswiften.

Tab completion

The first improvement is that the console now supports tab completion. This not only makes it easy to quickly type long commands such as sluift.new_client, but it also helps to quickly discover which commands or fields are available on a given object:

> sluift.<TAB> base64 disco get_help hexify jid new_uuid sleep tprint copy from_xml help idn new_client sha1 to_xml unhexify > client = sluift.new_client('alice@wonderland.lit', 'MyPass') > client:<TAB> add_contact for_each_message get_next_message messages send_presence async_connect for_each_presence get_next_presence process_events set cancel_subscription for_each_pubsub_event get_next_pubsub_event pubsub set_caps_node confirm_subscription get get_software_version pubsub_events set_command connect get_contacts get_vcard query_pubsub set_disco_info disconnect get_disco_items get_xml remove_contact set_options events get_dom is_connected send set_version for_each_event get_next_event jid send_message wait_connected Print and store command results

A second improvement is that we print the results of each command invoked in the console. You therefore no longer have to remember to put = in front of a command to actually see the result:

> sluift.base64.encode("Hello world") SGVsbG8gd29ybGQ= > client userdata: 0x7fd76b45a568 > client:get_software_version{to = 'wonderland.lit'} { ['os'] = 'Linux', ['version'] = '0.9.0', ['name'] = 'Prosody' }

Apart from printing each result, the console also stores each result of each command in the variables _1, _2, …, allowing you to reuse results easily in subsequent commands:

> sluift.new_client('alice@wonderland.lit', 'MyPass') userdata: 0x7fd76b735fc8 > client = _1 > client:connect() Integrated help

The console now comes with integrated help functionality. If you want help for any object, just call help(), and pass the object or function you want help for. For example, getting help for a function:

> help(sluift.new_client) Creates a new client. Returns a `Client` object. Parameters: jid: The JID to connect as passphrase: The passphrase to use

Getting help for an object:

> client = sluift.new_client('alice@wonderland.lit', 'MyPass') > help(client) Client interface Methods: add_contact: Add a contact to the contact list. async_connect: Connect to the server asynchronously. ... pubsub: Returns a `PubSub` object for communicating with the PubSub service at `jid`. ...

In case you don’t have an object, but want to see the methods available on a class of objects, you can pass a string to help:

> help("PubSub") Interface to communicate with a PubSub service Methods: events for_each_event get_affiliations ...

All the help provided in the interactive console is now also available on-line.

Changing context

Finally, we made it easier to do multiple operations on an object, without each time having to specify the object on which to call the operation. You can now change the “context” of the console by calling with with the target object as an argument. Any global function or field requested will first be searched in the target object, after which it falls back to the normal behavior. Moreover, any function called and found in the target object will be passed self implicitly. For example, suppose you want to do multiple operations on a client:

> with(sluift.new_client('alice@wonderland.lit', 'MyPass')) alice@wonderland.lit> connect() alice@wonderland.lit> get_software_version{to = 'wonderland.lit'} { ['os'] = 'Linux', ['version'] = '0.9.0', ['name'] = 'Prosody' }

Notice that the prompt of the console reflects the current context.

Resetting the context can be done by calling with():

alice@wonderland.lit> with() >

The with function is also available for scripts to use (as sluift.with). You can pass a dynamic scope to only temporarily change the context. For example, a variant of the EchoBot that uses with would look like this:

client = sluift.new_client('alice@wonderland.lit', 'MyPass') sluift.with(client, function () connect() set_version{name = "EchoBot", version = "0.1"} send_presence("Send me a message") for message in messages() do send_message{to = message["from"], body = message["body"]} end end)

Thijs Alkema: Misconceptions about forward-secrecy

Planet Jabber - 17 January, 2014 - 22:16

Lately, there has been a lot of interest in forward-secrecy, mostly in the context of TLS/HTTPS. Some people seem to think it’s a magic bullet that will thwart all the NSA’s efforts. I am not against forward-secrecy, to the contrary, I think any encrypted communications protocol should use it, but I think it is important that people keep realistic expectations about what forward-secrecy protects them against. The worst security is security that you assume you have, but don’t actually have.

Misconception #1: “More keys, so more work to break.”

What some people seem to think is that forward-secrecy implies that to break the encryption of n sessions, n times as much computational power is necessary compared to breaking 1 session, because it involves n different session keys.

This is not automatically the case. Not only does forward-secrecy not imply it, common protocols which have forward-secrecy based on Diffie-Hellman key exchanges do not have this property.

To break a number of Diffie-Hellman negotiated keys all using the same Diffie-Hellman group, a number of different attacks are known. Many of these scale pretty well in the number of sessions.

Take for example a naive brute force search. We start generating g, g2 mod p, g3 mod p, … until we find the key we want. This requires modular multiplication of a huge number (lets say at least 1024 bits), so the multiplication step is quite an intensive computation. Comparing numbers (even 1024 bit numbers) is by comparison much easier. So it doesn’t matter much if we need to compare gx mod p to one, two or n different numbers (if we have a lot of keys, we have other options like sorted tables to optimize this further). If the NSA captured the ciphertext of you logging in 50 different times, then it’s 50 times as easy to obtain your password by decrypting at least one of the sessions compared to if they only captured one login.

Misconception #2: “They can’t break future sessions.”

Many people think 1024-bit RSA keys can be cracked by the NSA. If they would do this to a key used for a TLS handshake that didn’t use ECDHE/DHE, every captured TLS session using that key would be trivially decryptable.

The brute force attack on Diffie-Hellman I described under #1 does not break future sessions: it can only break the sessions that have already been captured. When new keys come in, the process has to start all over again.

But using the index-calculus algorithm instead, the attacker first needs to pre-compute lots of data before the actual key is necessary in the computation. The attack has 3 steps: find some powers of g which factorize into a small set of primes (the factor base). Then taking the logg of the equations gx = p1s1 … prsr creates linear equations with the logarithms of the primes as unknowns. When enough equations are found, they can be solved using linear algebra mod (p – 1). In the final stage, the key is multiplied with g until a number is found that factors into the factor base. From this, it is easy to compute the discrete log of the key.

The first two steps do not use the key at all, their result can be stored for later use to decrypt future keys. There is a trade-off here, though: the larger the factor base, the slower the first and second stages are, but the faster the third stage is. It’s unlikely that it is worth the effort to make the third stage as efficient as decrypting a session with a RSA private key is, but it’s not impossible.

Misconception #3: “It’s automatically more secure!”

We can conclude from #1 and #2 that attacks on Diffie-Hellman groups exist that can reveal as much as an RSA private key.

It is generally assumed that Diffie-Hellman and RSA offer approximately equal security for the same bit length. So breaking 1024-bit RSA would be as hard as breaking 1024-bit Diffie-Hellman.

Therefore, if you’re using a 1024-bit Diffie-Hellman group (if you’re using Java and DHE, you’re using a 1024-bit group, if you’re not using the very latest version of Apache, you’re using a 1024-bit group) you effectively have the same security level as somebody using a 1024-bit RSA key, but for one exception: the RSA private key can be stolen (by NSA hackers or court orders). But please keep in mind that this is the only benefit forward-secrecy gives you.

What does this mean for OTR?

Every OTR conversation uses a DH key exchange with the same 1536 bit prime from RFC 3526. While I have no idea how much it would cost, there is a finite amount of work, somewhere in the order of breaking RSA-1536, the NSA needs to do after which they are capable of decrypting every OTR encrypted session with an hour of work. Is it realistic to hope the NSA never had enough interest/budget against OTR to carry out such an attack?

Remember this news article from September 2013 about the NSA’s capabilities:

“For the past decade, N.S.A. has led an aggressive, multipronged effort to break widely used Internet encryption technologies,” said a 2010 memo describing a briefing about N.S.A. accomplishments for employees of its British counterpart, Government Communications Headquarters, or GCHQ. “Cryptanalytic capabilities are now coming online. Vast amounts of encrypted Internet data which have up till now been discarded are now exploitable.”

I don’t think the amount of OTR traffic is “vast”, but other than that, this seems spot on.

Thijs Alkema: Misconceptions about forward-secrecy

Planet Jabber - 17 January, 2014 - 22:16

Lately, there has been a lot of interest in forward-secrecy, mostly in the context of TLS/HTTPS. Some people seem to think it’s a magic bullet that will thwart all the NSA’s efforts. I am not against forward-secrecy, to the contrary, I think any encrypted communications protocol should use it, but I think it is important that people keep realistic expectations about what forward-secrecy protects them against. The worst security is security that you assume you have, but don’t actually have.

Misconception #1: “More keys, so more work to break.”

What some people seem to think is that forward-secrecy implies that to break the encryption of n sessions, n times as much computational power is necessary compared to breaking 1 session, because it involves n different session keys.

This is not automatically the case. Not only does forward-secrecy not imply it, common protocols which have forward-secrecy based on Diffie-Hellman key exchanges do not have this property.

To break a number of Diffie-Hellman negotiated keys all using the same Diffie-Hellman group, a number of different attacks are known. Many of these scale pretty well in the number of sessions.

Take for example a naive brute force search. We start generating g, g2 mod p, g3 mod p, … until we find the key we want. This requires modular multiplication of a huge number (lets say at least 1024 bits), so the multiplication step is quite an intensive computation. Comparing numbers (even 1024 bit numbers) is by comparison much easier. So it doesn’t matter much if we need to compare gx mod p to one, two or n different numbers (if we have a lot of keys, we have other options like sorted tables to optimize this further). If the NSA captured the ciphertext of you logging in 50 different times, then it’s 50 times as easy to obtain your password by decrypting at least one of the sessions compared to if they only captured one login.

Misconception #2: “They can’t break future sessions.”

Many people think 1024-bit RSA keys can be cracked by the NSA. If they would do this to a key used for a TLS handshake that didn’t use ECDHE/DHE, every captured TLS session using that key would be trivially decryptable.

The brute force attack on Diffie-Hellman I described under #1 does not break future sessions: it can only break the sessions that have already been captured. When new keys come in, the process has to start all over again.

But using the index-calculus algorithm instead, the attacker first needs to pre-compute lots of data before the actual key is necessary in the computation. The attack has 3 steps: find some powers of g which factorize into a small set of primes (the factor base). Then taking the logg of the equations gx = p1s1 … prsr creates linear equations with the logarithms of the primes as unknowns. When enough equations are found, they can be solved using linear algebra mod (p – 1). In the final stage, the key is multiplied with g until a number is found that factors into the factor base. From this, it is easy to compute the discrete log of the key.

The first two steps do not use the key at all, their result can be stored for later use to decrypt future keys. There is a trade-off here, though: the larger the factor base, the slower the first and second stages are, but the faster the third stage is. It’s unlikely that it is worth the effort to make the third stage as efficient as decrypting a session with a RSA private key is, but it’s not impossible.

Misconception #3: “It’s automatically more secure!”

We can conclude from #1 and #2 that attacks on Diffie-Hellman groups exist that can reveal as much as an RSA private key.

It is generally assumed that Diffie-Hellman and RSA offer approximately equal security for the same bit length. So breaking 1024-bit RSA would be as hard as breaking 1024-bit Diffie-Hellman.

Therefore, if you’re using a 1024-bit Diffie-Hellman group (if you’re using Java and DHE, you’re using a 1024-bit group, if you’re not using the very latest version of Apache, you’re using a 1024-bit group) you effectively have the same security level as somebody using a 1024-bit RSA key, but for one exception: the RSA private key can be stolen (by NSA hackers or court orders). But please keep in mind that this is the only benefit forward-secrecy gives you.

What does this mean for OTR?

Every OTR conversation uses a DH key exchange with the same 1536 bit prime from RFC 3526. While I have no idea how much it would cost, there is a finite amount of work, somewhere in the order of breaking RSA-1536, the NSA needs to do after which they are capable of decrypting every OTR encrypted session with an hour of work. Is it realistic to hope the NSA never had enough interest/budget against OTR to carry out such an attack?

Remember this news article from September 2013 about the NSA’s capabilities:

“For the past decade, N.S.A. has led an aggressive, multipronged effort to break widely used Internet encryption technologies,” said a 2010 memo describing a briefing about N.S.A. accomplishments for employees of its British counterpart, Government Communications Headquarters, or GCHQ. “Cryptanalytic capabilities are now coming online. Vast amounts of encrypted Internet data which have up till now been discarded are now exploitable.”

I don’t think the amount of OTR traffic is “vast”, but other than that, this seems spot on.

Distribuir contenido