Agregador de noticias

Daniel Pocock: How much of Linux will be illegal in the UK?

Planet Jabber - 3 November, 2015 - 19:13

This week I've been in the UK again, giving a talk about Lumicall and JSCommunicator in Manchester last night and a talk about Free Real-Time Communications at the mini-DebConf in Cambridge on the weekend of 7-8 November.

An interesting backdrop to these activities has been a national debate about Internet privacy. The UK Government and police are demanding laws to mandate back doors in all communications products and services.

It leaves me wondering about a range of issues:

  • Will overzealous UK police, reknowned for singling out and bullying people who don't conform with their idea of normality, start taking a more sinister attitude to people using software like Linux? For example, if airport security asks to inspect a laptop and doesn't see the familiar Windows or Mac OS desktop, will the owner of the laptop be delayed or told to leave it behind? Some people may feel this is extreme, but workers in these roles are known for taking initiative in their own special way, such as the infamous baby pat-down. If the owner of a Linux laptop is a Muslim, like the Texas schoolboy recently arrested because his clock looks suspicious to the untrained eye of a policeman, the chances of a rough encounter with authority probably rise even further.
  • Will developers still be able to use technologies like PGP and ZRTP in the UK? Will PGP key-signing parties become illegal or have to be held 20 miles offshore on a boat like the legendary pirate radio stations of the sixties?
  • Will Linux distributions such as Debian and Fedora have to avoid distributing packages such as Enigmail?
  • Will updates to Android and iOS on smartphones seek to automatically disable or remove apps like Lumicall?
  • Even if a user chooses a secure app like Lumicall for communication, will the vendor of the operating system be required to provide alternative ways to monitor the user, for example, by intercepting audio before it is encrypted by the app?
  • Without strong encryption algorithms, digital signatures will no longer be possible either and it will be impossible for software vendors to securely distribute new versions of their software.
  • Why should the police be the only workers to have their job done for them by Internet snooping? Why shouldn't spouses have a right to all their partner's communications to periodically verify they are not cheating and putting themselves at risk of diseases? Why shouldn't employers be able to check on employee's private communications and home computers to help prevent leaks of customer data? Why shouldn't the NHS be able to go through people's garbage to monitor what they eat given the WHO warning that bacon is more likely to kill you than a terrorist?
  • While the authorities moan about the internet being a "safe" place for terrorists and paedophiles, what is their real motivation for trying to bring in these new laws, even when their best technical advisors must surely be telling them about the risks and negative consequences for compatibility of UK systems in a global Internet? If the terrorist scare story is not so credible, is it more likely they are seeking to snoop on people who may not be paying taxes or to maintain the upper hand over rival political parties like the Greens and the UKIP in a time of prolonged and increasingly punitive austerity?
  • Australia already introduced similar laws a few weeks ago, despite widespread criticism from around the world. With cricket and rugby now over, is the UK just looking to go one up on Australia in the game of snooping?
Island mentality in the Internet age

Politics aside, what would this mean from a technical perspective? The overwhelming consensus among experts is that secure technology that people use and expect in many other parts of the world, including the US, simply won't be compatible with the products and services that UK residents will be permitted to use. Bigger companies like Google and Apple may be able to offer differentiated versions of their services for the UK but smaller companies or companies who have built their reputation on technical excellence simply won't be able or willing to offer crippled versions of their products with backdoors for the UK. The UK's island geography will become a metaphor for its relationship with the global marketplace.

The first thing to take note of is that encryption and authentication are closely related. Public-key cryptography, for example, simply swaps the public key and private key when being used to authenticate instead of encrypt. An effective and wide-reaching legal ban on encryption would also potentially prohibit the algorithms used for authentication.

Many methods of distributing software, including packages distributed through Linux distributions or apps distributed through the Google Play store are authenticated with such algorithms. This is often referred to as a digital signature. Digital signatures help ensure that software is not corrupted, tampered with by hackers or infected by viruses when it is transmitted and stored in the public Internet.

To correctly implement these mechanisms for installing software safely, every device running an operating system such as Debian, Ubuntu, Fedora or Android needs to include some software modules implementing the algorithms. In Linux, for example, I'm referring to packages like GnuPG, OpenSSL and GnuTLS. Without these components, it would be hard or even impossible for developers in the UK to contribute or publish new versions of their software. Users of the software would not be able to securely receive vital updates to their systems.

An opportunity for free software?

Some people say that any publicity can be good publicity. Now the Government has put the ball into play, people promoting secure solutions based on free software have an opportunity to participate in the debate too.

While laws may or may not change, principles don't. It is a perfect time to remind users that many of the principles of software freedom were written down many years ago, before the opportunity for mass surveillance came into existence. These principles remain relevant to this day. The experts who developed these principles back then are also far more likely to offer insights and trustworthy solutions for the road ahead.

If you'd like to discuss these issues or ask questions, please join the Free-RTC mailing list.

Daniel Pocock: FOSDEM 2016 Real-Time Communications dev-room and lounge

Planet Jabber - 2 November, 2015 - 10:29

FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2016 takes place 30-31 January 2016 in Brussels, Belgium.

This call-for-participation contains information about:

  • Real-Time communications dev-room and lounge,
  • speaking opportunities,
  • volunteering in the dev-room and lounge,
  • related events around FOSDEM, including the XMPP summit,
  • social events (including the Saturday night dinner),
  • the Planet aggregation sites for RTC blogs
Call for participation - Real Time Communications (RTC)

The Real-Time dev-room and Real-Time lounge is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, privacy and encryption. The dev-room is a successor to the previous XMPP and telephony dev-rooms. We are looking for speakers for the dev-room and volunteers and participants for the tables in the Real-Time lounge.

The dev-room is only on Saturday, 30 January 2016 in room K.3.401. The lounge will be present for both days in building K.

To discuss the dev-room and lounge, please join the FSFE-sponsored Free RTC mailing list.

Speaking opportunities

Note: if you used Pentabarf before, please use the same account/username

Main track: the deadline for main track presentations was midnight on 30 October. Leading developers in the Real-Time Communications field are encouraged to consider submitting a presentation to the main track.

Real-Time Communications dev-room: deadline 27 November. Please also use the Pentabarf system to submit a talk proposal for the dev-room. On the "General" tab, please look for the "Track" option and choose "Real-Time devroom".

Other dev-rooms: some speakers may find their topic is in the scope of more than one dev-room. It is permitted to apply to more than one dev-room but please be kind enough to tell us if you do this. See the full list of dev-rooms.

Lightning talks: deadline 27 November. The lightning talks are an excellent opportunity to introduce a wider audience to your project. Given that dev-rooms are becoming increasingly busy, all speakers are encouraged to consider applying for a lightning talk as well as a slot in the dev-room. Pentabarf system to submit a lightning talk proposal. On the "General" tab, please look for the "Track" option and choose "Lightning Talks".

First-time speaking?

FOSDEM dev-rooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the dev-room administrators personally if you would like to ask any questions about it.

Submission guidelines

The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:

  • the purpose of your talk
  • any other talk applications (dev-rooms, lightning talks, main track)
  • availability constraints and special needs

You can use HTML in your bio, abstract and description.

If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes, presentations aimed at developers of free and open source software about RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the dev-room administrators. As the two previous dev-rooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate.

Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used.

For any questions, please join the FSFE-sponsored Free RTC mailing list.

Volunteers needed

