ChatSecure v4.3.6

Tue, 11 Dec 2018 00:00:00 -0800

ChatSecure v4.3.6

This maintenance release contains an important update to the certificate pinning alert dialog. After updating to v4.3.6 you may see an alert asking you to re-verify your server’s SSL/TLS certificate.

Previously, the dialog would display ✅ Valid if the certificate was valid for any domain. Additionally, it was then pinning the certificate to the connected domain (e.g. xmpp.example.com from the SRV records), and not to the JID domain (e.g. example.com).

If you are not automatically prompted to re-verify, you should manually re-verify your server’s certificates by going into Settings -> Pinned Certificates, delete the existing entries, and then reconnect.

Special thanks to Michel Le Bihan, for uncovering the flaw and quickly proposing a fix.

Release Notes

Fix security issue in certificate pinning alert dialog, where any valid certificate would show as valid
Fix crash when rapidly scrolling through chat history
Fix issue where chat history is temporarily blank after sending a message
Swift 4.2 / Xcode 10.1
Updated 3rd party dependencies
Other minor bug fixes
Full release notes
Changelog

Download the latest ChatSecure version here:

ChatSecure v4.3.0 - OMEMO Group Chat Preview

Mon, 09 Apr 2018 00:00:00 -0700

ChatSecure v4.3.0 - OMEMO Group Chat Preview

Chat history now automatically synchronizes between your devices - including OMEMO chats! This includes any device using a modern XMPP client that supports Message Archive Management (aka MAM or XEP-0313). There still may be some rough edges with some configurations (like duplicate messages), but if your server supports MAM, you should be good to go. You’ll also notice that your active group chats are synchronized between devices via support for Group Chat Bookmarks (XEP-0048).

Another big change is preliminary support for OMEMO Group Chats. This still needs some testing and isn’t yet recommended for general use. If you’d like to try it, you must first enable it via the Advanced section of the Settings screen, and then also enable it individually for each group chat in the Members screen. Regardless of the settings you will still be able to receive incoming group OMEMO messages.

Up next will be a performance and stability release focusing on MAM and OMEMO groups.

Contributing

Thank you to all of the monthly supporters!

Not a supporter yet? It’s easy! You can start supporting development directly in the app. Sustainable open source starts with you! ❤️

Download the latest ChatSecure version here:

Release Notes

Message Archive Management (XEP-0313) - one-to-one and group chat history is now synchronized between multiple devices, if supported by your server.
Group Chat Bookmarks (XEP-0048) - Group chats are now bookmarked on your server to allow persistence between devices / installs.
OMEMO Group Chat Encryption Preview - This is not yet recommended for general use and is for advanced users only. Must be globally enabled in Advanced Settings as well as individually for each group chat.
Improvements to general group chat user experience
Bug fixes and performance improvements
Full release notes
Changelog

ChatSecure v4.2.0 - Group Chat

Tue, 24 Oct 2017 00:00:00 -0700

ChatSecure v4.2.0 - Group Chat

First of all, thank you to all of the monthly supporters! Your contributions have been a great motivator to keep the release cycle moving along at a regular pace, from master branch, to TestFlight, to App Store. Not a supporter yet? It’s easy! You can start supporting development directly in the app. Remember, sustainable open source starts with you! ❤️

This version contains numerous improvements to the existing group chat functionality: unencrypted media transfers (XEP-0363), brand new participant list, and enhanced stability and reliability. There is still a lot of work to be done, but it has stabilized enough for a general release. It was designed with small, private groups in mind, so it hasn’t been tested with very large groups, and “anonymous” groups are currently unsupported.

Up next is support for XEP-0313: Message Archive Management, which will allow you to use the same account on multiple devices, and is a prerequisite for OMEMO group chats.

Download the latest ChatSecure version here:

Release Notes

Improved group chat reliability
Media sharing in group chats (unencrypted only)
Redesigned group participants view
Improve performance of chat view. Thanks @stigger!
Bug fixes and refactoring
Tor 0.3.0.11
Full release notes
Changelog

ChatSecure v4.1.0 - Media Messaging

Fri, 30 Jun 2017 00:00:00 -0700

ChatSecure v4.1.0 - Media Messaging

This release contains major improvements to how media messages are handled. We’ve added support for both XEP-0363: HTTP Upload and the aesgcm:// scheme, allowing for mobile-friendly asynchronous end-to-end encrypted file transfers.

Previously we used a rather obscure protocol called OTRDATA that utilized OTR TLVs to send arbitrary data through existing OTR sessions. It worked reasonably well… sometimes. It was subject to throttling by XMPP servers, had a lot of encoding overhead, and wouldn’t work unless both parties were online and were in an active OTR session.

This new file transfer mechanism was designed to work well with OMEMO, and should handle multiple devices and group chats once that work is completed. To see if your server supports XEP-0363, check the “Server Information” section of your account details. If not, contact your server administrator or in the meantime test it out on a server from this list.

