Some of our customers asked for NuGet packages. The roadmap of our development is heavily impacted by our customer requests. We are always receptive to your criticism, ideas and praise
You can find the MatriX NuGet package here:
In just 34 days the first full test run of ubiquitous security on the XMPP network will be attempted by many service operators.
Like the IPv6 test days, on the 4th January XMPP server operators are turning on TLS encryption for s2s and c2s connections and testing to see what doesn’t work and what needs more work.
The participants of this effort would like you to join others in the XMPP community and help secure users private communications.
They are inviting you to join other operators and secure XMPP.
Answers to common questions:
Q: how do I test my site’s security?
A: use http://xmpp.net to run a test against your domain. For help enabling full TLS encryption, check out the Securing XMPP wiki page or contact your XMPP server vendor.
Q: But what if things break?
A: This is a just a test. The changes will be rolled back on 5th January until the next test the following month.
Q: Can’t you test this all before and then switch?
A: In theory everything should work. In reality it’s better to test, rollback, fix, re-test.
Q: I heard that Google doesn’t do encrypted connections to non Gtalk servers.
A: True: server to server connections on Google network are inescure. The XMPP Board has reached out to Google at different levels and will continue to work with Google to find a way to keep XMPP interoperability with Google servers.
Q: Where do I discuss this?
A: Join the operators mailing list: http://mail.jabber.org/mailman/listinfo/operators
Q: I heard there is a manifesto?
A: Indeed – if you are a server operator and want to publicly show your support for secure user communications, sign up (with a pull request) at https://github.com/stpeter/manifesto
The operators are all looking forward to the go-live date of May 19, 2014 and excited for this huge step. Thanks for playing your part.
edit: Changed the tone and voice of the article as it had previously implied that the XSF itself was running this Test Day rather than it being the community generated event that it is.
In order to enable SASL External add following line to the init.properties filec2s/clientCertCA=/path/to/cacert.pem
File cacert.pem contains Certificate Authority certificate which is used to sign clients certificate.
Client certificate must include user's Jabber ID as XmppAddr in subjectAltName:
As specified in RFC 3920 and updated in RFC 6120, during the stream negotiation process an XMPP client can present a certificate (a “client certificate”). If a JabberID is included in a client certificate, it is encapsulated as an id-on-xmppAddr Object Identifier (“xmppAddr”), i.e., a subjectAltName entry of type otherName with an ASN.1 Object Identifier of “id-on-xmppAddr” as specified in Section 126.96.36.199 of RFC 6120. 
First 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-rc1 - tags/tigase-server-5.2.0-rc1. Maven artifacts have been deployed to our maven repository.
At the meetup event we will have sensors and actuators connected to raspberries and create interoperable interchange of data with the help of XMPP.
Interested in how XMPP could be used in the Internet of Things arena contact the organizer Joachim Lindborg XSF or Peter Waher XSF
Simon posted on the jdev mailing list a great reminder about the upcoming test day quoted below:
“We owe it to our user’s to provide secure communications” – St Peter.
To achieve ubiquitous encryption between clients and servers on XMPP, we’re
doing a phased approach similar to the ipv6 test days.
– 4th January is the first test day of full XMPP encryption. The aim -
see what breaks when all XMPP sites enable secure communication.
– February 22, 2014 – second test day
– March 22, 2014 – third test day
– April 19, 2014 – fourth test day
– May 19, 2014 – permanent upgrade
This mean that you should:
– Sysadmins: check your server’s security at http://XMPP.net
– XMPP developers: provide a bare minimum configuration to be able to
pass the tests at http://wiki.xmpp.org/web/Securing_XMPP
– Everyone: Sign the manifesto (via pull request):
I’m really excited to achieve this. It’s been too long in the making but we
have no better reasons than now to get it done.
Please also spread the word on how XMPP takes user privacy seriously.
A couple of days ago, my friend Tom asked me using GMail’s Google Talk widget why one bash command worked while another didn’t. The commands looked the same, but to make sure no UTF-8 silliness was going on, I checked Adium’s debug window. There, I noticed the messages both contained an XML element I didn’t recognize, google-mail-signature:1 2 3 4 5 6 7 <message type='chat' email@example.com' from='...@gmail.com/...' id='...' iconset='classic'> <body>...</body> <google-mail-signature xmlns='google:metadata'>JZRvRiVt_pz4h4l-VIms2ufrvbQ</google-mail-signature> <active xmlns='http://jabber.org/protocol/chatstates'/> <x value='disabled' xmlns='google:nosave'/> <record otr='false' xmlns='http://jabber.org/protocol/archive'/> </message>
This does not appear to belong to any of the officially documented Google XMPP extensions, so I tried to figure out what it is.
Zash pointed out that substituting _ with /, - with + and adding a = to fix the padding turns the data into valid base64 Florob pointed out that this is base64url encoded, with padding left out. Adding back one = of padding and base64 decoding it turned it into 20 bytes of random looking data. What sort of signature could that be?RSA or DSA?
Cryptographic signatures for email are often using RSA or DSA. It is unlikely this is an RSA signature: an RSA signature is always of the same length as the keypair and 160 bit RSA would be undeniably insecure (although Google has in the past signed their emails with a key not fully up to best practices). DSA signatures must contain a pair of two values, typically using ASN.1 encoding. That means it must always start with 0x30, which is not the case.
20 bytes is however exactly the length of a SHA-1 hash. Could it be the hash of a signature? That would make little sense, as nobody would be able to verify the signature from just the hash. It is likely either:
I observed the following:
I tried to reproduce the hash by testing 2.4 billion permutations of:1 2 3 SHA1(sender + delimiter + recipient + delimiter + message) SHA1(sender + delimiter + message + delimiter + recipient) ...
for (almost) all 1-4 character delimiters, all possible orderings of sender, recipient and message and a couple of different formats of sender and message I could think of. None of them matched the hash on the message.
Of course, it could be a different delimiter or encoding the message in a different way. But unless someone else manages to find how these hashes are calculated, it looks like only Google can generate them, using a deterministic procedure.HMAC-SHA-1
From the fact that the data is called “signature”, I think it is likely these are HMAC-SHA-1 MACs of the message generated using a key only Google has. This would make it impossible for anyone to generate a fake signature, unless they brute-forced the key used by Google. The difference between a MAC and RSA or DSA signatures is roughly the difference between symmetric and asymmetric encryption: to verify a MAC, you need the key that was used to generate it. To verify an RSA or DSA signature, you need only the public key, but you need the secret key to create that signature.Why is this dangerous?
Cryptographic signing isn’t automatically bad. Many emails are signed using DKIM and a number of people choose to sign their emails using GPG. But these are emails – most people will assume correctly these are stored forever and that the signatures can be verified forever.
IMs are different. Not only does it appear this feature is not documented anywhere, but people generally assume IMs are more ephemeral than emails. Signing them should not happen while people aren’t aware of it.
Even though nobody but Google is able to verify or fake these signatures, there is one signing oracle that can be used: Google. The fact that the signatures are deterministic means they can be later verified by sending the same message again.
If you ever use GTalk on GMail to send a message describing some illegal activities, that message will receive a signature from Google. If the recipient stores that message and signature, they have cryptographically verified blackmail material: they could later turn both message and signature over to law enforcement. Law enforcement could then take control over your account and resend the message to the recipient to verify the signature is correct, or they could try to force Google to verify the signature. If it succeeds, it proves cryptographically that your account sent that message. Of course they can’t prove the order or context of your messages, but one message in itself might be enough to get you into trouble.
I think Google should either:
With great pleasure we want to announce a new public service brought to you by yaxim.org - the yax.im (read: Yaks’ IM) public XMPP server.
To register with it, open your XMPP client (e.g. yaxim), choose a JID of your liking that ends with @yax.im, like firstname.lastname@example.org and activate “Register new account”.Server Details
The service is running the recent Prosody 0.9 XMPP server written in Lua. Many thanks go to the dedicated Prosody developers.
yax.im is reachable via IPv4 and IPv6 (if your client does not support SRV resolution, use yaxim.boerde.de as the server name, port 5222) and is hosted in Berlin, Germany. It features several extensions important for mobile clients:
Certain JIDs are barred from registration (you need to specify at least two letters, and test and admin, among some others, are disallowed).Transports and Services
So far, yax.im offers a built-in XEP-0045: MUC component at chat.yax.im with the yax.im service and yaxim app support chat room email@example.com. Feel free to bother us with any issues you might have with either the app or the server.
The server is not offering any transports. This might change if a transport implementation for XMPP or any proprietary service appears that has a credible security audit.
In the meantime, you are free to use whatever external transport you are used to.
Timothée and Vincent will be at the Cité des sciences, in Paris, to give a conference about the project. Named “Movim, réseau social et décentralisation”, you’ll be able to see the last version of the software and have a look on the decentralization advantages.
The podcast will be published as soon as possible.
Joachim is in the US (San Francisco specifically) and would love to get together with anyone from the XMPP and/or IoT community!
His original goal was to attend the Doing IoT with XMPP meetup. Either way you should poke him on the members@ mailing list to at least find a pub and raise a pint or three!
The XSF held it’s annual meeting the 29th of October and we voted for Council and Board
I’m happy for two reasons, first that my friend and coworker at &yet was elected to the Council and that I was again elected to the Board.
With all of the activity in the web space and all of the people now realizing that the internets need security and that XMPP is already a federated, secure suite of protocols - it will be a very busy year I think.
Peter Saint-Andre has created a Manifest for others to join, debate and discuss about a plan for upgrading the XMPP network to always-on, mandatory, ubiquitous encryption.
To quote Peter:
In short: we owe it to those who use XMPP technologies to improve the security of the network (and thanks to Thijs Alkemade, we now have better ways to test such security, using the newly-launched “IM Observatory” at xmpp.net). Although we know that channel encryption is not the complete answer, it’s the right thing to do because it will help to protect people’s communications from prying eyes.
Every year the members of the XSF get together to vote on the current quarter’s new and renewing members and to also elect who will become members of the Technical Council and who will server on the Board of Directors.
This year that meeting was held on the 29th of October, 2013 and Alexander has recorded the details in a on the XSF site.
The 13th XSF Technical Council for the 2013/2014 term are:
The 2013/2014 Board will consist of:
Please congratulate them if you run across any but also please help us make this another great year for the XSF.
Earlier this year we announced the open source Pushpin project, a server component that makes it easy to scale out realtime HTTP APIs. Just what kind of scale are we talking about though? To demonstrate, we put together some code that pushes a truckload of data through a cluster of Pushpin instances. Here's the output of its dashboard after a successful run:
Before getting into the details of how we did this, let's first establish some goals:
TechNet is an annual event organised by AFCEA Europe (Armed Forces Communications & Electronics Association) to highlight IT developments in the military sector. TechNet 2013 was held on 23/24 October at the Lisbon Congress Centre. This year the focus was on connecting coalition forces and bringing high-end IT capabilities to deployed forces using mobile devices.
Normally we attend these events to listen to the talks and network with other attendees. This year we were invited by our friends at HP Autonomy to share their stand for a joint HP/Isode demonstration showing Autonomy analysis of M-Link chat files.
M-Link can provide chat log archives, which can be configured to audit all messages sent either by user, by MUC room, or both. The archives are stored in an XML-like syntax on disk.
The TechNet demonstration showed how a link between M-Link’s chat log files and Autonomy could enable the analysis of real-time chat data to search for developing patterns, sentiment and intention.
Both Isode and HP Autonomy will be showing this demo at future events.
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.