To make the dev-room and lounge run successfully, we are looking for volunteers:

  • FOSDEM provides video recording equipment and live streaming, volunteers are needed to assist in this
  • organizing one or more restaurant bookings (dependending upon number of participants) for the evening of Saturday, 30 January
  • participation in the Real-Time lounge
  • helping attract sponsorship funds for the dev-room to pay for the Saturday night dinner and any other expenses
  • circulating this Call for Participation to other mailing lists

FOSDEM is made possible by volunteers and if you have time to contribute, please feel free to get involved.

Related events - XMPP and RTC summits

The XMPP Standards Foundation (XSF) has traditionally held a summit in the days before FOSDEM. There is discussion about a similar summit taking place on 28 and 29 January 2016. Please see the XSF Summit 19 wiki and join the mailing list to discuss.

We are also considering a more general RTC or telephony summit, potentially on 29 January. Please join the Free-RTC mailing list and send an email if you would be interested in participating, sponsoring or hosting such an event.

Social events and dinners

The traditional FOSDEM beer night occurs on Friday, 29 January

On Saturday night, there are usually dinners associated with each of the dev-rooms. Most restaurants in Brussels are not so large so these dinners have space constraints. Please subscribe to the Free-RTC mailing list for further details about the Saturday night dinner options and how you can register for a seat.

Spread the word and discuss

If you know of any mailing lists where this CfP would be relevant, please forward this email. If this dev-room excites you, please blog or microblog about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your blog to the planet site administrators:

Please also link to the Planet sites from your own blog or web site.


For discussion and queries, please subscribe to the Free-RTC mailing list.

The dev-room administration team:

ProcessOne: ejabberd 15.10: HTTP upload, metrics and performance

Planet Jabber - 29 October, 2015 - 14:55

This month’s ejabberd release contains brand new features, performance optimisations, bugfixes and many other improvements.

This release includes a brand new module to help with file transfer. In XMPP transferring files between users required users to be online at the same time. It all changed with XEP-0363 and it is now possible to share file using HTTP protocol while doing the signaling over XMPP. Thanks to Holger and Evgeny, we are now pleases to include this feature in ejabberd core, with mod_http_upload.

ejabberd now also include a module to export metrics information about ejabberd behaviour to Grapherl, a tool that was developed during the Google Summer of Code by Vanshdeep Singh. This is only the beginning, as we are planning to both increase the number of metrics and available backends in upcoming releases. As a start, you can now track the traffic (both from clients and between servers), the offline messages and the user registration and account deletion.

We improved the overall performance of ejabberd, thanks to optimisation in the XML parser.

We also improved the documentation to help you set up mod_xmlrpc with OAuth for those who were already using it prior to 15.09 release.

Finally, as usual, we fixed bugs and improved many features across the whole server.

Here is the full list of changes.

Changes Core
  • c2s: Let stop/1 close XEP-0198 sessions
  • c2s: Close socket when waiting for resume
  • s2s: Don’t crash on certificates without extensions
  • xml: Optimizations in memory allocator
  • OAuth: Fix cyrsasl_oauth:mech_new call
  • mod_http_upload: New HTTP File Upload module (XEP-0363)
  • mod_http_upload_quota: New module to support user quotas
  • mod_metrics: New simple metrics module for use with grapherl
  • mod_mam: Advertise XEP-0313 v0.4 support in room disco
  • mod_mam: Avoid MAM dups when routing to multiple resources
  • Make: Pass {C,CPP,LD}FLAGS used in main ./configure to deps
  • Use OTP directory structure for ‘make install’
  • mix.lock should be commited to ensure consistent builds
  • Code cosmetic cleanup
  • Let modules_update_specs report failures
  • Fix problem with –auth
  • Fix unauthenticated calls to commands with policy=user
  • Improve access_commands option backward compatibility
  • ejabberdctl.cfg: New CONTRIB_MODULES_CONF_DIR
  • Be able to merge old style configs with {listen,…}
  • Fix support for macros
  • mod_ping: New option ping_ack_timeout

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

Daniel Pocock: Free Real-Time Communications workshop in Manchester, 2 November

Planet Jabber - 28 October, 2015 - 16:29

Manchester Free Software and MadLab are hosting a workshop on Free and Federated Real-Time Communications with Free Software next Monday night, 2 November from 7pm.

Add this to your calendar (iCalendar link)

Users and developers are invited to come and discover the opportunities for truly free and secure chat, voice and video with WebRTC, mobile VoIP and the free desktop.

This is an interactive workshop with practical, hands-on opportunities to explore this topic, see what works and what doesn't and learn about troubleshooting techniques to help developers like myself improve the software. This is also a great opportunity for any Java developers who would like to get some exposure to the Android platform.

People wishing to fully participate in all the activities are encouraged to bring a laptop with the Wireshark software and Android tools (especially adb, the command line utility) or if you prefer to focus on WebRTC, have the latest version of Firefox and Chrome installed.

If you are keen to run the DruCall module for WebRTC or your own SIP or XMPP server, you can try setting it up as described in the RTC Quick Start Guide and come along to the workshop with any questions you have.

A workshop near you?

Manchester has a history of great technological innovation, including the first stored program computer and it is a real thrill for me to offer this workshop there.

FSFE Manchester ran a workshop evaluating the performance of free software softphones back in 2012.

Over the coming months, I would like to be able to hold further workshops in other locations to get feedback from people who are trying this technology, including the Lumicall app, JSCommunicator and DruCall. If you are interested in helping organize such an event or you have any other feedback about this topic, please come and discuss it on the Free RTC mailing list.

ProcessOne: ejabberd Saas Console: Introducing Delegation and Permission System

Planet Jabber - 28 October, 2015 - 10:42

We just release a new feature on our ejabberd SaaS Console

Server owners can now invite their co-workers and give them access to some parts of their dashboard.

To do so, from the dashboard root, choose Permission tab. By the way, you can notice that dashboard root changed. It is not your own server page status anymore but the list of all servers you have access to : your own one and those that some people may have shared with you as we will see further.

The new permission system is based on Group. You can associate a user (using his/her email address) to one or many groups and you can define one or more permissions on each group.

Here we will add a new DevOps Group to existing Admin and Dev Group

Then we will allow users from Admin Group to have access to status, documentation and metrics of our “another” server. For DevOps Group, we will only allow server status access. At any time, you can remove any permission to a group, just edit them by clicking again on Authorize.

To add a user to a Group, just click on “User list” and fill the form. Here we will add a new admin user to Admin Group and a new devops user to DevOps Group

Now, if we sign in using recently invited admin account, we will a see “another” server and the three links : Metrics, Status and Documentation.

But as Devops user, we will only see Status link for “another” server and “test” server that some other account will have shared (status only) with us.

Happy sharing and collaboration on your ejabberd server.

ProcessOne: New talk added to Advanced Erlang ejabberd Workshop

Planet Jabber - 26 October, 2015 - 20:56

You may remember the Advanced Erlang Initiative. You may also remember that back in August we announced an Advanced Erlang ejabberd Workshop that will take place on the 17th of November 2015 in Paris.

Today we have more good news. We have just updated the ejabberd November workshop schedule with a new talk by Thomas Arts that will cover Property-based testing of XMPP and how to generate your tests automatically.

Thomas was a researcher at Ericsson, and then a professor at Chalmers University, before co-founding Quviq. As a researcher in Ericsson’s Computer Science Laboratory he worked on software verification tools for Erlang. This provided a natural transition to working with advanced testing technology at Quviq, where Thomas is CTO. Thomas manages the research and development of QuickCheck, a tool for automatic test case generation from properties of a system.

On the Advanced Erlang website you can see the schedule and register for the workshop.