Up next will be improvements to group chat, multi-device conversation history, and better reliability of push notifications. If you like what we’re doing, don’t forget that sustainable open source starts with you! Thank you so much to everyone who has pledged their support! ❤️

Download the latest ChatSecure version here:

What’s new in 4.1.0

XEP-0363: HTTP Upload support for much faster and reliable media messaging. [1]
XEP-0352: Client State Indication. Helps reduce network usage when running in the background.
End-to-end encryption for file transfers in OMEMO or OTR sessions [2].
Inline media previews for incoming URLs. (Optional)
Bug fixes and refactoring.
Tor 0.3.0.9

Caveats

Your server administrator must enable support for XEP-0363. See mod_http_upload for Prosody [3] and ejabberd [4] for more details.
Encrypted file transfer is required in OMEMO/OTR, but has limited compatibility for receiving clients. Users on the other end will receive aesgcm:// links [2].
Inline media previews are enabled by default, but can be disabled on a per-account basis. This feature should be disabled if you have extreme privacy concerns or do not trust your contacts. This setting is always disabled for Tor accounts.
Known bug related to adding friends and setting up the first OMEMO session. These will be addressed in a future release.

References

https://xmpp.org/extensions/xep-0363.html
https://github.com/iNPUTmice/ImageDownloader
https://modules.prosody.im/mod_http_upload.html
https://docs.ejabberd.im/admin/configuration/#mod-http-upload
https://xmpp.org/extensions/xep-0352.html

Changelog: https://github.com/chatsecure/chatsecure-ios/compare/v4.0.9…v4.1.0

ChatSecure v4.0.9 - Sustainable Open Source Starts With You

Tue, 23 May 2017 00:00:00 -0700

ChatSecure v4.0.9 - Sustainable Open Source Starts With You

The v4.0.9 release marks the beginning of a fundraising experiment to measure the long term viability of user-driven open source privacy software development. ChatSecure has been around for over five(!) years now, and grown from a small hobby project to a full time mission to prevent the centralization of communication.

This growth wouldn’t have been possible without the generous funding and support of organizations like The Guardian Project, OpenITP, and the Open Technology Fund along the way. The open source privacy software scene would not be nearly as vibrant without grant funding, and many projects you’ve heard of receive large amounts of funding from similar sources.

Unfortunately there are large risks with this funding model:

Funders generally do not support ongoing software maintenance. Grants require specific milestones and deliverables.
The grant cycle can be very long. It can take over a year and multiple iterations between a concept and secured funding.
Even after multiple rounds of negotiation, funders may ultimately decide not to fund your vision.
Fundraising is a full time job. For a small team, that means less time can be spent on improving the product.
There’s also the elephant in the room. Although “Internet freedom” appropriations may be safe for now, a large chunk of this funding pool could also quickly dry up, leaving many projects scrambling to keep the lights on.

Other funding models don’t work well either for tools in this space. Venture capital is incapable of funding “privacy software” products without eventually introducing something to monetize you by violating your privacy. The upfront cost of paid App Store builds prevents vulnerable users without reliable access to payment services from downloading the app. Services like Patreon may work for some projects, but most rarely receive enough funds to actually pay anyone for development. Offering white labels and consulting services can also work to fund core development, but it doesn’t scale well and can take a considerable amount of time.

❤️ This Is For You

You, the user, are the reason this project exists. We’ve now put the power of direct funding in your hands. There are quite a few of you now, and if a relatively small fraction of you can contribute a few bucks a month, you will prove that open source privacy software development can be sustainable.

You can now show your continued support directly within the app. The current options are ☕️ $2.99/mo, 🍺 $5.99/mo, and 🎁 $19.99/mo. Hopefully these are enough choices for now, and we’re welcome to any feedback or suggestions. If you’re already a supporter, or don’t have the spare cash right now, you can help in other ways like improving a translation, submitting a bug report, or simply spreading the word.

Thank you so much for your support!

Download the latest ChatSecure version here:

ChatSecure v4.0 - OMEMO and Signal Protocol

Tue, 17 Jan 2017 00:00:00 -0800

ChatSecure v4.0 - OMEMO and Signal Protocol

We’re excited to announce the release of ChatSecure v4.0, our largest step forward in usability since the addition of push messaging six months ago. The most significant new feature is OMEMO Encryption, a mobile-friendly encryption scheme pioneered by Conversations that adapts Signal Protocol to the XMPP world.

Using OTR on mobile has always been problematic because it was designed for desktop computers and synchronous conversations. For example, if you don’t have an active OTR session, you can’t start a new secure session if your contact is offline. Even if you do have an OTR session, it can go stale if one of the sides is purged from RAM due to low memory. This can lead to messages that disappear into the ether with no standardized way for the recipient to indicate which message they couldn’t decrypt.

OMEMO fixes all of these problems, and opens doors to new features that were impossible with OTR, like multi-client support, encrypted group chat, and more reliable file transfers. Multi-client conversations would work particularly well with our planned Desktop client, so we’re excited to add support for these features in future releases.

