Freedombone Blog

Freedom in the Cloud

Dark Messenger 1.3

Emerging from the murky depths of the interwebs like a low-budget B-movie monster or something out of a 1970s Dr Who episode is Dark Messenger version 1.3.

This version is based on the latest Conversations XMPP chat app and has an added usability feature for initial setup. On the screen where you are first asked to enter your account details there is now a QR code button. If you have your onion JID as a QRcode, as it exists in Freedombone on the members screen, then you can scan it with your phone camera and the address and hostname fields are then populated automatically. This saves any fiddling around switching between apps, or trying to type long random addresses manually. The only thing you then need to do is enter the account password.

Top of the screen showing QR code button

Dark Messenger is a version of Conversations restricted to using onion address based XMPP accounts. This makes opsec snafus much harder to commit, and always ensures that the metadata is protected from passive surveillance. "Just say no" to letter agency spooks and other random interweb flotsam. No Certificate Authorities are involved in the running of this app.

Dark Messenger will not get rid of the nubs.
Dark Messenger will not make you look five pounds thinner.
And it's available in no app store anywhere.

But you can download it from here.

Adding Padding to OMEMO

I've enabled OMEMO padding within DarkMessenger. This regularizes the message lengths to a minimum of 64 bytes, and thereafter quantized in chunks of 32 bytes. If you are a passive adversary listening on the wire then regardless of how random-looking the cyphertext may be, message lengths still reveal some (probably small, but not zero) amount of information about the conversation. It may be possible to use small and common messages, such as "hi" or "ok", or common emojis, as cribs to then begin to attempt decryption. Having a minimum message length and quantized plaintext lengths removes that as a possibility such that from the passive "bulk surveillance" point of view messages all look quite similar and are harder to track through multiple onion unwraps.

OMEMO padding was a patch I submitted a few years ago, but because it's not in the XEP it never made it into production. A random sequence of spaces and tabs are added before the beginning and after the end of every message such that its length becomes a multiple of 32. On the receiving end the plaintext is trimmed to remove the padding. This has the advantage that even if the message "hi" is being sent an adversary doesn't necessarily know where within the 64 byte padded string the text begins.

The new DarkMessenger version (1.1.00) can be downloaded here.

The rush to TLS

Issues which I've been encountering recently with XMPP are all about TLS and differing threat models. It seems as if LetsEncrypt has been around for ever, but really it has only been usable in the last two or three years. During that time an increasing number of internet applications just assume that TLS authentication is in place.

Before LetsEncrypt XMPP servers typically allowed self-signed TLS certificates or no certificates. Recognition by Certificate Authorities (CAs) wasn't mandatory. But increasingly now it is. This is all fine except in cases where you don't need TLS or where Certificate Authorities are untrusted and belong in the threat model. That's usually the case if you're running XMPP on onion addresses. After all, CAs include numerous dodgy companies and entities like the Chinese government.

So if you're setting up an XMPP server with the intention of using both clearnet and onion addresses then there's a conflict of interests between the two routing worlds. The clearnet would like CA-recognized TLS certificates to always be used. The onionspace would prefer that to be optional or not present.

In the rush to implement TLS everywhere, and thereby secure the internet from the evildoers, minority use cases like onion routing have been forgotten about and there isn't a clear solution if you want to inhabit both worlds.

As a workaround I've added a settings screen for the XMPP app within Freedombone which allows TLS authentication to be strictly enforced or not.

Matrix addendum

There has been a recent talk about Matrix at FOSDEM 2019 in which it's said:

As of Matrix 1.0, we require homeservers to present a CA-signed TLS certificate

So very much the same problems are going to apply to Matrix on onion addresses quite soon. Probably the version of Matrix on onion-only versions of Freedombone will need to be modified in order to federate, and will be non-compliant with the spec. If that's infeasible then it might be that Matrix on onion will only be non-federating, which would be disappointing.

Addendum addendum

It looks like Matrix will be ok after all. In the recently published federation API it says:

The TLS certificate provided by the target server must be signed by a known Certificate Authority. Servers are ultimately responsible for determining the trusted Certificate Authorities, however are strongly encouraged to rely on the operating system's judgement. Servers can offer administrators a means to override the trusted authorities list. Servers can additionally skip the certificate validation for a given whitelist of domains or netmasks for the purposes of testing or in networks where verification is done elsewhere, such as with .onion addresses.

Dark Messenger

Recent testing of the Conversations app with an XMPP server running on the onion-only version of Freedombone revealed that it no longer worked. This was strange because for the first few years of development of the server system I used this as a test case, having messages go back and forth between a phone and a laptop using the onion server and no clearnet.