Jérôme Poisson: Want a decentralized, encrypted, Free (as in freedom) “social” app on Android and desktop ?

Planet Jabber - 26 October, 2015 - 14:54
 We have just launched a crowdfunding campaign to develop a new frontend to Libervia, and port it to Android (in a native application!). (subtitles available in many languages). If the campaign is successful, we'll have a unique tool. Here are only a few features managed by Libervia: 
  • blogging/microblogging: we have a decentralized blogging engine based on XMPP, no need to create an account/validate an email to post a comment
  • instant messaging, single or multi-user, with a lot of features
  • end to end encryption: we already manage OTR for single chat, there is a good probability that we also implement OMEMO/Axolotl
  • file sharing: being file uploading or P2P transfer
  • group permissions: similarly to what others call “circle” or “aspect”, you can share with only your friends or your family
  • a lot more, check (and don't miss the experimental ones)
In addition we are a non-profit association focusing on ethic, we want to make a good tool, not a place for advertisements! So if you are looking for next-gen communication tool, please support us and share the link: Thanks !

Peter Saint-Andre: Anti-Politics

Planet Jabber - 25 October, 2015 - 00:00
With just over a year until the election of the 44th person who will preside over the affairs of the U.S. governmment, we have entered again the silly season of American politics. Although I pay as little attention to this circus as possible, at times it can be hard to ignore. Yet it is eminently worth ignoring, despite all the forces and voices that hector me from all sides. First, my vote (if I even cast one) has no bearing on the outcome. Second, democracy in America is actually an oligarchy, as all elective democracies are (there's a good reason why the ancient Greeks favored sortition over election as a method for choosing those who would exercise power). Third, the purpose of our modern two-party state is for the elites to divide and conquer the people through a particularly insidious application of in-group/out-group psychology. Fourth, just about everything in life - friends, family, work, community, science, technology, the arts, the environment, ideas, values, the conduct of life - is more important than mere politics, and it's always best to focus on what is more important at the expense of what is less important.

Daniel Pocock: New planet sites for SIP

Planet Jabber - 22 October, 2015 - 20:39

I've started syndicating some SIP-related blogs at (English) and (Spanish).

If anybody would like to have their blog added or suggest other blogs that deserve recognition, please email me. If a blog is not entirely dedicated to SIP, it is better to use a tag or category with a dedicated RSS feed URL for SIP articles.

Articles related to Asterisk, FreeSWITCH, SIP proxies and softphones are all welcome.

Please also remember to create links to the planet sites from your own blogs and web sites, it helps solutions based on free software to become more prominent online.

Streamlining planet-site management

I'm also looking for feedback about how to streamline management of the planet sites, maybe providing a self-service portal or letting people add themselves with Github pull requests. Has anybody else seen solutions for this?

Daniel Pocock: A mission statement for free real-time communications

Planet Jabber - 21 October, 2015 - 17:51

At FOSDEM 2013, the RTC panel in the main track used the tag line "Can we finally replace Skype, Viber, Twitter and Facebook?"

Does replacing something else have the right ring to it though? Or does such a goal create a negative impression? Even worse, does the term Skype replacement fall short of being a mission statement that gives people direction and sets expectations of what we would actually like to replace it with?

Towards a clearer definition

Lets consider what a positive statement might look like:

Making it as easy as possible to make calls to other people and to receive calls from other people for somebody who chooses only to use genuinely Free Software, open standards, a free choice of service providers and a credible standard of privacy.

If you agree with this or if you feel you can propose a more precise statement, please come and share your thoughts on the Free RTC email list.

The value of a mission statement should not be underestimated. With the right mission statement, it should be possible to envision what the future will look like if we succeed and also if we don't. With the vision of success in mind, it should be easier for developers and the wider free software community to identify the steps that must be taken to make progress.

Fanout Blog: Pushpin and RethinkDB meetup video

Planet Jabber - 21 October, 2015 - 03:40
A few months ago I presented at the RethinkDB meetup on the topic of building realtime APIs. Fortunately the talk was recorded and the video is below. Enjoy!

Tigase Blog: Tigase JaXMPP 3.0.1 Maintenance Release

Planet Jabber - 19 October, 2015 - 19:56

Tigase JaXMPP 3.0.1 Client Library has been released! This is a maintenance release and includes numerous bug fixes. Binaries are available from the project's files section.

ProcessOne: XMPP Academy #2: November 4th

Planet Jabber - 19 October, 2015 - 08:59

Our second session of XMPP Academy is scheduled for the 4th of November. The goal of the XMPP Academy is to help developers get the big picture and get XMPP architecture and design tips from 15-years-experience XMPP experts.

We are targeting all XMPP developers interested in asking questions on specific XMPP topics. Selected questions will be answered during a live private session for our ejabberd SaaS customers. The recording will be available to anyone to see later on-demand on ProcessOne videos channel.

Our second session will takes place on November 4th at 6pm CET. If you are an ejabberd SaaS customer, you can save the date, as you will soon receive a free registration link to attend live.

For other XMPP developers, you are very welcome to send us your questions before November 3rd through our contact form. We will select the most interesting topics / questions to reply to.

We are waiting for your input !

In the meantime, you can catch up on the first XMPP Academy session: ProcessOne XMPP Academy #1 Video and Slides.

Tigase Blog: XMPP An Introduction Part IV - Could you…?

Planet Jabber - 17 October, 2015 - 02:39
Next we dive into IQ stanzas to see how they tick.


Planet Jabber - 16 October, 2015 - 15:55

.IM top-level domain Domain Name System Security Extensions Look-aside Validation DNS-based Authentication of Named Entities Extensible Messaging and Presence Protocol TLSA ("TLSA" does not stand for anything; it is just the name of the RRtype) resource record.

Okay, seriously: this post is about securing an XMPP server running on an .IM domain with DNSSEC, using as a real-life example. In the world of HTTP there is HPKP, and browsers come with a long list of pre-pinned site certificates for the who's'who of the modern web. For XMPP, DNSSEC is the only viable way to extend the broken Root CA trust model with a slightly-less-broken hierarchical trust model from DNS (there is also TACK, which is impossible to deploy because it modifies the TLS protocol, and also unmaintained).

Because the .IM TLD is not DNSSEC-signed yet, we will need to use DLV (DNSSEC Look-aside Validation), an additional DNSSEC trust root operated by the ISC (until the end of 2016). Furthermore, we will need to set up the correct entries for (the XMPP service domain), (the conference domain) and (the actual server running the service).

This post has been sitting in the drafts folder for a while, but now that DANE-SRV has been promoted to Proposed Standard, it was a good time to finalize the article.


Our (real-life) scenario is as follows: the XMPP service is run on a server named (for historical reasons, the host is a web server forwarding to, not the actual XMPP server). The service furthermore hosts the conference service, which needs to be accessible from other XMPP servers as well.

In the following, we will create SRV DNS records to advertise the server name, obtain a TLS certificate, configure DNSSEC on both domains and create (signed) DANE records that define which certificate a client can expect when connecting.

Once this is deployed, state-level attackers will not be able to MitM users of the service simply by issuing rogue certificates, they would also have to compromise the DNSSEC chain of trust (in our case one of the following: ICANN/VeriSign, DLV, PIR or the registrar/NS hosting our domains, essentially limiting the number of states able to pull this off to one).

Creating SRV Records for XMPP

The service / server separation is made possible with the SRV record in DNS, which is a more generic variant of records like MX (e-mail server) or NS (domain name server) and defines which server is responsible for a given service on a given domain.

For XMPP, we create the following three SRV records to allow clients (_xmpp-client._tcp), servers (_xmpp-server._tcp) and conference participants (_xmpp-server._tcp on to connect to the right server: IN SRV 5 1 5222 IN SRV 5 1 5269 IN SRV 5 1 5269

The record syntax is: priority (5), weight (1), port (5222 for clients, 5269 for servers) and host ( Priority and weight are used for load-balancing multiple servers, which we are not using.

Attention: some clients (or their respective DNS resolvers, often hidden in outdated, cheap, plastic junk routers provided by your "broadband" ISP) fail to resolve SRV records, and thus fall back to the A record. If you set up a new XMPP server, you will slightly improve your availability by ensuring that the A record ( in our case) points to the XMPP server as well. However, DNSSEC will be even more of a challenge for them, so lets write them off for now.

Obtaining a TLS Certificate for XMPP

While DANE allows rolling out self-signed certificates, our goal is to stay compatible with clients and servers that do not deploy DNSSEC yet. Therefore, we need a certificate issued by a trustworthy member of the Certificate Extorion ring. Currently, StartSSL and WoSign offer free certificates, and Let's Encrypt is about to launch.

Both StartSSL and WoSign offer a convenient function to generate your keypair. DO NOT USE THAT! Create your own keypair! This "feature" will allow the CA to decrypt your traffic (unless all your clients deploy PFS, which they don't) and only makes sense if the CA is operated by an Intelligence Agency.

What You Ask For...

The certificate we are about to obtain must be somehow tied to our XMPP service. We have three different names (, and and the obvious question is: which one should be entered into the certificate request.

Fortunately, this is easy to find out, as it is well-defined in the XMPP Core specification, section 13.7:

In a PKIX certificate to be presented by an XMPP server (i.e., a "server certificate"), the certificate SHOULD include one or more XMPP addresses (i.e., domainparts) associated with XMPP services hosted at the server. The rules and guidelines defined in [TLS‑CERTS] apply to XMPP server certificates, with the following XMPP-specific considerations:

  • Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP client and server software implementations. Certification authorities that issue XMPP-specific certificates MUST support the DNS-ID identifier type. XMPP service providers SHOULD include the DNS-ID identifier type in certificate requests.

  • Support for the SRV-ID identifier type [PKIX‑SRV] is REQUIRED for XMPP client and server software implementations (for verification purposes XMPP client implementations need to support only the "_xmpp-client" service type, whereas XMPP server implementations need to support both the "_xmpp-client" and "_xmpp-server" service types). Certification authorities that issue XMPP-specific certificates SHOULD support the SRV-ID identifier type. XMPP service providers SHOULD include the SRV-ID identifier type in certificate requests.

  • [...]

Translated into English, our certificate SHOULD contain and according to [TLS-CERTS], which is "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", or for short RFC 6125. There, section 2.1 defines that there is the CN-ID (Common Name, which used to be the only entry identifying a certificate), one or more DNS-IDs (baseline entries usable for any services) and one or more SRV-IDs (service-specific entries, e.g. for XMPP). DNS-IDs and SRV-IDs are stored in the certificate as subject alternative names (SAN).

Following the above XMPP Core quote, a CA must add a DNS-ID and should add an SRV-ID field to the certificate. Clients and servers must support both field types. The SRV-ID is constructed according to RFC 4985, section 2, where it is called SRVName:

The SRVName, if present, MUST contain a service name and a domain name in the following form:


For our XMPP scenario, we would need three SRV-IDs ( for clients, for servers, and for the conference service; all without the _tcp. part we had in the SRV record). In addition, the two DNS-IDs and are required by the specification, allowing the certificate to be (ab)used for HTTPS as well.

And then there is one more thing. RFC 7673 proposes also checking the certificate for the SRV destination ( in our case) if the SRV record was properly validated, there is no associated TLSA record, and the application user was born under the Virgo zodiac sign.

Summarizing the different possible entries in our certificate, we get the following picture:

Name(s) Field Type Meaning or Common Name (CN) Legacy name for really old clients and servers. DNS-IDs (SAN) Required entry telling us that the host serves anything on the two domain names. SRV-IDs (SAN) Optional entry telling us that the host serves XMPP to clients and servers. SRV-ID (SAN) Optional entry telling us that the host serves XMPP to servers for DNS-ID or CN Optional entry if you can configure a DNSSEC-signed SRV record but not a TLSA record. ...and What You Actually Get

Most CAs have no way to define special field types. You provide a list of service/host names, the first one is set as the CN, and all of them are stored as DNS-ID SANs. However, StartSSL offers "XMPP Certificates", which look like they might do what we want above. Let's request one from them for and and see what we got:

openssl x509 -noout -text -in yaxim.crt [...] Subject: description=mjp74P5w0cpIUITY, C=DE, X509v3 Subject Alternative Name:,, othername:<unsupported>, othername:<unsupported>, othername:<unsupported>, othername:<unsupported>

So it's othername:<unsupported>, then? Thank you OpenSSL, for your openness! From RFC 4985 we know that "othername" is the basic type of the SRV-ID SAN, so it looks like we got something more or less correct. Using this script (highlighted source, thanks Zash), we can further analyze what we've got:

Extensions: X509v3 Subject Alternative Name: sRVName:, xmppAddr:, dNSName:,

Alright, the two service names we submitted turned out under three different field types:

  • SRV-ID (it's mising the _xmpp-client. / _xmpp-server. part and is thus invalid)
  • xmppAddr (this was the correct entry type in the deprecated RFC 3920 XMPP specification, but is now only allowed in client certificates)
  • DNS-ID (wow, these ones happen to be correct!)

While this is not quite what we wanted, it is sufficient to allow a correctly implemented client to connect to our server, without raising certificate errors.

Configuring DNSSEC for Your Domain(s)

In the next step, the domain (in our case both and, but the following examples will only list needs to be signed with DNSSEC. Because I'm a lazy guy, I'm using BIND 9.9, which does inline-signing (all I need to do is create some keys and enable the feature).

Key Creation with BIND 9.9

For each domain, a zone signing key (ZSK) is needed to sign the individual records. Furthermore, a key signing key (KSK) should be created to sign the ZSK. This allows you to rotate the ZSK as often as you wish.

# create key directory mkdir /etc/bind/keys cd /etc/bind/keys # create key signing key dnssec-keygen -f KSK -3 -a RSASHA256 -b 2048 # create zone signing key dnssec-keygen -3 -a RSASHA256 -b 2048 # make all keys readable by BIND chown -R bind.bind .

To enable it, you need to configure the key directory, inline signing and automatic re-signing:

zone "" { ... key-directory "/etc/bind/keys"; inline-signing yes; auto-dnssec maintain; };

After reloading the config, the keys need to be enabled in BIND:

# load keys and check if they are enabled $ rndc loadkeys $ rndc signing -list Done signing with key 17389/RSASHA256 Done signing with key 24870/RSASHA256

The above steps need to be performed for as well.

NSEC3 Against Zone Walking

Finally, we also want to enable NSEC3 to prevent curious people from "walking the zone", i.e. retrieving a full list of all host names under our domains. To accomplish that, we need to specify some parameters for hashing names. These parameters will be published in an NSEC3PARAMS record, which resolvers can use to apply the same hashing mechanism as we do.

First, the hash function to be used. RFC 5155, section 4.1 tells us that...

"The acceptable values are the same as the corresponding field in the NSEC3 RR."

NSEC3 is also defined in RFC 5155, albeit in section 3.1.1. There, we learn that...

"The values for this field are defined in the NSEC3 hash algorithm registry defined in Section 11."

It's right there... at the end of the section:

Finally, this document creates a new IANA registry for NSEC3 hash algorithms. This registry is named "DNSSEC NSEC3 Hash Algorithms". The initial contents of this registry are:

0 is Reserved.

1 is SHA-1.

2-255 Available for assignment.

Let's pick 1 from this plethora of choices, then.

The second parameter is "Flags", which is also defined in Section 11, and must be 0 for now (other values have to be defined yet).

The third parameter is the number of iterations for the hash function. For a 2048 bit key, it MUST NOT exceed 500. Bind defaults to 10, Strotman references 330 from RFC 4641bis, but it seems that number was removed since then. We take this number anyway.

The last parameter is a salt for the hash function (a random hexadecimal string, we use 8 bytes). You should not copy the value from another domain to prevent rainbow attacks, but there is no need to make this very secret.

$ rndc signing -nsec3param 1 0 330 $(head -c 8 /dev/random|hexdump -e '"%02x"') $ rndc signing -nsec3param 1 0 330 $(head -c 8 /dev/random|hexdump -e '"%02x"')

Whenever you update the NSEC3PARAM value, your zone will be re-signed and re-published. That means you can change the iteration count and salt value later on, if the need should arise.

Configuring the DS (Delegation Signer) Record for

If your domain is on an already-signed TLD (like on .org), you need to establish a trust link from the .org zone to your domain's signature keys (the KSK, to be precise). For this purpose, the delegation signer (DS) record type has been created.

A DS record is a signed record in the parent domain (.org) that identifies a valid key for a given sub-domain ( Multiple DS records can coexist to allow key rollover. If you are running an important service, you should create a second KSK, store it in a safe place, and add its DS in addition to the currently used one. Should your primary name server go up in flames, you can recover without waiting for the domain registrar to update your records.

Exporting the DS Record

To obtain the DS record, BIND comes with the dnssec-dsfromkey tool. Just pipe all your keys into it, and it will output DS records for the KSKs. We do not want SHA-1 records any more, so we pass -2 as well to get the SHA-256 record:

$ dig @ DNSKEY | dnssec-dsfromkey -f - -2 IN DS 42199 8 2 35E4E171FC21C6637A39EBAF0B2E6C0A3FE92E3D2C983281649D9F4AE3A42533

This line is what you need to submit to your domain registrar (using their web interface or by means of a support ticket). The information contained is:

  • key tag: 42199 (this is just a numeric ID for the key, useful for key rollovers)
  • signature algorithm: 8 (RSA / SHA-256)
  • DS digest type: 2 (SHA-256)
  • hash value: 35E4E171...E3A42533

However, some registrars insist on creating the DS record themselves, and require you to send in your DNSKEY. We only need to give them the KSK (type 257), so we filter the output accordingly:

$ dig @ DNSKEY | grep 257 86400 IN DNSKEY 257 3 8 AwEAAcDCzsLhZT849AaG6gbFzFidUyudYyq6NHHbScMl+PPfudz5pCBt G2AnDoqaW88TiI9c92x5f+u9Yx0fCiHYveN8XE2ed/IQB3nBW9VHiGQC CliM0yDxCPyuffSN6uJNVHPEtpbI4Kk+DTcweTI/+mtTD+sC+w/CST/V NFc5hV805bJiZy26iJtchuA9Bx9GzB2gkrdWFKxbjwKLF+er2Yr5wHhS Ttmvntyokio+cVgD1UaNKcewnaLS1jDouJ9Gy2OJFAHJoKvOl6zaIJuX mthCvmohlsR46Sp371oS79zrXF3LWc2zN67T0fc65uaMPkeIsoYhbsfS /aijJhguS/s= Validation of the Trust Chain

As soon as the record is updated, you can check the trustworthiness of your domain. Unfortunately, all of the available command-line tools suck. One of the least-sucking ones is drill from ldns. It still needs a root.key file that contains the officially trusted DNSSEC key for the . (root) domain. In Debian, the dns-root-data package places it under /usr/share/dns/root.key. Let's drill our domain name with DNSSEC (-D), tracing from the root zone (-T), quietly (-Q):

$ drill -DTQ -k /usr/share/dns/root.key ;; Number of trusted keys: 1 ;; Domain: . [T] . 172800 IN DNSKEY 256 3 8 ;{id = 48613 (zsk), size = 1024b} . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} [T] org. 86400 IN DS 21366 7 1 e6c1716cfb6bdc84e84ce1ab5510dac69173b5b2 org. 86400 IN DS 21366 7 2 96eeb2ffd9b00cd4694e78278b5efdab0a80446567b69f634da078f0d90f01ba ;; Domain: org. [T] org. 900 IN DNSKEY 257 3 7 ;{id = 9795 (ksk), size = 2048b} org. 900 IN DNSKEY 256 3 7 ;{id = 56198 (zsk), size = 1024b} org. 900 IN DNSKEY 256 3 7 ;{id = 34023 (zsk), size = 1024b} org. 900 IN DNSKEY 257 3 7 ;{id = 21366 (ksk), size = 2048b} [T] 86400 IN DS 42199 8 2 35e4e171fc21c6637a39ebaf0b2e6c0a3fe92e3d2c983281649d9f4ae3a42533 ;; Domain: [T] 86400 IN DNSKEY 257 3 8 ;{id = 42199 (ksk), size = 2048b} 86400 IN DNSKEY 256 3 8 ;{id = 6384 (zsk), size = 2048b} [T] 3600 IN A ;;[S] self sig OK; [B] bogus; [T] trusted

The above output traces from the initially trusted . key to org, then to and determines that is properly DNSSEC-signed and therefore trusted ([T]). This is already a big step, but the tool lacks some color, and it does not allow to explicitly query the domain's name servers (unless they are open resolvers), so you can't test your config prior to going live.

To get a better view of our DNSSEC situation, we can query some online services:

Ironically, neither DNSViz nor Verisign support encrypted connections via HTTPS, and Lutz' livetest is using an untrusted root.

Enabling DNSSEC Look-aside Validation for

Unfortunately, we can not do the same with our short and shiny domain. If we try to drill it, we get the following:

$ drill -DTQ -k /usr/share/dns/root.key ;; Number of trusted keys: 1 ;; Domain: . [T] . 172800 IN DNSKEY 256 3 8 ;{id = 48613 (zsk), size = 1024b} . 172800 IN DNSKEY 257 3 8 ;{id = 19036 (ksk), size = 2048b} [T] Existence denied: im. DS ;; Domain: im. ;; No DNSKEY record found for im. ;; No DS for;; Domain: [S] 86400 IN DNSKEY 257 3 8 ;{id = 17389 (ksk), size = 2048b} 86400 IN DNSKEY 256 3 8 ;{id = 24870 (zsk), size = 2048b} [S] 3600 IN A ;;[S] self sig OK; [B] bogus; [T] trusted

There are two pieces of relevant information here:

  • [T] Existence denied: im. DS - the top-level zone assures that .IM is not DNSSEC-signed (it has no DS record).
  • [S] 3600 IN A - is self-signed, providing no way to check its authenticity.

The .IM top-level domain for Isle of Man is operated by Domicilium. A friendly support request reveals the following:

Unfortunately there is no ETA for DNSSEC support at this time.

That means there is no way to create a chain of trust from the root zone to

Fortunately, the desingers of DNSSEC anticipated this problem. To accelerate adoption of DNSSEC by second-level domains, the concept of look-aside validation was introduced in 2006. It allows to use an alternative trust root if the hierarchical chaining is not possible. The ISC is even operating such an alternative trust root. All we need to do is to register our domain with them, and add them to our resolvers (because they aren't added by default).

After registering with DLV, we are asked to add our domain with its respective KSK domain key entry. To prove domain and key ownership, we must further create a signed TXT record under with a specific value: IN TXT "DLV:1:fcvnnskwirut"

Afterwards, we request DLV to check our domain. It queries all of the domains' DNS servers for the relevant information and compares the results. Unfortunately, our domain fails the check:

FAILURE has extra: 86400 IN DNSKEY 256 3 RSASHA256 ( AwEAAepYQ66j42jjNHN50gUldFSZEfShF... FAILURE has extra: 86400 IN DNSKEY 257 3 RSASHA256 ( AwEAAcB7Fx3T/byAWrKVzmivuH1bpP5Jx... FAILURE missing: YAX.IM. 86400 IN DNSKEY 256 3 RSASHA256 ( AwEAAepYQ66j42jjNHN50gUldFSZEfShF... FAILURE missing: YAX.IM. 86400 IN DNSKEY 257 3 RSASHA256 ( AwEAAcB7Fx3T/byAWrKVzmivuH1bpP5Jx... FAILURE This means your DNS servers are out of sync. Either wait until the DNSKEY data is the same, or fix your server's contents.

This looks like a combination of two different issues:

  1. A part of our name servers is returning YAX.IM when asked for
  2. The DLV script is case-sensitive when it comes to domains.

Problem #1 is officially not a problem. DNS is case-insensitive, and therefore all clients that fail to accept YAX.IM answers to requests are broken. In practice, this hits not only the DLV resolver (problem #2), but also the resolver code in Erlang, which is used in the widely-deployed ejabberd XMPP server.

While we can't fix all the broken servers out there, #2 has been reported and fixed, and hopefully the fix has been rolled out to production already. Still, issue #1 needs to be solved.

It turns out that it is caused by case insensitive response compression. You can't make this stuff up! Fortunately, BIND 9.9.6 added the no-case-compress ACL, so "all you need to do" is to upgrade BIND and enable that shiny new feature.

After checking and re-checking the TXT record with DLV, there is finally progress:

SUCCESS DNSKEY signatures validated. ... SUCCESS COOKIE: Good signature on TXT response from <NS IP> SUCCESS <NS IP> has authentication cookie DLV:1:fcvnnskwirut ... FINAL_SUCCESS Success.

After your domain got validated, it will receive its look-aside validation records under

$ dig +noall +answer DLV 3451 IN DLV 17389 8 2 C41AFEB57D71C5DB157BBA5CB7212807AB2CEE562356E9F4EF4EACC2 C4E69578 3451 IN DLV 17389 8 1 8BA3751D202EF8EE9CE2005FAF159031C5CAB68A

This looks like a real success. Except that nobody is using DLV in their resolvers by default, and DLV will stop operations in 2017.

Until then, you can enable look-aside validation in your BIND and Unbound resolvers.

Lutz' livetest service supports checking DLV-backed domains as well, so let's verify our configuration:

Creating TLSA Records for HTTP and SRV

Now that we have created keys, signed our zones and established trust into them from the root (more or less), we can put more sensitive information into DNS, and our users can verify that it was actually added by us (or one of at most two or three governments: the US, the TLD holder, and where your nameservers are hosted).

This allows us to add a second, independent, trust root to the TLS certificates we use for our web server ( as well as for our XMPP server, by means of TLSA records.

These record types are defined in RFC 6698 and consist of the following pieces of information:

  • domain name (i.e.
  • certificate usage (is it a CA or a server certificate, is it signed by a "trusted" Root CA?)
  • selector + matching type + certificate association data (the actual certificate reference, encoded in one of multiple possible forms)
Domain Name

The domain name is the hostname in the case of HTTPS, but it's slightly more complicated for the XMPP SRV record, because there we have the service domain (, the conference domain ( and the actual server domain name (

The behavior for SRV TLSA handling is defined in RFC 7673, published as Proposed Standard in October 2015. First, the client must validate that the SRV response for the service domain is properly DNSSEC-signed. Only then the client can trust that the server named in the SRV record is actually responsible for the service.

In the next step, the client must ensure that the address response (A for IPv4 and AAAA for IPv6) is DNSSEC-signed as well, or fall back to the next SRV record.

If both the SRV and the A/AAAA records are properly signed, the client must do a TLSA lookup for the SRV target (which is for our client users, or for other XMPP servers connecting to us).

Certificate Usage

The certificate usage field can take one of four possible values. Translated into English, the possibilities are:

  1. "trusted" CA - the provided cert is a CA cert that is trusted by the client, and the server certificate must be signed by this CA. We could use this to indicate that our server only will use StartSSL-issued certificates.
  2. "trusted" server certificate - the provided cert corresponds to the certificate returned over TLS und must be signed by a trusted Root CA. We will use this to deliver our server certificate.
  3. "untrusted" CA - the provided CA certificate must be the one used to sign the server's certificate. We could roll out a private CA and use this type, but it would cause issues with non-DNSSEC clients.
  4. "untrusted" server certificate - the provided certificate must be the same as returned by the server, and no Root CA trust checks shall be performed.
The Actual Certificate Association

Now that we know the server name for which the certificate is valid and the type of certificate and trust checks to perform, we need to store the actual certificate reference. Three fields are used to encode the certificate reference.

The selector defines whether the full certificate (0) or only the SubjectPublicKeyInfo field (1) is referenced. The latter allows to get the server key re-signed by a different CA without changing the TLSA records. The former could be theoretically used to put the full certificate into DNS (a rather bad idea for TLS, but might be interesting for S/MIME certs).

The matching type field defines how the "selected" data (certificate or SubjectPublicKeyInfo) is stored:

  1. exact match of the whole "selected" data
  2. SHA-256 hash of the "selected" data
  3. SHA-512 hash of the "selected" data

Finally, the certificate association data is the certificate/SubjectPublicKeyInfo data or hash, as described by the previous fields.

Putting it all Together

A good configuration for our service is a record based on a CA-issued server certificate (certificate usage 1), with the full certificate (selector 0) hashed via SHA-256 (matching type 0). We can obtain the required association data using OpenSSL command line tools:

openssl x509 -in -outform DER | openssl sha256 (stdin)= bbcc3ca09abfc28beb4288c41f4703a74a8f375a6621b55712600335257b09a9

Taken together, this results in the following entries for HTTPS on and IN TLSA 1 0 1 bbcc3ca09abfc28beb4288c41f4703a74a8f375a6621b55712600335257b09a9 IN TLSA 1 0 1 bbcc3ca09abfc28beb4288c41f4703a74a8f375a6621b55712600335257b09a9

This is also the SHA-256 fingerprint you can see in your web browser.

For the XMPP part, we need to add TLSA records for the SRV targets ( for clients and for servers). There should be no need to make TLSA records for the service domain (, because a modern client will always try to resolve SRV records, and no DNSSEC validation will be possible if that fails.

Here, we take the SHA-256 sum of the certificate we obtained from StartSSL, and create two records with the same type and format as above: IN TLSA 1 0 1 cef7f6418b7d6c8e71a2413f302f92fc97e57ec18b36f97a4493964564c84836 IN TLSA 1 0 1 cef7f6418b7d6c8e71a2413f302f92fc97e57ec18b36f97a4493964564c84836

These fields will be used by DNSSEC-enabled clients to verify the TLS certificate presented by our XMPP service.

Replacing the Server Certificate

Now that the TLSA records are in place, it is not as easy to replace your server certificate as it was before, because the old one is now anchored in DNS.

You need to perform the following steps in order to ensure that all clients will be able to connect at any time:

  1. Obtain the new certificate
  2. Create a second set of TLSA records, for the new certificate (keep the old one in place)
  3. Wait for the configured DNS time-to-live to ensure that all users have received both sets of TLSA records
  4. Replace the old certificate on the server with the new one
  5. Remove the old TLSA records

If you fail to add the TLSA records and wait the DNS TTL, some clients will have cached a copy of only the old TLSA records, so they will reject your new server certificate.


DANE for XMPP is a chicken-and-egg problem. As long as there are no servers, it will not be implemented in the clients, and vice versa. However, the (currently unavailable) XMPP security analyzer is checking the DANE validation status, and GSoC 2015 brought us DNSSEC support in minidns, which soon will be leveraged in Smack-based XMPP clients.

With this (rather long) post covering all the steps of a successful DNSSEC implementation, including the special challenges of .IM domains, I hope to pave the way for more XMPP server operators to follow.

Enabling DNSSEC and DANE provides an improvement over the rather broken Root CA trust model, however it is not without controversy. tptacek makes strong arguments against DNSSEC, because it is using outdated crypto and because it doesn't completely solve the government-level MitM problem. Unfortunately, his proposal to "do nothing" will not improve the situation, and the only positive contribution ("use TACK!") has expired in 2013.

Finally, one last technical issue not covered by this post is periodic key rollover; this will be covered by a separate post eventually.

Comments on HN

Peter Saint-Andre: Minerval Arts

Planet Jabber - 16 October, 2015 - 00:00
More and more I am struck by an essential similarity in the aims of various philosophies and religions: through reason and reflection to place some distance between impulse and action. These schools have different techniques, but there is a family resemblance among them; they are like an intellectual analogue of the martial arts (the arts of Mars, the Roman god of war - we could say that philosophies are the arts of Minerva, goddess of wisdom). Just as someone who has earned a black belt in, say, aikido starts over as a white belt in jiu-jitsu, so a master of, say, Taoism would start over as a beginner in Stoicism. My lifelong philosophy project is in large measure an exploration of the methods that six secular thinkers (Rand, Nietzsche, Aristotle, Thoreau, Epicurus, and Lao Tzu) have devised to help individuals achieve the goals of self-discipline and self-mastery. Unfortunately, we have lost the ancient conception of philosophy as the love and practice of wisdom. Thus (with the possible exception of Taoism) we don't have schools, communities, and traditions of the minerval arts, in which their lessons are passed down, shared, and applied among friends and associates who share a common outlook on life. This lack of historical continuity with the original meaning of philosophy makes it even harder than it already is to live a life of continual self-examination and self-improvement. Hopefully I'm doing my share to make that great task a bit easier...

Peter Saint-Andre: RFC 7673: DNSSEC, DANE, and SRV

Planet Jabber - 14 October, 2015 - 00:00
Traditionally, connections to Internet services such as websites are secured using SSL/TLS with digital certificates issued by third-party certification authorities. Because this dependency on CAs isn't always a good thing (can you say Diginotar?), building atop DNSSEC some smart folks at the IETF designed DANE as a way for application service providers to specify their own keying material. This works just fine for protocols like HTTP in which a client to look up a server "directly" using DNS A or AAAA records. However, it doesn't work for protocols like IMAP or XMPP in which a client uses DNS SRV records to find the server to which it will ultimately connect. Because we care about this scenario in the Jabber/XMPP community, Matt Miller and I volunteered to help Tony Finch finish his initial work to fill this gap. The resulting document was published today as RFC 7673. Security FTW!

ProcessOne: My GSoC 2015 project: push for XMPP

Planet Jabber - 12 October, 2015 - 15:23
This is a guest post by Christian Ulrich, the author of mod_push and oshiya, an XEP-0357 compatible XMPP component. Christian is the first guest author on ProcessOne Blog. Starting with his article, we would like to open our blog to anyone who wants to share an interesting original post related to XMPP. If you are up for the challenge, please contact us.

The Google Summer of Code is over and this is my attempt to explain what my project was about, what I implemented and what is still to be done. This article is meant to be an introduction to the push topic for people who know some basics about XMPP. If you know that it’s based on a federated client-server architecture, and heard about pubsub and stream management, you will probably be fine. This is the first part of my summary. I’ll elaborate about technical details in another article. In this part there are some references to technical documents though for those who want to dive deeper.

The problem

Most mobile operating systems provide a framework app developers have to use in order to let their apps communicate with the outside. That’s an attempt to save battery by limiting CPU cycles and wireless communication to a minimum. I’ll pick iOS as an example, but all operating systems I looked at follow very similar approaches.

I’ll simplify the situation a little in order to make it clear. An iOS app only runs as long as you look at it. As soon as you switch to another app or turn off the screen the app will be stopped. The OS gives the app the possibility to perform last wish operations though. Once it’s stopped the app can no longer send data or react to incoming data. If the app doesn’t close connections (and it should before it is stopped) those connections are dead and it can take the other side a long time to realize that. The only way for an outside sender to wake up the app and make it responsive again is to send a push notification. Push is a term used by many protocols, but when mobile OS vendors say push they mean a very specific thing: using their proprietary cloud service to send notification packets to users. The mobile OS listens on exactly one connection and will wake up an app when a notification arrives for it. As I said I simplified the situation. There are exceptions to this strict policy. There is background execution on iOS. But in general XMPP apps are not supposed to use that. An app which does not follow this rule might not be allowed into the app store.

XMPP core requires a permanent TCP connection between client and server. If a client closes the connection (or the server realizes the connection is dead) the client is considered offline and the server won’t route packets to it anymore. So mobile XMPP apps cannot receive messages most of the time. This is where XEP-0357 comes into play.

The solution: XEP-0357

XEP-0357 is a standard extension written by Lance Stout which defines a way for XMPP servers to act as a push provider, that is request push notifications at the vendor’s push service if the receiving mobile device has no connection open.

The XEP divides the task of sending push packets into two parts: The XMPP server part and the app server part. The XMPP server’s task is to manage subscriptions of push clients: they can enable/disable push and set some parameters. Requesting push notifications at the vendor’s push service is done by another piece of software which may even run on another machine. It’s called the app server. If an XMPP server receives an XMPP packet for a client that previously enabled push and that client does not have an open TCP connection, the XMPP server sends all the information needed for crafting a push notification to the app server which then crafts and sends a push notification request to the vendor’s push service. To be exact the XEP only specifies the XMPP server part and does not tell what an app server should do (as my project is all about push it’s not hard to guess what my app server implementation does: initiating push notifications, yay!). This indirect approach allows different XMPP servers to use the same app server. Most vendors (that is all except for Ubuntu and Mozilla) even require such a setup. When a push provider wants to send a push notification the vendor’s service asks for authentication credentials. Those credentials are issued by the vendor to the app developer only. Thus all push notifications for a specific app have to be requested by a service the app-developer runs.

One interesting detail which may sound a little complicated at first is how an XMPP server tells an app server to send a push notification: it’s done via Pubsub. There needs to be a pubsub service somewhere where the app server can create nodes and subscribe to them. The XMPP server then publishes the information needed for requesting push notifications at those nodes. It sounds complicated to introduce this extra indirection but on the other hand pubsub is already implemented and (on paper) provides all the features needed for this task. You’ll see in the next chapter that with my ejabberd module it’s possible to run all needed components within one ejabberd instance without much effort.

Let’s look at an example. Our user Alice has an iPhone with an XMPP app called chatninja installed. These are the necessary steps in order to use push:

  1. chatninja registers at the app server run by the developers of chatninja. If Alice had an Ubuntu phone instead she could run her own app server or use that of a friend. In the registration request a token identifying Alice’s iPhone is included. The app server sends back the Jabber ID of a pubsub service, the name of an allocated node on that service and a password.

  2. Chatninja sends an enable request to Alice’s XMPP server including all the information received from the app server (Pubsub JID, node name, password). Optionally it can configure what information shall be included in push notifications. As chatninja is a privacy-aware app, it tells the server to only include the number of new subscription requests and the number of new messages but not the the senders’ Jabber IDs and the message contents.

  3. Alice turns off the screen. Chatninja disconnects from the XMPP server and is stopped by the operating system.

  4. Bob wants to say hello to Alice and sends her a message.

  5. Alice’s XMPP server cannot route Bob’s message directly to her iPhone but instead publishes an item at the pubsub service it was told about. It needs the node name and the password it received earlier for that.

  6. The chatninja app server gets notified about the published item. It crafts a push notification request and sends it to Apple’s push notification service, including the token identifying Alice’s iPhone.

  7. Alice’s iPhone receives the push notification. Chatninja wakes up and connects to the XMPP server to pick up Bob’s message.


In order to understand why I did certain things it’s nice to know my motivation for working on this project. I wanted to provide a missing puzzle piece for seamlessly working instant messaging clients on the different mobile operating systems. As mentioned earlier XEP-0357 only specifies what XMPP servers should do and leaves the app server part to app developers. Lance Stout told me the reason for this: XMPP can be used for many things, not only instant messaging and thus app developers should be able to decide when their apps receive push notifications and when not. That’s not the best foundation for the instant messaging use case because every developer of a messaging app would have to take care of the app server too. That’s why besides the XMPP server part I implemented a generic instant messaging app server as part of mod_push, my ejabberd module. With mod_pubsub and mod_push ejabberd thus can provide an all-in-one solution to the push problem, at least for instant messaging.

As I said earlier Mozilla SimplePush and Ubuntu Push are different than the other services in one aspect. They don’t require per-app authentication. So Ubuntu phone or Firefox OS users can run their own app server. They just need to activate the internal app server in their mod_push configuration. On the other platforms apps have to use an external app server run by the app developer. mod_push allows both setups.

That’s not all. Other XMPP servers like prosody should get invited to the party too. So I started oshiya. Oshiya is an XMPP component which is an app server with the same XMPP interface as mod_push. So clients can choose between ejabberd with mod_push installed or any XMPP server with oshiya connected. Both setups should be compatible. I hope this will help spread push in the XMPP world.

Both mod_push and oshiya will support the same set of push services (for implementation status see the next section). These are:

An important implementation detail is how ejabberd distinguishes between connected and disconnected clients. mod_push uses stream management’s resumption feature for that. Clients are expected to close their connection when they’re about to be stopped. If a client enabled push before, mod_push will initiate push notifications from now on until the client resumes its XMPP stream. Another approach would be to close the XMPP stream completely when the app is stopped. The advantage of my approach is that clients will keep their presence state which is important for MUC rooms for example.

You can find the source code and documentation of both mod_push and oshiya on github.

Up next

Both mod_push and oshiya still require some work. Right now mod_push is the more mature project. It made some modifications of ejabberd necessary which are not yet merged back into master. So running mod_push currently requires my ejabberd branch. Hopefully this will change soon.

oshiya does not support all push services yet (Mozilla SimplePush and WNS are missing). It does not support service discovery yet either. Besides that I will try to build oshiya packages for popular linux distributions soon (help is very welcome) and I’ll write more documentation too.

Last but not least I’ll cooperate with app developers and try and help fixing issues that might come up. I know of some people who are already actively working on mobile XMPP apps supporting push. Of course everyone is invited to try my software and file bug reports.

If you wonder how mobile XMPP’s future will look like you should also have a look at another important project in this year’s GSoC. I’m quite optimistic.

Daniel Pocock: RTC Quick Start becoming a book, now in beta

Planet Jabber - 12 October, 2015 - 10:23

The Real-Time Communications (RTC) Quick Start Guide started off as a web site but has recently undergone bookification.

As of today, I'm calling this a beta release, although RTC is a moving target and even when a 1.0 release is confirmed, the book will continue to evolve.

An important aspect of this work is that the book needs to be freely and conveniently available to maximize participation in Free RTC. (This leads to the question of which free license should I choose?)

The intended audience for this book are people familiar with setting up servers and installing packages, IT managers, system administrators and support staff and product managers.

There are other books that already explain things like how to setup Asterisk. The RTC Quick Start Guide takes a more strategic view. While other books discuss low-level details, like how to write individual entries in the Asterisk extensions.conf file, the RTC Quick Start Guide looks at the high level questions about how to create a network of SIP proxies, XMPP servers and Asterisk boxes and how to modularize configuration and distribute it across these different components so it is easier to manage and support.

Some chapters give very clear solutions, such as DNS setup while other chapters present a discussion of issues that are managed differently in each site, such as user and credential storage.

One of the key themes of the book is the balance between Internet architecture and traditional telephony, with specific recommendations about mixing named user accounts with extension numbers.

Many people have tried SIP or XMPP on Linux in the past and either found themselves overwhelmed by all the options in Asterisk (start with a SIP proxy, it is easier) or struggling with NAT issues (this has improved with the introduction of ICE and TURN, explained in a chapter on optimizing connectivity).

The guide also looks at the next generation of RTC solutions based on WebRTC and gives specific suggestions to people deploying it with JSCommunicator.

Help needed

There are many ways people can help with this effort.

The most important thing is for people to try it out. If you follow the steps in the guide, does it help you reach a working solution? Give feedback on the Free RTC mailing list or raise bug reports against any specific packages if they don't work for you.

The DocBook5 source code of the book is is available on Github and people can submit changes as pull requests. There are various areas where help is needed: improvements to the diagrams, extra diagrams and helping add details to the chapter about phones, apps and softphones.

How could the book be made more useful for specific sectors such as ISPs, hosting providers, the higher education sector or other domains that typically lead in the deployment of new technology?

There is a PDF version of the book for download, it has been created using the default templates and stylesheets. How could the appearance be improved? Should I look at options for having it made available in print?

The book is only available in English at the moment, what is the best strategy for supporting translations and engaging with translators?

Are there specific communities or projects that the book should be aligned with, such as The Linux Documentation Project? (Note: RTC is not just for Linux and people use many of these components on BSD-like platforms, Windows, Mac and Android).

Which is the best license to choose to engage contributors and translators and ensure the long term success of the project?

Another great way to help is to create links to the book from other web sites and documents.

Any questions or feedback on these topics would be very welcome through theFree RTC mailing list.

ProcessOne: Building an XMPP iOS client in Swift 2

Planet Jabber - 9 October, 2015 - 15:00

Following our patch that lead to the release of the updated XMPPFramework CocoaPods, then the Swift demo, we are proud to show you our XMPP Swift wrapper !

The goal was to be able to create a simple yet powerful messaging app, in a record time.

With the power of CocoaPods and our Swift Wrapper, we, and now YOU are able to do so much more when it comes to messaging in Swift.

The code comes with a complete end-to-end tutorial, so you won’t get lost in the making !

The tutorial is extremely comprehensive and covers both the XMPP protocol Layer with XMPPFramework and the chat UI for one-to-one chat thanks to JSQMessagesViewController open source chat user interface library.

You can check it out here.

Distribuir contenido