There are some other major changes in this release that improve the user experience, such as the outgoing message queue and enhanced identity management. The message queue automatically negotiates OMEMO and OTR sessions and allows you to resend messages in case of failure.

The new profile view allows you to view a contact’s OMEMO and OTR fingerprints, change each fingerprint’s trust settings, and modify the default encryption method. We’ve made important changes to the way trust is handled for new contacts by adopting the TOFU or “trust on first use” model. The first time you see OMEMO or OTR fingerprints for a contact, they will appear as trusted and marked with “TOFU” in the user interface. Any subsequent fingerprints will be untrusted and need to be manually verified. In this release you can compare fingerprints out-of-band by pressing on the cell and bringing up the system share dialog, but we plan to streamline the fingerprint comparison process in the future.

There are hundreds of other changes under the hood that fix bugs, improve performance, and enhance reliability. On the roadmap for v4.1 and beyond are improvements to group chat, including OMEMO encryption, multi-device chat history synchronization (XEP-0313 MAM), read receipts (aka chat markers XEP-0333), improved file transfer, and more.

We’re excited to see people experience this new frontier for XMPP usability. We will be working with the Zom project to bring OMEMO support to their suite of apps, and we expect other apps will start adopting OMEMO as well.

Thank you to everyone who helped make this release a reality!

Download ChatSecure on the App Store

The End of ChatSecure Android

Fri, 16 Dec 2016 00:00:00 -0800

The End of ChatSecure Android

The developers of the Android version have hard forked the code and are no longer maintaining the upstream version. If you still use ChatSecure Android you should migrate to another app immediately. For a similar user experience and the best compatibility with the latest features of ChatSecure iOS, we recommend downloading Conversations.

The development of ChatSecure iOS is unaffected by this change and we will continue to release new features and updates.

ChatSecure iOS v3.2.3 - XMPP Push

Mon, 25 Jul 2016 00:00:00 -0700

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

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.

v3.2.3 changes:

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

Thu, 14 Apr 2016 00:00:00 -0700

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.

Example Flow

Alice (alice@example.com) and Bob (bob@example.com) 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

Tue, 08 Dec 2015 00:00:00 -0800

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:

username@domain.com

Where whichever person who first registered username on 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:

7388a1238a0865a74d721861356d3f7869c598494ff906a52e15338585a02c00

This is 32-bytes of random data from random.org, which in theory could represent an entire Ed25519 public key. Using other encodings such as Base64 can result in an event shorter output:

c4ihI4oIZadNchhhNW0/eGnFmElP+QalLhUzhYWgLAA

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:

ooekci4kbbs2otlsdbqtk3j7pbu4lgcjj74qnjjocuzylbnafqaa

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:

wlcpmruglhxp6quz.onion

The above example is the dukgo.com XMPP server’s .onion address.

Similar Work

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.

ooekci4kbbs2otlsdbqtk3j7pbu4lgcjj74qnjjocuzylbnafqaa@wlcpmruglhxp6quz.onion

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:

Invite Link URL (Link will 404, server/client support still in progress)
XMPP URI
QR Code

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.

Contrived Example

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!

Roadmap

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

Stay tuned!

ChatSecure, Conversations and Zom

Fri, 02 Oct 2015 00:00:00 -0700

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

Android

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.

iOS

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.

Android

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?

iOS

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 OTRResources bundle.

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.

ChatSecure SaaS

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 .onion services 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.

Roadmap

Push

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.

Group Chat

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

The ongoing 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.

Business

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!

Keybase Integration?

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!

Jobs

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
Frontend: HTML5, CSS, JavaScript, Bootstrap, Jekyll, Angular, React, Ember, your own website
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!

ChatSecure Core

Tue, 11 Aug 2015 00:00:00 -0700

ChatSecure Core

Motivation

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.

New License

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.

Refactor

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

Push

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.

Axolotl

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.

New Onboarding

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!

ChatSecure iOS Security Audit

Fri, 26 Jun 2015 00:00:00 -0700

ChatSecure iOS Security Audit

Last year OpenITP generously funded a security audit of the ChatSecure iOS client, performed by QuarksLab in Q1 2014. It was the first professional security audit of the code and it revealed a few critical issues that we were able to quickly address.

Originally ChatSecure was designed to be a multiprotocol IM client that supported OTR over AIM, Google Talk, Facebook, and generic XMPP. Because libpurple, used in Pidgin and Adium for chat network support, is licensed under GPL we could not distribute it on the App Store. Additionally libpurple has had quite a few vulnerabilities itself, so instead we chose to use two Objective-C libraries: XMPPFramework for GTalk, Facebook and XMPP, and a lesser-known library called LibOrange for AIM support.

XMPP and STARTTLS

