ChatSecure iOS v3.2.3 - XMPP Push
We’re excited to announce that XMPP push (XEP-0357) is now available, finally allowing users to receive push messages from any contact. This feature is only available when used with compatible XMPP servers, and requires special modules to be enabled for Prosody (
mod_cloud_notify) or ejabberd (
Our next release will focus on OMEMO support for multi-device asynchronous end-to-end encryption, which will provide huge usability gains over OTR on mobile devices. Thankfully the GPL + App Store licensing issues concerning SignalProtocol have been resolved. You can try OMEMO today in other apps such as Conversations, Gajim, and Cryptocat.
- XMPP push for supported servers (XEP-0357)
- Improved subscription requests UI
- Basic vCard nickname support
- Fix issues with missing messages during stale OTR sessions
- Improved IPv6 support for NAT64/DNS64
- Fix some issues with presence/availability
- Added button to view your password
- Fix issue where message view would appear multiple times
- Automatically start OTR sessions when contact is online
- Send error messages back to contact when messages cannot be decrypted
Download on the App Store.
ChatSecure iOS v3.2 - Decentralized Interoperable Push Support
With the release of ChatSecure iOS v3.2, we have enabled the first phase of a new form of push messaging that is decentralized, interoperable, and reduces identifiable metadata. Users of any app compatible with the ChatSecure Push protocol can send push messages across app boundaries, starting with the latest release of ChatSecure iOS and the next version of Zom Messenger. These push messages currently contain no content and are simply a way to wake up the receiving client for ~20 seconds.
Unlike centralized messaging applications like WhatsApp, Signal or Telegram, a core part of our mission is to allow users to connect any XMPP server of their choice and to encourge users to run their own servers. This privacy win also comes with a major drawback for iOS users, because Apple prevents the application from running in the background. The only way push messages can be sent are through servers run by app developers themselves, which presents a problem when trying to support push for any arbitrary XMPP server.
[email protected]) and Bob (
[email protected]) are both using the ChatSecure iOS app to communicate via their private XMPP server
example.com. After each OTR session is established, they each send a payload inside the OTR channel that contains a fresh token and their push API endpoint. The token is used by the API endpoint to lookup your device APNS token, and the endpoint parameter is what allows this to work between apps from different developers. Because all of this data is exchanged by the clients themselves, our push server has no idea about the JIDs of Alice or Bob, or where any of the tokens ended up.
The next time Alice opens the app and she wants to talk to Bob, she sees that Bob is offline.
On the chat screen there is now a new button called Knock that has replaced the Send button when the contact is offline (and no text is entered). By pressing Knock, it looks up the token and endpoint that Bob gave her earlier, and sends a HTTP POST to that endpoint with the token.
About 5 seconds later Bob’s client will wake up in the background and automatically login to his XMPP account.
His device will also receive back the token he gave to Alice, do a local lookup to see that the incoming push is coming from Alice, and show a local notification visibile on the lock screen. We are able to keep the app open for about 20 seconds in the background, which is enough time for Alice to establish a new OTR session and send a few messages.
Improving the UX
Having a Knock button is not the ideal user experience because it’s a foreign UI concept and not immediately clear how it works. Originally we tried to automatically trigger knock messages, but hit issues with missing messages caused by sending messages to offline contacts, or when in a stale OTR session. Our message pipeline needs to be reworked to handle these cases and ensure that no message ever enters a black hole.
There is a relatively new way for XMPP servers to interact with app push gateways called XEP-0357 but not very many servers support this extension right now. Our current solution works immediately with any XMPP server as long as you’re both running a ChatSecure Push compatible client. In the future we will roll out client support for XEP-0357 to allow you to receive pushes from any contact, as long as you’re connected to a compatible XMPP server.
The Road Ahead
Although OTR has proven to be trustworthy over the years, it is showing its age in the face of more modern protocols like SignalProtocol (formerly known as Axolotl). Originally we wanted to integrate Axolotl/OMEMO but we haven’t been able to acquire a license from Open Whisper Systems. The next post will be about our plans, in collaboration with the Conversations team, to implement a revision of OMEMO that supports Olm instead of SignalProtocol.
Better XMPP Identifiers - Ed25519 Public Keys and .onions
In a future version of ChatSecure I’d like to introduce a human-usable implementation of using entire public keys as identifiers. We are already experimenting with appending a portion of your OTR fingerprint to your XMPP username, but I’d like to take it a step further using some of the latest advances in ECC.
The Current State of XMPP Identifiers
Right now identifiers for XMPP-based apps (
JID) are currently in the form:
Where whichever person who first registered
domain.com owns that identifier, similar to an email address. Even this basic level of complexity can be confounding for most non-technical people I’ve come across, so we’ve been doing what we can in our UX to relieve this complexity.
One of the main ways we’ve been simplifying things has been to implement QR-code and URL-based invite links of the form:
https://chatsecure.org/i/#<base64 encoded JID + OTR fingerprint>
Which shows invited contacts links to download the apps if they don’t have them, or directly opens ChatSecure to the add contact screen (with a somewhat-verified OTR key!).
Ed25519 Public Key Cryptography
The great thing about Ed25519 signing keys, is that that the whole public key can fit into 32-bytes. That’s equivalent to 32 ASCII characters (between 0-255). To allow for a more seamless representation (non-alphanumeric ASCII characters can be a bummer), you can use hex, for example:
But unfortunately XMPP JIDs don’t play well with Base64 because JIDs are case-insensitive. We can, however, use Base32 to shrink the size while still maintaining compatibility with XMPP JIDs:
Now that we have our username portion, let’s solve the other big problem with XMPP JIDs… the server.
Let’s Get Rid of XMPP Servers
Although there are some trustworthy XMPP servers out there, you can never be more secure than hosting your server yourself on hardware you own. Traditionally this has been a problem for non-technical users. Asking them to SSH into their headless Raspberry Pi to
apt-get install prosody won’t get you the results you’d want.
For technical users, on the other hand, one of the main problems has often been the lack of a publicly reachable IP address. Fortunately by utilizing Tor
.onion services, you can have a reachable address from anywhere, even behind carrier-grade NAT (like on a cellphone)!
.onion addresses are an 80-bit number represented in base32 and look like this:
The above example is the
dukgo.com XMPP server’s
A similar approach to the
.onion endpoints has been taken by the Ricochet project.
They replace both the username and server with the
.onion address itself. The main drawback (or feature, depending on your viewpoint) is that it’s a ground-up rewrite of a full stack chat client, which means no interoperability for existing XMPP clients.
Pond also operates in a similar way as far as
.onion addresses, but as far as I know there’s still only a rudimentary GUI and command line client, which limits its usefulness to very technical users.
My approach would be completely backwards compatible with existing XMPP clients, where you could use the same Ed25519 identifier on multiple servers (including your own
.onion) to ensure reachability by all of your contacts, regardless of their client of choice.
A Glorious Dawn
Using this new public key identifier, you can sign your other cryptographic identities and identifiers, and upload the results to
keybase.io, or wherever. New contacts can automatically verify your identity, and can use our new QR-code invites and links to avoid typing these long strings.
This above example could be your fully valid JID containing your public key and personal
.onion address. Because no human would ever type that in, we can share it in link form:
You can still have a human-readable username in your XMPP vCard, so you can choose whatever ‘username’ you’d like without creating a collision. You can also upload signatures of your OTR, PGP, or Axolotl identities (using this same Ed25519 key) to your vCard to help contacts auto-verify your cryptographic identity.
Bob serendipitously meets Alice in a crowded bar and they instantly hit it off by talking about obscure cryptographic protocols. A loud band starts playing and they have difficulty maintaining conversation, so they decide to move their communication to a secure channel.
Bob opens up the latest version of ChatSecure, and tries to share his Invite URL to Alice’s phone via a secure Bluetooth LE channel. Due to the crowding of the 2.4 GHz channel, they have trouble establishing a connection, and decide to switch to QR codes, which should work well in the dim lighting.
Alice successfully scans Bob’s QR code Invite URL, which opens up her browser to
chatsecure.org/i/#..., where she sees how to download the latest version of ChatSecure. Once the app finishes downloading, she clicks the same link again, but this time instead of opening her browser, it opens ChatSecure to the Add Contact screen. Bob’s account details are shown on the screen, and she can see his other cryptographic identities being pulled down in realtime from Keybase.
Now that they have established a secure channel, they decide that this music is too loud anyway, and it would be a good point to leave the bar and drink some coffee at one of their apartments. An encryption success story!
This is just one of many exciting changes I want to bring in the months ahead. Coming very soon will be a new iOS release with group chat, slick onboarding, and… push notifications. 🚀
ChatSecure, Conversations and Zom
We are excited to announce that major changes are planned for the underlying architecture of ChatSecure Android, and that there is a new UX-focused fork of the existing iOS and Android code bases called Zom. In the upcoming months, we will be releasing a new version of ChatSecure Android that will be powered by the core of Conversations, as well as the first releases of Zom for iOS and Android. Both will have a new package name and signing key, so the existing ChatSecure Android app will prompt you on every launch to either download the new version of ChatSecure or Zom.
ChatSecure & Conversations
Conversations is currently (in my opinion) the best modern open source Android XMPP client. It was originally founded, and still primarily maintained, by Daniel Gultsch. This summer he mentored Andreas Straub’s GSoC 2015 project to develop and implement a new XEP for asynchronous encryption based on Axolotl. They are calling it OMEMO (OMEMO Multi-End Message and Object Encryption), and it’s a genius way to adapt TextSecure’s fantastic Axolotl protocol in a way that’s compatible with almost every existing XMPP server (anything that supports PEP).
The source code to the current version of ChatSecure Android will soon be reaching end-of-life, and all new features and maintenance of that code will be happening in the Zom Android fork. The Zom fork is focused on a simplified and streamlined user experience, targeted toward a less tech-savvy crowd, but still powered by strong cryptography under the hood.
To keep the ChatSecure™ brand consistent across platforms, we are partnering with Daniel Gultsch to create a whitelabeled version of Conversations to become the new ChatSecure Android. ChatSecure Android will continue to be offered for free on Google Play and F-Droid, but will be signed by a new key, so keep an eye out for that. We’ll do our best to ease the transition.
Daniel and I discovered that we both have been working on methods to make it easier to whitelabel ChatSecure and Conversations. The primary purpose of these whitelabeling methods is to allow for downstream forks to more quickly and easily merge security updates and new features. As a nice side effect of this work, we will also soon be offering both automated and bespoke professional whitelabeling services to finally satisfy the (nearly constant) demand.
For more information about ChatSecure for Business, see below.
Soon we will be implementing OMEMO Encryption in ChatSecure iOS, and immediately contributing our OMEMO XEP code upstream to XMPPFramework so that other apps can benefit. We plan to utilize the pre-existing Objective-C library AxolotlKit, written by Frederic Jacobs, that has been used in production since the release of Open Whisper System’s Signal v2.0 for iOS. Unfortunately AxolotlKit is still currently GPL (and therefore not redistributable to the App Store) so this work is on hold until we can negotiate a change to an App Store-comptible copyleft license like LGPLv2 or MPL 2.0 from Fred and Moxie.
ChatSecure & Zom
As I mentioned earlier, the Zom fork is focused on a simplified and streamlined user experience, targeted toward a less tech-savvy crowd. Our goal is to produce a messenging product that is fun and easy to use, while also being secure by default, and as decentralized as possible. Users shouldn’t have to know or care that this is built for security under the hood, all they need to care about is being able to send cat pictures and emojis to their friends without fear of censorship or retaliation. This is a notoriously hard problem to solve.
Zom Android will have a radically different UI than the current version of ChatSecure Android, is a hard fork of the current code. Many advanced features will be hidden or removed for the sake of simplicity (with sane secure defaults of course!), which we feel is the right move when targeting the mass market. It will also only support a single account at a time, have a bigger focus on media sharing, and sport silly stuff like sticker packs.
Under the hood, it will still support OTR, XMPP, Tor, SQLCipher, certificate pinning, and all that crypto goodness that you expect, all bundled up behind a shiny new interface designed to hide or minimize the vast majority of the complexity. No use in having a secure messenger if it’s as hard to setup and use securely as PGP, right?
Zom iOS is a soft fork of ChatSecure iOS, meaning it was designed to track upstream as closely as possible. We will continue to develop new features first in ChatSecure iOS, and push them to the downstream forks, such as Zom, as soon as they are stable. We will also ensure that security updates are available to every downstream fork as soon as possible.
Our ChatSecure Core whitelabeling system is made possible by the newly supported iOS 8.0+ dynamic frameworks.
ChatSecureCore.framework contains the entirety of the upstream ChatSecure source code and resources, and allows for every string, image asset, and resource file to be customized via the
Another nice bonus is that this work will open the door for ChatSecure for Mac, which will be the first open source, modern, native, sandboxed XMPP client for OS X. The lack of maintenance of Adium has made this issue especially urgent so, if you’d like to help, please be in contact!
ChatSecure for Business™
Since early 2012 ChatSecure development has been financially supported by the following (outstanding) organizations: The Guardian Project, OpenITP, Rights Action Lab, and the Open Technology Fund. There have also been many smaller individual donations over the years (thank you)! Although open source grants and donations can be a great way to fund certain kinds of software development, the process can be glacial, arduous, and unforgiving at times. Even though I intend to continue funding ChatSecure development with grants for the immediate future, I still think it would be wise to begin diversifying our funding portfolio.
Despite living in Berkeley, with a close physical and social proximity to the frothy tech scene of San Francisco and Silicon Valley, I still have no desire to seek VC funding for ChatSecure. I was part of the first class to the awesome Matter startup accelerator as a co-founder to OpenWatch, an anti-authoritarian citizen journalism app. That whole concept didn’t really fly in the VC world, so eventually we pivoted our core technology to become Kickflip.io, an open source mobile live broadcasting SDK + SaaS platform. My experience with the VC scene, although mostly pleasant, has made it very clear that traditional VC is a tough fit for open source privacy / security software.
Whitelabel ChatSecure iOS and Android apps
I get emailed approximately once a week from some organization or individual who is seeking to produce a whitelabeled version of ChatSecure. In the past we haven’t really had the resources to help to anyone, and even had to tell people to abandon their efforts due to the legal complexity of offering GPL license exemptions for the iOS client.
This has been the equivalent of leaving money on the table for years, especially considering I know for a fact there at least a few “illegal” forks of ChatSecure on the iOS App Store. I believe that ChatSecure should remain under a copyleft license for the benefit of the public good, but I never intended to prevent the free binary redistribution of our code on the App Store (an unfortunate side effect of the GPL) as long as the source code to your modifications remains available.
As I mentioned in a previous blog post, future releases of ChatSecure iOS will be available under the MPL 2.0, which is a fully App Store-compatible copyleft license (also used by Firefox and VLC for iOS). It’s most similar to the LGPL, so you only have to distribute the source to modified ChatSecure files, and you only have to seek a license exemption if you plan to modify upstream code.
This solution has extra benefits because it encourages downstream forks to minimize their modifications to upstream code, allowing them to more easily pull in security updates and new features. Most students, individuals, and small organizations won’t need to pay for a license if they follow the requirements of the MPL.
Larger organizations and customers seeking bespoke solutions will desire the freedom to release deeper proprietary modifications, so we will be developing a fair pricing model to support these kinds of applications as well. This new revenue model can also help offset our reliance on grants, and allows for a greater diveristy of messaging products all built upon a solid ChatSecure foundation.
An XMPP client without a server is rather useless, so we will also be offering paid XMPP server and ChatSecure Push hosting. Since we believe in the power of open source software, both the client and server implementations will be completely free (as in source), and designed to be easily deployed by a moderately technical end user. Running your own secure XMPP server continues to be extremely difficult for the average person, so we intend to solve that:
- Paid SaaS hosting for XMPP and Push infrastructure.
- Secure Server Hardware solution for Enterprise networks that lives behind your corporate firewall.
- HIPAA and other data security regulation compliance.
- ChatSecure Server for Android. Quick to setup, easily provision new devices, secure by default (end-to-end and at-rest), and user friendly.. even for novices! This open source Android XMPP server app will be based on Prosody and will use Orbot’s
.onionservices to provide universal NAT traversal (even over cell networks).
If you’re interested in ChatSecure for Business please send me an email as soon as possible so we shape our product offerings to better match your needs in the upcoming months.
We’re on track to release the first beta version of ChatSecure Push in both Zom for iOS and Android, as well as ChatSecure for iOS. We’ll be using separate federated instances to demonstrate decentralized push between multiple native mobile applications. We plan on integrating some components of ChatSecure Push into Conversations as well. It’s by far the #1 most requested iOS feature, so I hope you’ll like it.
Axolotl / OMEMO
Work on implementing Axolotl / OMEMO into ChatSecure iOS will begin as soon as we can negotiate a license change to AxolotlKit. Hopefully we can sort that out quickly and get to work.
We plan to support unencrypted group chat in ChatSecure iOS v3.2 this fall. Work on np1sec (aka mpOTR) for multi-party OTR has been slow, but appears to be progressing. OMEMO works for small group chats as well, so we may adopt that in the meantime.
ChatSecure for Mac
ChatSecureCore.framework effort will soon make it possible to create a sandboxed desktop version of ChatSecure for Mac. Want to help? Drop me a line.
ChatSecure Server for Android
It’s still too hard to host your own secure XMPP server. We are going to change that… some time next year.
We will be putting more effort toward providing secure communications tools to individuals, small teams, and larger businesses alike. Feel free to reach out if you’d like to discuss business applications for ChatSecure or have ideas about opportunities for growth.
iOS 9 Tor VPN
As a quick side note, iOS 9 added a neat new API for full device VPN, which opens the door for a better way to implement Tor on iOS. We are working on it!
I had sort of a wild idea the other day to integrate ChatSecure with the Keybase API, which is basically a cryptographic identity provider and aggregator of your semi-decentralized signatures scattered around on Twitter, GitHub, etc. You can think of it as a successful mashup of a social network and a GPG keyserver. There’s a lot of cool UX stuff we could do there, so I’d like to hear any ideas! Also, Chris, we should chat!
We will soon be hiring mobile, frontend, and backend developers with some or all of the following qualifications.
- iOS: Objective-C, Swift, C, AutoLayout, Storyboards, CocoaPods, iPad, Cocoa, Mac UI, XCTest, an app in the App Store
- Android: Android 4.0 SDK and higher, Android NDK, Java, C, Android Studio, Gradle, JUnit, an app in the Play Store
- Backend: Python, Django, Ubuntu, Go, Rust, Docker, your own API
- General Programming: data structures, flow control, POSIX, standard stuff. Experience with Test Driven Development would be nice.
- Security: Some basic knowledge of cryptography is a must, but don’t stress about the advanced stuff. You must have experience with modern secure / defensive coding practices, familiar with common vulnerabilites in native code, identifying potential areas of concern, surface area analysis, etc.
- Open Source contributions are highly recommended: individual projects, larger projects, pull requests, bug reports, QA, documentation, modular coding practices, semantic versioning, Travis-CI, GitHub, git. Know how to find the best existing open source libraries that solve a need. Be able to quickly assess a library’s code quality and general maintenance health compared to similar projects. Know when to just rewrite it from scratch instead. Know how to properly publish your new open source library.
- Freelance Contrators Only: Sorry, there are currently no full time or permanent positions. Interns are OK though! If you’re looking for that steady 9-5 you really should be looking somewhere else, because this ain’t it. Fortunately Obamacare has made buying individual health insurance a lot better for us freelancers.
- Equal Opportunity: We do not discriminate based on race, color, sex, religion, national origin, age, disability, sexual orientation, genetic information, reprisal, socioeconomic class, radical political beliefs, tattoos, hair color, clothing style, or otherwise.
- Berkeley, CA: East Bay or SF preferred. Remote may be negotiable though!
Want to stand out by sending your application early? Email me with a link to your GitHub profile and a short introduction.
That’s All Folks
Until next time. Thank you!
I’ve noticed that many apps have been appropriating ChatSecure iOS code for their whitelabeled products, even though the code is not currently suitable for this purpose. There are a lot of cross-dependencies, assumptions about the ChatSecure brand, and some unfortunate spaghetti code that has accumulated over the last few years of development. The GPL license also currently prevents people from legally shipping forks or devirative works that include our code to the App Store (without an exemption). Although many people and organizations have requested license exemptions since our move to the GPL, we haven’t had the time or legal resources to grant any.
Now that we are also working on a whitelabeled version of ChatSecure ourselves, the pain of keeping the two versions in sync has made it apparent that a major refactor needs to happen as soon as possible. This will be done in two phases:
- Creating a monolithic framework containing almost all of the existing ChatSecure iOS code.
- Splitting that framework into multiple sub-frameworks each concerned with a single domain: UI, network, database, encryption.
Additionally, to accomodate forks and other open source projects that wish to reuse our code, we will be relicensing these reusable components under the copyleft MPL 2.0 license. This is the license used by Firefox and VLC for iOS. It is most similar to the LGPL in that binary distributions require attribution and that modifications to the code need to be publicly available. It doesn’t virally spread its terms to the rest of your program like the GPL, there’s no issue with static linking like the LGPL, and it is fully compatible with the App Store.
Organizations that wish to release closed source / commerical / proprietary apps will also be able to use the code as long as they follow the terms of the MPL 2.0. In short, just give us proper attribution, and publicly distribute any source code changes you’ve made to our framework.
This will require a very large refactor of the existing ChatSecure code into reusable components. Right now there is a tight coupling (aka spaghetti code) between the UI, XMPP network stack, database, and encryption layer. Each of these components will need to be split into reusable components with no cross-dependencies.
For the first step, we will create a monolithic ChatSecure framework that includes the entirety of the ChatSecure iOS code as a reusable library. This will allow improvements and security updates to the core ChatSecure code to be more readily available to whitelabeled apps.
After that is complete, we will begin splitting up the monolithic framework into smaller and more manageable frameworks: UI, network stack, database, and encryption layer. When that is complete, it will become much more feasible to create novel UI experiences that diverge from the upstream ChatSecure iOS UI code, without sacrificing the ability to easily merge in security updates and new backend features.
Bonus: ChatSecure for Mac
As an unintended bonus of this work, it will then be possible to eventually create a native OS X desktop client for ChatSecure. The current standard for OTR+XMPP on OS X, Adium, hasn’t been updated since last year but depends on Pidgin’s libpurple, which is known for containing many security holes. The lack of Adium updates puts users at risk, and it looks like new development is almost completely stalled. It also doesn’t use OS X sandboxing so any Adium vulnerability allows an attacker to read and write (almost) any file on your computer, including past conversations, passwords, etc. We can fix that.
On the Roadmap
We are now well on our way to implementing our design for decentralized push support, courtesy of a new grant from the Open Technology Fund. Yes, we are finally fixing the XMPP push problem! We are very excited to ship beta versions of ChatSecure that will include this functionality in early Q4 2015. This is a feature that can be included in ANY app (we have SDKs for iOS and Android), that allows your users to communicate with users of other apps. No more walled gardens!
This work is compatible with and compliments the existing effort to add push support to XMPP itself.
We will also be integrating the mobile friendly Axolotl end-to-end encryption protocol into ChatSecure iOS, following the lead of the Conversations team. This is the same protocol used by TextSecure/Signal, developed over at the amazing Open Whisper Systems.
We are also working on a streamlined onboarding process to help new users who are unfamiliar with the intricacies of XMPP. Stay tuned for more updates regarding that exciting new feature!
A Bright Future for Secure Messaging
With all of these changes in place, we will be able to deliver a more seamless user experience that can rival that of other popular mobile messaging apps. We are committed to open source, open standards, decentralized protocols, and delivering the most secure and user-friendly product possible.
Thank you for your support!