I think what has happened is that within the last year or so enforcement of TLS within XMPP clients has become stricter and can no longer be easily bypassed or turned off. While LetsEncrypt is a great thing if you're not using the clearnet then the imposition of strict TLS can become a problem leading to bad or in this case broken user experience. It's yet another example of how minority use cases sometimes get disregarded.

The changes needed to get the app working with an onion-only server again are fairly minor but unlikely to be upstreamed. So I've made a fork of Conversations dedicated to messaging using onion addesses, called Dark Messenger. Dark as in darknet or "going dark". Most of the effort was actually just changing the branding to distinguish it from the main Conversations version. You can run the two apps on the same phone without any interference if necessary.

dark messenger on a mobile phone

The dove is a CC0 icon and it symbolizes peace and reconcilliation. Also there is the dove in the biblical flood story who brings back the olive leaf as a sign that refuge was close at hand.

Noah then sent forth a dove, which returned the first time without good news; but the second time, she brought an olive leaf in her bill, plucked off, plainly showing that trees, fruit trees, began to appear above water.

Not exactly instant messaging, but a sort of message bringer during times of hardship.

Dark Messenger can be downloaded as an installable apk or as source code from the downloads section and the development repo is here. You won't find it on any app store.

There are various advantages to this kind of setup, and it's hard to accidentally send anything insecurely. In the longer term Briar might become a better option, because it doesn't need any servers.

XMPP Notifications

Another of the features I'd wanted to add to Freedombone for a long time was server notifications via XMPP, and now that has been added. This is for things like notification that an upgrade or security test has failed or that the tripwire has been triggered. Previously those notifications were only via email, but I'm not very obsessive about email and rarely check it, whereas instant messages are much more likely to get my attention.

The security policy for XMPP chat was previously set such that end-to-end security was required, but it was difficult to automatically send out an OMEMO encrypted message from the server and so I've had to downgrade end-to-end security to being optional. This is not ideal, but the tradeoff between having to deal with folks trying to send me plaintext messages and being promptly alerted if something has failed on the server is probably worth it. Longer term I'd like to figure out if I can automatically generate OMEMO messages and then I can return to a better security policy.

The main factor which delayed the implementation of this was the question of needing to generate a separate XMPP account on the server to push out notifications. I didn't really want there to be a permanent separate account with a password lingering around somewhere which could become a possible security vulnerability. The solution to this was to generate an ephemeral account purely for the purpose of sending a single message. A new notification XMPP account gets created with a random password, sends the message and then about one second later the account is deleted. Even if the account credentials were to leak during the sending of a plaintext message they can't subsequently be useful to a potential adversary.

Another addition to the notifications system is being able to send a webcam photo if the USB canary is triggered. The purpose of that is to answer the paranoid question "Is anyone trying to mess with the server while I'm not at home?" if you're out shopping or at work. The particular threat model is known as evil maid. If you're running Freedombone on an old laptop and have a secondary webcam plugged it it will preferentially use that, so that you can set up the field of view appropriately. Not many people will need this level of physical device security, but it's nice to have the option. Also if you have the Syncthing app installed then any USB canary photo will be synced to the admin account.

End-to-End Policy

Another thing changed recently on the XMPP configuration within Freedombone is the end-to-end security policy. Previously if you posted anything without encryption there would be a big scary and usually also noisy warning notification telling you to do better. This is ok for private one-to-one chats, but not for public multi-user chats such as channels used for open source projects.

So I did a little tweaking and now either OpenPGP or OMEMO are required for one-to-one chat (if you try anything else it will just fail) and there is no encryption requirement for multi-user chat. So you won't get any annoying alarms when posting to multi-user chats. You can of course still do encrypted multi-user chat if you want to, it's just not a strict requirement enforced by the server.

I now find that using XMPP with Conversations on Android is actually a nice experience with very little friction. The cryptostuff all seems to "just work", and there is no possibility of accidentally sending an unencrypted private message as there was before. As of Conversations 2.1 OMEMO encryption is now the default, so you don't need to be concerned about turning it on.

Also in cryptostuff-related news I noticed recently that the Tor daemon on my server was struggling and that apps were not accessible via their onion addresses. This happens occasionally, because Tor is not a perfect system. Relays appear or disappear. Guards change. Systems are attacked and defended. It would be nice to know when these outages are occurring though, so I've added a watchdog to monitor the health of the Tor daemon and report any changes in status via email. So now just by reading your email you can know whether there are any Tor problems happening. In future I'd like to integrate this with XMPP, because that might be more useful. I don't read emails all that often.