One of the issues they found was the ability for an attacker with a privileged network position to potentially block the STARTTLS functionality of XMPP, which is used to initiate TLS connections. Although we support TLS with certificate pinning, XMPPFramework directly followed the XMPP specification which states the server is to specify (in plaintext) whether or not TLS is supported or required. This is a problem for all protocols utilizing STARTTLS (including email), and no server should ever allow plaintext connections in 2015. We worked with the XMPPFramework maintainers to add the ability to require TLS connections regardless of what the server reports. This way if an attacker tries to force a downgrade attack, the connection simply fails.

Many XMPP server operators have pledged to require STARTTLS for all client-to-server and server-to-server connections. Due to this change, many servers no longer federate with Google’s XMPP gateway because Google still doesn’t support server-to-server STARTTLS.

LibOrange and AIM

LibOrange (for AIM/Oscar) was originally included back in 2011 when ChatSecure (then called “Off the Record”) was a proof of concept pre-release hobby project to demonstrate libotr on iOS. The LibOrange code originally was not carefully audited and turned out to contain serious flaws in both its memory handling, and the example implementation, which included debugging commands that were not documented or fully understood.

Although we had been planning to remove AIM support for other reasons, thanks to Quarkslab we immediately removed LibOrange and AIM support and pushed a new release as soon as these flaws were uncovered on 2/21/2014. Fortunately there were no complaints from our users after its removal.

If you still use AIM on other chat clients, you should disable it immediately and migrate to other networks. AIM is a centralized messaging service hosted in the US, and has a complete view of your message content, history, contacts, and metadata (IP address, connection/disconnection times, etc). Using OTR over AIM only helps protect message content.

Improving Security

Since the audit last year, we have implemented a number of features to improve security. For example, all content is locally encrypted in a SQLCipher database, and it is possible to connect to XMPP servers over Tor.

XMPP servers with a Tor .onion address that force OTR, such as Caylx or otr.im, currently offer the one of the easiest ways to protect both message content and identifiable metadata.

Even better is to physically host an XMPP server for yourself and your friends, but unfortunately this is still very difficult to get right, even for tech savvy users.

The combination of XMPP+OTR+Tor still offers the best and easiest way to provide decentralization, content/metadata protection, and censorship resistance. Unfortunately this combination is difficult to make user-friendly, especially on mobile devices. Both XMPP and OTR were originally designed for desktop computers and are definitely showing their age in the age of mobile.

There are efforts to replace this combination, such as Pond, but it’s almost impossible for a non-technical person to understand or setup.

If you don’t need decentralization or metadata protection, TextSecure/Signal is a very good choice because it is easy to setup for non-technical users and works very well on mobile. Its main downside is that you still need to use a real phone number to register, and to communicate with other people you need to share your phone number with them, which is not always desirable. It also makes open federation impossible.

Moving Forward

We are still committed to supporting the XMPP+OTR+Tor combination in ChatSecure for now, but are monitoring the maturity of new technologies that solve usability headaches without sacrificing decentralization, content/metadata protection, and censorship resistance. We are working on a solution for interoperable push messaging in ChatSecure, XMPP will also soon finally have a way to provide mobile push notifications, and Axolotl (which underlies Signal/TextSecure) has proven to be a great replacement for OTR on mobile devices.

Although open source software with deterministic builds remains a best practice for security software, careful coding techniques cannot always protect against all flaws, especially when linking against 3rd party libraries. We will be commissioning a new professional security audit of the ChatSecure iOS and Android code to be completed by the end of the year.

ChatSecure iOS v3.0 Released

Mon, 05 Jan 2015 00:00:00 -0800

ChatSecure iOS v3.0 Released

Over the last year, David Chiles and I have been working on a major overhaul of the iOS app to modernize the user experience and incorporate additional security features. The most significant user-facing changes are:

The buddy list has been replaced by a list of your most recent conversations, bringing it in line with modern messaging clients.
Conversation archives are encrypted using SQLCipher.
Experimental Tor support for custom XMPP accounts.

Download ChatSecure for free from the App Store. If you’re a developer you can also compile it yourself from the source code on GitHub.

Tor Support

Right now (to my knowledge) we are the only messaging app on the App Store that supports Tor. Although the current implementation appears to be functional, please only use it for testing purposes until it has been studied further by security professionals. In other words, do not rely on it for strong anonymity, and use something like TAILS instead.

During our journey to add Tor support, we first tried to extract the Tor management code from Mike Tigas’s Onion Browser, but discovered it was too tightly coupled with the rest of the app. We also investigated Tor.framework by Hive Wallet but it required some awkward patching of the Tor source code, and has since been deprecated by the original developers. Eventually we discovered Claudiu-Vlad Ursache’s CPAProxy, a more modern attempt at a thin Objective-C wrapper around Tor’s control port. Although it is currently missing a few features like customizable bridges and pluggable transports (and a security audit), I would encourage other developers who are interested in adding Tor support to their iOS apps to help us improve CPAProxy.

Encrypted Storage

When ChatSecure iOS v2.0 was released over a year ago, it contained a major overhaul of the internal data model to support Core Data, Apple’s solution for data persistence. We originally planned on utilizing the MITRE Corporation’s encrypted-core-data project, which adds a customized NSPersistentStoreCoordinator backed by Zetetic’s SQLCipher. Unfortunately working with Core Data can be terribly frustrating, especially when you cannot debug its closed-source internals.

Fortunately we discovered YapDatabase by Robbie Hanson, an Objective-C key-value-collection store built on top of sqlite. It has all sorts of nice features like a coherent concurrency model, fast full text search, easy binding to UITableView, and more. If you develop iOS apps, I strongly encourage you to check it out, especially in conjunction with something like Mantle. Because it is built on top of sqlite, it was relatively straightforward for us to add SQLCipher support (use the YapDatabase/SQLCipher Cocoapods subspec).

New User Interface

Our overhaul of the UI started at the OpenITP UX Sprint, which brought together developers and designers to help improve the usability of crypto tools. One of the biggest challenges when creating security software is ensuring it’s usable by normal humans. During this event we decided to finally move away from the “buddy list” because it no longer reflects how people use messaging apps, especially on mobile. In its place, we added the “Conversations” view, which simply lists your most recent conversations and is designed to feel similar to the built-in iOS Messages app.

We also decided to use Jesse Squires’ totally awesome JSQMessagesViewController for the messaging UI. We were previously using a custom solution designed to imitate the iOS 6 Messages.app, but this new approach should allow us to more easily add in-line media messaging in the future.

On the Roadmap

This release has a large amount of internal refactoring that should (hopefully) make it easier to maintain and add new features. Here are some features we are planning on adding over the next year:

Inline multimedia messaging via OTRDATA
A modern onboarding experience that makes it easier for new users to get started
More options for users behind restrictive firewalls (Tor pluggable transports)
An interoperable privacy-conscious solution for push messaging
Axolotl, the mobile-friendly asynchronous encryption protocol used by TextSecure
Internet-free hyperlocal chat network over Bluetooth LE
Sandboxed Mac OS X port
An easy way for users to set up their own XMPP server

Unfortunately, despite the recent proliferation of “secure messaging” apps, we are still a long way from ubiquitous, easy to use, decentralized, verifiable end-to-end encryption.

Fixing the XMPP Push Problem

Tue, 08 Apr 2014 00:00:00 -0700

Fixing the XMPP Push Problem

XMPP is at serious risk of being permanently replaced by proprietary alternatives that have already solved the mobile push messaging problem. Remember in the 90s how many closed IM networks there were? Today it is much worse.

Current Approaches

Thin Client

Run a thin XMPP client on a ‘man-in-the-middle’ server that can relay messages to clients via push message when mobile clients aren’t actively connected. Many iOS messenger apps use this method without clearly informing the user.

Pros:

Can add push support for any arbitrary XMPP server

Cons:

Very obvious, centralized point of failure
Allows for easy eavesdropping or even active MITM attacks
Requires plaintext storage of remote login credentials (e.g. Gmail passwords)

Examples:

Verbs Pro (iOS)
IM+ (iOS, Android, Web)

Persistent Socket

Persistent sockets is how XMPP was originally designed to work. Acquire a long-lived socket and keep it open… forever. Android apps are able to use this method, as well as iOS apps that declare VoIP functionality. On iOS this socket is supposed to be for VoIP signaling only, so you can be terminated by the OS for too much activity while in the background (e.g. presence updates).

Pros:

XMPP works as designed, most of the time
No modification to existing infrastructure

Cons:

Battery drain because the antenna cannot be powered down
Disconnection can still occur from wireless network problems
iOS apps can still be terminated by the OS under memory pressure or too much socket activity

Examples:

ChatSecure (Android version only)
Monal (iOS)

Abandon XMPP Compatibility

Many apps have abandoned traditional XMPP in favor of proprietary modifications that lack federation and interoperability. WhatsApp took ejabberd, an open source XMPP server written in Erlang, and modified it to send native push messages, but of course it only works with their official apps.

Pros:

Relatively easy to implement
Lock in users to your proprietary ecosystem

Cons:

Locks you in to their proprietary ecosystem
No federation between domains
No federation between apps: each app developer taking this approach is their own silo, unable to communicate with any others

Examples:

WhatsApp
TextSecure (however, email identifiers and a limited form of federation are coming soon)

How Push Messages Work

If you’re not familiar with Apple’s APNs or Google’s GCM, these services are the officially sanctioned way of sending push messages to mobile apps. However, there are certain limitations that prevent easy XMPP-style federation:

You cannot (easily) send push messages to someone else’s app
Push messages on iOS are not guaranteed to be delivered (although they usually are)
Push message payloads on iOS cannot be processed by the app in the background before iOS 7

The biggest problem is that there is no easy way to send push messages between my app and your app. For me to send a push to one of your app’s users on iOS, I must first obtain an APNs SSL certificate/key pair from you, and one of your user’s ‘push token’ that uniquely identifies their device to Apple. These push tokens are potentially sensitive information because they allow Apple to locate your device (in order to send it a push).

Solving Inter-app Push

To solve the XMPP push problem, we need multiple pieces of new infrastructure:

Solve the problem of how to send raw push messages between two arbitrary apps.
Define spec for where clients (apps) should send messages when contact is “offline”
Define spec for where servers should send messages when contact is “offline”

Instead of having each app developer manually provide every other app developer an SSL push certificate and push tokens, an intermediary server can be built to automate this process and obscure the actual push tokens, as well as control potential spam.

However, this approach will require cooperation between XMPP clients and XMPP servers in order for federation to work properly.

ChatSecure iOS can connect to almost any XMPP server, so it can be a client for multiple JIDs. A user could have the accounts “alice@example.com” and “alice@jabber.org” and expect to receive background notifications for both accounts. This means the operators of the XMPP servers for example.com and jabber.org will need to understand and implement our spec to send pushes to our client.

Push Relay Server

This is the server that sends the final push to the app user. It will need to accept POSTs from authorized pushers, which can include XMPP server operators, individual app developers with other relay servers, or even other end users. For ChatSecure iOS we can do this by having users register a unique username/password with our instance of the push relay server, tied to an optional email address identifier for password resets.

After registering a “ChatSecure Push” account, you must add a device to receive pushes, which includes the required information for delivering the final push message (the APNs token) and probably a user friendly identifier / basic device info.

To receive push messages to your account (which are then forwarded to all your registered devices), you must request a whitelist token from the server to give to your friends and authorized XMPP servers. Anyone with a whitelist token will be able to send you messages directly to all of your devices by crafting a POST message to our relay server.

An old draft of how this server might work is available here but it needs to be updated because we identified serious problems with this spec a long time ago. However, we never updated the draft online from our notes, so we lost all of that work. Great.

XMPP Clients

XMPP clients will need a way to ask another clients if they support receiving pushes via a relay. Since pushes can be sent from anywhere, clients will also be able to send pushes directly to other clients through the relay as long as they have their friend’s whitelist token. They will also need to respond to XMPP server inquiries for whitelist tokens to allow pushes to be sent by the server if a message is sent by a client not supporting direct push.

XMPP Servers

XMPP servers can ask their connected clients if they support push relays and, if so, forward messages they receive to the push relay server when the client is offline. This will require the XMPP server to obtain a whitelist token from the user as well.

Non-XMPP Clients

Because this method can bypass the XMPP server entirely, it allows for non-XMPP protocols to participate.

What Still Needs to be Done

We need to fix/finish our server draft spec and deploy a proof of concept XMPP server and push relay for the chatsecure.org domain. Additional work will also need to be done to integrate this for the ChatSecure clients.

There are many issues to be overcome, and there are very few developers who care about developing an interoperable standard because there is absolutely no financial incentive… and it is very difficult to do correctly. Proprietary messaging apps can get hundreds of millions in financing and large teams of engineers. We have to make do with much, much less.

Another big problem is that OTR is incompatible with this approach unless we use hacks to wake up clients to establish new sessions but, even if we do that, the messages won’t be able to be decrypted by multiple devices. The TextSecure protocol may provide some answers here, but they also haven’t solved the inter-app federation problem in a way that allows users to run their own backend or custom TextSecure clients.

Perhaps work should be directed toward extending the TextSecure infrastructure to support inter-app communication and federation instead of extending the aging OTR and XMPP protocols beyond their meaningful lifetime.

The Importance of SSL Pinning

Sat, 22 Feb 2014 00:00:00 -0800

You may have noticed there was a very important security update for iOS devices lately that patches a flaw allowing the complete bypass of certificate checks for any apps that use the default system-wide TLS library, Security.framework. There is a pretty good description of the vulnerability here, if you’re interested.

If you use the latest versions of ChatSecure you are now using a feature called SSL pinning that allows for you to manually inspect and remember the SSL certificates of the servers you connect to, bypassing the CA system entirely.

However, if you do not update to iOS 7.0.6 or higher and you are being actively MitMed, the alert dialog (pictured above) may provide misleading information in the form of a green ✓ instead of a red ✗ with the appropriate certificate error. This is because XMPPFramework’s socket library, GCDAsyncSocket, relies on Apple’s faulty SSL verification routine. Fortunately the displayed SHA-1 hash will still not match, so it is especially important to check the double-check the fingerprint of any new certificate before you store it.

It is especially important to update all of your devices as soon as possible because apps that don’t implement certificate pinning will not display any warning at all when your connection is compromised. Unfortunately most apps do not implement this functionality, including many banking apps.

Additionally, if you are using OS 10.9.1, please avoid using Safari (or other programs that use Security.framework) until this vulnerability is patched on OS X as well.

ChatSecure v2.2 Released

Wed, 22 Jan 2014 00:00:00 -0800

ChatSecure v2.2 for iOS was approved by Apple today. One of the main new features is support for SSL certificate pinning, to help prevent man-in-the-middle attacks. A nice side effect of implementing this feature is that we now support alternative root CAs like CACert.org, which now means jabber.ccc.de accounts should work properly. This also means that if you run your own XMPP server with a self-signed certificate, you should have less problems connecting and can now verify and pin the SHA1 hash of your certificate before connecting. @davidchiles crafted a beautiful and simple interface that appears for each new certificate, including information about whether or not the certificate would pass the built-in iOS certificate checks:

We also implemented another highly requested feature: you can now enable automatic login for your accounts. Coming soon is support for Tor, SOCKS5, and XMPP account creation (XEP-0077).

Notable Changes

XMPP: SSL Certificate Pinning
XMPP: Support for non-standard root CAs like CACert to support jabber.ccc.de
XMPP: Better support for self-signed SSL certificates via certificate pinning
Support auto-login for accounts
User interface improvements
Security improvements
Internal refactoring and code cleanup
Fix many crashes
Update 3rd party libraries
Full Changelog

Special thanks to @vitalyster for the UI patches included in this version.

Download

Download it for free on the App Store and check out the source code on GitHub.

Website Redesign

Thu, 09 Jan 2014 00:00:00 -0800

I decided to redesign chatsecure.org with Jekyll, a static blogging framework, combined with the very pretty Incorporated theme. If you find any mistakes, or would like to help improve the site, feel free to submit a pull request!

One major issue is that GitHub Pages doesn’t support SSL and, even worse, if you have a custom domain it will appear to be completely broken because their servers don’t respond at all on port 443 for custom domains.

New Servers!

Thu, 12 Dec 2013 00:00:00 -0800

It only took a year, but we have finally migrated to a new server and a super simple Django blogging engine instead of a giant template file rendered with Flask. Sorry about the lack of updates in the meantime! Next step will be to rewrite chatsecure.org to include information about the Android version as well.

ChatSecure v2.1.2 Released

Thu, 14 Nov 2013 00:00:00 -0800

Fix Facebook login issues
Fix non-Gmail Google Apps for Domain login issues
Fix issue with erroneous SSL validation error
Fix missing keyboard / chat input area
Fix crash when quickly switching between buddies
Fix 100% CPU usage bug

Full changelog

ChatSecure v2.1.1 Released

Mon, 11 Nov 2013 00:00:00 -0800

Localization updates
Fixes for delivery receipts
Fix OTR negotiation with ChatSecure-Android
Opportunistic OTR support
iOS 6 Sharing Sheet
Fix Facebook account disconnection crash
Fix QR code sharing
Fix XMPP SSL hostname mismatch and self-signed cert switches
Fix various UI bugs

Full changelog

ChatSecure v2.1 Released

Wed, 30 Oct 2013 00:00:00 -0700

Bug Fixes
Security improvements
iOS 7 UI improvements
Added OAuth Support for Google & Facebook
Fixes Facebook login
Updated localization
Fixed Core Data database migration from v2.0.1

Note: For Google and Facebook accounts you’ll need to reauthorize using OAuth instead of username & password

Full changelog

ChatSecure v2.0 Released

Thu, 20 Jun 2013 00:00:00 -0700

We are excited to announce the release of v2.0 of ChatSecure! There has been a major overhaul of the internals to use Core Data, which will allow us to make major improvements much more quickly in the future. Users have reported some instability with the current release, but it should be fixed in v2.0.1. You can help us track down bugs by opting in to automated crash reporting. You can also submit feedback directly to our UserVoice page, or if you’re feeling adventurous submit them directly to our Github Issues tracker.

What’s New in Version 2.0

New UI design
Updated translations
Major internal changes that will make the app easier to improve in the future
Add buddies
Search buddy list
Groups
View buddy info on long press

Free Download (changelog)

ChatSecure v1.5 Released

Thu, 13 Dec 2012 00:00:00 -0800

In November we added Tibetan translations, better fingerprint verification UI, and added an in-app language switcher. We also introduced a crash-on-launch bug that affected certain locales. This should be fixed in v1.5.1.

More/updated localizations merged into the app
Tibetan translation now works
Improved fingerprint verification user interface
In-app language switcher for changing to languages not supported by the OS (e.g. Tibetan)
v1.5.1 Fix crash on launch bug and localization switcher

Free Download (changelog)

ChatSecure v1.4 Released

Mon, 05 Nov 2012 00:00:00 -0800

In October we finished up v1.4 which includes XEP-0184 (delivery receipts), XEP-0085 (chat state) and a redesigned login screen. We have also been working on privacy-minded solutions to the lack of push messaging support (ChatSecure Push Server) as well as additional avenues for backgrounded sockets.

XEP-0184: Delivery receipts. This feature is in Gibberbot as well, which allows for clients to be notified when their messages are received by the other chat participant.
XEP-0085: Chat State. This feature allows users to see when other people are typing a message, and gives them the option to send those notifications as well.
Redesigned login screen: Completely refactored the login screen to be more extensible in the future. We also added a port field for custom XMPP servers.
ChatSecure Push Server: A working proof-of-concept server has been built, and we are now working on client integration, as well as other options to allow for long running background sockets.

Free Download (changelog)

ChatSecure v1.3 Released

Mon, 24 Sep 2012 00:00:00 -0700

What’s New in Version 1.3

Multiple simultaneous account support! (Facebook, GTalk, AIM, XMPP)
Option to remember account passwords in iOS keychain
User interface improvements
Many, many bug fixes
Upgrade to libotr 4.0.0
iOS 6 and iPhone 5 support
Removes support for armv6 devices and now has a minimum requirement of iOS 4.3. Sorry!

Free Download (changelog)

v1.3 Status Update

Fri, 10 Aug 2012 00:00:00 -0700

A number of changes have been committed to the master branch since the last status update:

The refactoring required for multiple account support is almost complete.
Global XMPP SSL certificate verification preferences have been removed and have been replaced with per-account settings. (Thanks to Chris Gahan for mentioning it before it was ever a problem)
Currently there is no UI for relaxing the cert checks anymore, but the underlying code is in place. This will need to be hooked up toOTRLoginViewController and tested thoroughly before v1.3 submission.
Some UI elements have been simplified or merged into other views.
The Conversations view (only available on iPhone) has been eliminated and has been replaced by an editable “Recents” list at the top of your Buddy List on both iPhone and iPad.
Adding accounts is now done directly from the Settings screen.
Fixes have been made to the logic for when to show message notifications
It also doesn’t crash anymore when trying to reply under certain scenarios
Support for sharing a link to the App via Twitter on iOS 5 and higher.

There are still some issues related to not properly downgrading back to plaintext aftercancelinga secure conversation that need to be fixed before the next update as well. Once that is figured out, we should be on track for submission to the App Store very soon!

ChatSecure v1.3 Progress

Tue, 31 Jul 2012 00:00:00 -0700

I have been mainly working on UI / usability improvements and trying to iron out some persistent bugs. Here are the things that still need to be done before the 1.3 release:

Figure out how to properly downgrade conversation to plaintext (Ian’s explanation on the otr-dev mailing list wasn’t clear to me, so maybe Miron could be of help)
Hopefully this will fix the “missing messages” bug.
Rigorously test the security of the new password storage mechanism (uses iOS keychain)
Make the XMPP SSL certificate-checking options (hostname mismatch, or allowing self-signing) per-account, rather than global, and only for custom XMPP accounts.
Implement SSL cert verification if possible.
Fix the “multiple conversations with the same buddy” bug.

We have a Mailing List

Tue, 10 Jul 2012 00:00:00 -0700

We now have a Google Group for public discussion about the app. Feel free to join!

In other news, we are moving ahead with multiple account support and better UI integration with other XMPP services like Facebook, Jabber, Google Apps, and custom servers. Expect v1.3 to be on the App Store in the next few weeks. We are considering dropping AIM support in a future release because the LibOrange library seems to be dead. If you still use AIM and would like to see it kept in the app, please make your voice heard!

Also, if have a paid iOS developer account and are looking for longer-running background support, check out the background branch on Github.

Version 1.2 Approved

Thu, 07 Jun 2012 00:00:00 -0700

I would like to announce a partnership with The Guardian Project, who develops the Android equivalent of ChatSecure called Gibberbot, along with a whole suite of mobile security applications. It’s an exciting time for open-source secure mobile communications!

Version 1.2 has been approved! This new version includes support for limited background messaging, the #1 most requested feature. Yay!

Background Messaging

Unfortunately, Apple’s policies prevent the creation of secure chat applications that run in the background indefinitely. The only way to get backgrounded sockets on iOS is to register your app as “VoIP”, but unless you actually implement VoIP services, you will get rejected from the App Store. A common workaround used by other chat programs is to run the real chat client server-side and run a “push service” that sends the messages to your phone. That approach is unacceptable for this app because it would require me to build my own push server, which comes with quite a few drawbacks:

Centralized storage of login credentials
Single point of failure
Vulnerable to eavesdropping
Expensive to build and maintain
Maximum size allowed for a notification payload is 256 bytes, and is “best effort” and not guaranteed.

The only other option is to ‘trick’ the OS into continuing to run the application in the background by starting a “long running task” during the applicationDidEnterBackground: in your app delegate, which in this case is an NSTimer set to fire every 10 seconds or so. The main limitation to this approach is that unless you manually restart the app every 10 minutes, it will be force-closed by the OS. This is similar to the technique used by the awesome Verbs app, who graciously helped me tackle this problem.

Version 1.2 Submitted

Tue, 08 May 2012 00:00:00 -0700

First post!