Client-Server Instant Messengers (IM)

Development
1

The level of security and anonymity an instant messaging platform provides should be the ultimate criteria for deciding which one to use. Practically speaking, not all of your counterparties will have the necessary motivation or technical skills to implement the various options and you may have limited leverage in convincing them to switch platforms.

While mobile encrypted chat platforms are increasing in popularity, and while they may offer secure transmission of content; it is difficult to be confident that your anonymity is protected given the numerous fingerprinting and tracking methods used by iOS and Android. Additionally, many of these platforms are closed-ecosystem if not closed-source.

If you require a widely-adopted, reasonably anonymous solution, then your only option is to use a platform based on OTR. You must understand that OTR is a server-based protocol and as such, exposes significant metadata to the server. [It is possible to run your own XMPP server - even better if itā€™s hosted on your own hidden service and better still if all of your contacts register on it - but this is not trivial to set up securely and anonymously.]

Youā€™ll need to choose an IM client that supports OTR. In parentheses is the name of the XMPP/OTR implementation followed by the language that itā€™s written in. Youā€™ll notice a pattern with some popular clients listed first:

Pidgin (libpurple, C): One of the most popular cross-platform desktop IM clients. It is unsafe given its track record: https://pidgin.im/news/security/

Adium (libpurple, C): As noted by @HulaHoop, Adium has also had a buggy past, for largely the same reasons as Pidgin. The developers have also been negligent when it comes to privacy issues.

Empathy (libpurple, C)
InstantBird (libpurple, C)

libpurple has roots going back to 1998 and AOL Instant Messenger. It is huge because it supports 14! messaging protocols out-of-the-box. Coupled with the fact that it is written in C/C++, which is relatively less safe than higher level languages, one would expect a fair number of memory-corruption bugs - and history has not disappointed.

The next generation of IM clients tend to use memory-safe languages and modular protocols.

CoyIM (xmpp/otr only, Go): Client-Server Instant Messengers (IM) - #11 by entr0py

Gajim (xmpp/pure-python-otr, Python): Client-Server Instant Messengers (IM) - #9 by entr0py

Tor Messenger (xmpp/libotr only, JavaScript): Client-Server Instant Messengers (IM) - #10 by entr0py. Stable release 6 months behind schedule and many important issues are still unresolved.

Kopete (modular, C++) / Telepathy: heavy KDE dependencies
Jitsi (multi-protocol, Java)

OTRā€™s shortcomings include lack of group chat functionality, no asynchronous communication, and prior to V3, lack of encrypted file transfers. The Signal Protocol was developed to address these issues and is gaining acceptance on mobile platforms via closed (non-federated) ecosystems such as Signal, Whatsapp, and Facebook Messenger. [Of course, maintaining anonymity while using a mobile platform is a challenge of a different magnitude, if possible at all.]

OMEMO is the Signal Protocol adapted for XMPP. (audited). It is currently implemented in Android via Conversations and ChatSecure, and on the desktop via Gajim. Support on other clients, like Jitsi, is forthcoming. (Itā€™s also on Tor Messengerā€™s to-do list.)

Like OTR, OMEMO suffers from metadata exposure. However, with the possibility of asynchronous communication, itā€™s no longer necessary to remain logged on at all times nor is it required to schedule chats using an out-of-band channel. Since neither protocol supports the ā€œinvisibleā€ status, itā€™s advisable to strengthen your own anonymity by using a separate XMPP account per contact and also by using Whonixā€™s stream isolation feature to ensure that each contact receives a new Tor circuit. OMEMO is not backward compatible with OTR so your contacts will need an OMEMO-supported client.

On the other hand, if all parties are willing to make the required effort, more privacy can be achieved by using a decentralized platform, such as I2P-Messenger, Ricochet IM, or Tox. See the wiki for more information: Instant Messenger Chat

EDIT: Updated client list.
EDIT: Added note about mobile chat.

3 Likes
2
  • Odd fact: signal (android app) does not work on a phone without google installed. Requires google services to run.

Sadly true. I have given up on this for outside of software fans / security minded groups.

OTF: even a geek and security minded friend of mine does not want to use OTR, because it does not allow to go online/offline. Always messed up the state, always messages are lost.

3

Good day,

Well, looking at their source code, they appear to mainly use it for ā€œProGuardā€, which is a solution developed by Alphabet to prevent reverse engeneering of certain functions, as well as optimize the code of an App. Whether this makes sense in an OpenSource-Program thoughā€¦

Source: Signal-Android/proguard-google-play-services.pro at 0a569676f7a57144374a24faef566b2ca3233290 Ā· signalapp/Signal-Android Ā· GitHub

Have a nice day,

Ego

1 Like
4

Nice write-up. A few thoughts:

Adium is ancient, has a ton of bugs and the devs are pieces of shit. Bradley Manning was convicted because they turned chat logging on by default. When this was pointed out to them they said they donā€™t care and didnā€™t change this.

I2P-Messenger is defunct AFAIK. Has it seen a new rewriting effort?

Although a work in progress Tor Messenger has a very important usability/security feature called CONIKS. This is a publicly auditable record that ties a userā€™s OTR fingerprint to their IM address which means that normal people no longer have to confirm fingerprints to start chatting securely.

EDIT:

@entropy please feel free to add to the chat page the stuff you researched.

1 Like
5

Your friend is probably using Signal! :grinning:

ICYMI LibreSignal was Signal without Google. Until Moxie Marlinspike killed it with this comment. One day when I had way too much time on my hands and was in need of my nerd-drama fix, I read nearly all zillion pages of that thread. Iā€™ll spare you from having to do the same.

At the risk of presuming to know what motivates Marlinspike personally (and without knowing much of his life story), the thread sounded a lot like the age-old tale: Revolutionary gets old. Revolutionary gets rich. Revolutionary wants mass market acceptance. In all fairness, however you feel about moxie0ā€™s present level of idealism, itā€™s hard to deny that there is truth to his contention: that software that gets most of the technical details right that gets used is better than software that gets all of the technical details right but doesnā€™t get used.

Some of moxie0ā€™s points are best stated using his own words:

Besides allowing for simple identifiers (like phone numbers), non-federation has major benefits:

XMPP is stuck in time. Making any changes to a federated protocol is very difficult, which is why it still resembles the late 1990s. Itā€™s also why weā€™ll never have usable end to end encrypted email. Services that control their own clients and infrastructure can iterate quickly, federated clients and servers can not.

On distributed communications:

Weā€™re trying to make mass surveillance impossible for the world we live in, not a fantasy land inhabited only by cryptonerds and moralists. This is the world we live in: people do most of their communication on mobile devices running iOS or Android, use Chrome on the desktop, and expect contact discovery to be automatic in their social apps. The browser has won the desktop, iOS and Android have won mobile, and the velocity of the ecosystem is unlikely to make ā€œdistributedā€ communication mechanisms possible for some time.

:frowning:

And a nice reply from eighthave of the Guardian Project:

@moxie0 We at Guardian Project applaud your work at making crypto easier to use, but donā€™t forget we are targeting different problems. As you said, Whisper Systems only cares about mass surveillance. We are definitely focused on targeted surveillance as well. Add in federation to the equation as an essential piece to circumvent blocking, and that makes it a lot harder to make easy-to-use software. ChatSecure works in China, which is part of the reason why we are funded, while Signal has been blocked for a while, and most devices there do not have Google on them. Federation is an important part of why ChatSecure still works in China. If you focus on the easiest part of the problem, then it becomes a lot easier to focus on a simple user experience. Focusing OWS on countries that donā€™t block internet services, avoiding mass surveillance, and requiring Google makes your problem space a lot smaller.

Perhaps, itā€™s agreeable enough to say that everyone has their own problem space that they are trying to resolve. As long as projects donā€™t misrepresent themselves or set unrealistic expectations, itā€™s fine to have solutions to different problems.

1 Like
6

The Signal client is open-source. Portions of the Signal server are not open-source. In particular, the portions written by the NSA. (joke!) Itā€™s not very clear why. But it wouldnā€™t really matter since Open Whisper Systems runs all the servers and could change the running code to some extent. This brings up another issue with Signal, besides the fact that it runs on iOS/Android. Here we have Privacy by Policy - their claim that they only keep limited metadata - that is difficult to work around. With OTR, I can simultaneously have 20 accounts on 20 different XMPP servers on 20 Tor circuits - not sure if thatā€™s possible with Signal.

Google Play services are used as a convenient delivery mechanism and most importantly, for Google Cloud Messaging (GCM) - the notification engine. AFAIK it is possible to install Signal on a rooted phone using F-Droid and also possible to avoid GCM by installing GmsCore. Signal also accepts registrations coming from VOIP numbers, which should open up the program to Android emulators. [Still too many unknowns with Android and Signal servers for my paranoia.]

@HulaHoop pieces of shit noted. Will update OP and add task to my wiki list. :wink: Also, any comments regarding the little bit about hosting your own XMPP server? Obviously, itā€™s better for you than your contacts but any obvious deficiencies? Is there inter-server leakage when all activity (registration and messaging) occurs on one server? It could be a decent workaround when a paranoid Whonix user needs to communicate with OTR-only contactsā€¦

2 Likes
7

I think youā€™re right. Is it just me or is all the I2P documentation stored on .i2p servers? I canā€™t find any information from the outside.
@goldstein Can you confirm?

Also, I added a blurb on coyIM then saw your old thread about it + Moxie dick moves:
A secure replacement for Pidgin
Will pull info from that thread. Maybe a table is in orderā€¦

2 Likes
8

I think a good rubric for recommending IM programs is:

*Written in a type safe language
*Encryption is the built-in default not a plugin
*The code is audited

Bonus points:

*No metadata collection possible
*PQ Crypto
*OMEMO support

2 Likes
9

Gajim Notes:

  • Gajim, plugins, and libraries written in Python (all unaudited)
  • OTR plugin is not installed by default; can be installed manually or by using ā€¦
  • ā€¦ Plugin Installer (v0.11.40) that leaks DNS and ignores Gajimā€™s global proxy setting.
  • plugins are not signed - but only relevant for OTR plugin because ā€¦
  • releases of gajim, python-potr, gajim-omeemo, and python-axolotl included in debian repos
  • python-axolotl is a close 1:1 port of audited libaxolotl-android
  • easy omemo setup: apt-get -t jessie-backports gajim-omemo
  • no manual certificate pinning (use .onion servers or trust PKI)
  • easy stream isolation of contacts accounts
  • separate setting for ā€˜Log encrypted chat sessionā€™ā€¦ but itā€™s enabled by default.
  • metadata / environment leaky options enabled by default (can be disabled)

Note on XMPP Privacy from https://securejabber.me/en_security.html:

XMPP was designed long time ago without anonymity kept in mind. Depending on the capabilities of your XMPP client it may leak some sensitive information about your software configuration such as the time on your machine, your timezone, geolocation (XEP-0080), version of your operating system and version of your XMPP client. Some XMPP clients can also download a content (pictures, files) authomatically that may be used by attacker to reveal your IP address. Thus, if anonymity matters for you, it is always better to run XMPP client inside some virtual operating system (on virtual machine), that doesnā€™t share its software configuraton with your main operating system.

1 Like
10

Tor Messenger (v0.2.0b2):

  • written in JavaScript and based on mature InstantBird code
  • OTR enabled by default
  • not in Debian repo, but has signed portable installation and built-in updater
  • clumsy interface, wrt account connectivity
  • only global status options (canā€™t set per account)
  • has fewer user-configurable privacy options (compared to pidgin, gajim). Hopefully, thatā€™s because theyā€™re all set to safe defaults.
  • default has no stream-isolation: Enable stream isolation (#14382) Ā· Issues Ā· Legacy / Trac Ā· GitLab. Whonix + Tor Messenger has stream isolation per xmpp server because port 9152 has IsolateDestAddr on Whonix-Gateway. Multiple accounts on same server will share circuits. Needs per-account proxy settings as is common on other chat clients.
  • flexible OTR fingerprint verification + future CONIKS
  • still WIP so things like interface and customizability likely to change
1 Like
11

CoyIM (v0.3.7):

wow.wow.wow. Love what Iā€™m reading here: https://coy.im/about/
These guys are our kindred spirits. If coyIM does what it says it does, Tor Messenger is dead-on-arrival.

Iā€™ll mostly just be repeating whatā€™s on their About pageā€¦ so whatā€¦ itā€™s good.

  • new release yesterday. previous release 2 months ago. active development.
  • written in Golang.
  • supports one protocol (xmpp).

The goal of CoyIM is not to have every feature under the sun. Instead we want to carefully pick and choose the features that are necessary to create a good chat experience, while keeping the attack surface of the system to a minimum.

  • built-in OTR enabled by default. Tor enabled if present. (confirmed using netstat - port 9050).
  • ! automatically connects to onion version of xmpp server if it exists (confirmed)
  • ! automatic stream isolation of accounts (confirmed using onioncircuits: two accounts on same server going to same dest address and port were routed over different circuits. ?using IsolateSocksAuth like Tor Browser?)
  • (probably not a long enough delay to matter but itā€™s a nice touch)

If more than one account is configured, when connecting CoyIM will insert random delays before connecting to each account, in order to make fingerprinting of connections between accounts harder

  • yellow banner on top of home page indicating unaudited. nice transparency.
  • optionally encrypted config files
  • safe defaults
  • all dialog options explained clearly on the dialog
  • blob is signed. navigate to download directory for sigs

On their wishlist:

  • disposable one-click xmpp accounts
  • reproducible builds

Blacklisted features:

  • hyperlinks
  • browser views
  • emoticons!
  • less config options are better
  • logging, maybe (personally, I wouldnā€™t mind having this)

Issue tracker looks pretty clean. Mostly UX stuff. Some tickets worth watching:

Audit Progress: Audit CoyIM Ā· Issue #297 Ā· coyim/coyim Ā· GitHub
Mandatory OTR: Make OTR mandatory Ā· Issue #270 Ā· coyim/coyim Ā· GitHub ; coming next release
Debian packaging: Add deb packaging Ā· Issue #260 Ā· coyim/coyim Ā· GitHub ; coming days timeframe
Fedora packaging: Easy CoyIM install on Fedora Ā· Issue #197 Ā· coyim/coyim Ā· GitHub ; also coming soon
Sandboxing: Sandboxing Ā· Issue #108 Ā· coyim/coyim Ā· GitHub ; leaning toward seccomp but apparmor also mentioned

This seems like a no-brainer for Whonix 14!

EDIT: I need to re-test the isolation using non-hidden services. I know streams going to different HS are isolated from each other. (per [tor-talk] hidden services and stream isolation) Iā€™m not sure if multiple streams going to same HS share circuits or not.

EDIT2: re-tested with non-onion jabber servers and stream isolation still works. fyi coyIM wonā€™t allow connections to clearnet servers if an onion server exists.

12

Also, EFF will be releasing their new Secure Messaging Guide soon:
https://www.eff.org/secure-messaging-scorecard

Version 1.0 was ratherā€¦ weak:

Recognizing that unpublished audits can be valuable, we do not require that the results of the audit have been made public, only that a named party is willing to verify that the audit took place.

Hmmā€¦ (those private audits also included closed-source apps).
Translation: ā€œTrust us when we say that our audit (which no one has seen) says that this program has solid code (which no one has seen).ā€

1 Like
13

Good day,

Wait what?! SO THEY DIDNā€™T EVEN REQUIRE RELEASING THE RESULT?!?! What purpose does that serve?

I can only think of this one:

Source: xkcd: Clinically Studied Ingredient

Actually, if the RESULTS (still canā€™t get over that part) arenā€™t even required to be released, even that translation is to good. That XKCD fits really perfectly for this.

Have a nice day,

Ego

2 Likes
14

Had a closer look at gajim because gajim and a gajim OMEO plugin are installable from packages.debian.org. Here are the notes that came out of it.

Instant Messenger Chat

Great stuff in this thread!

FYI unmessage. Had quite some discussions with its developer recently. They even added experimental VoIP support recently!

How to their encryption features compare to OTR and/or OMEMO?

They use the same circuit unless they are using a different SocksPort or socks user name.

15

ricochet does not use an inside application encryption layer. The only encryption is the one used by Tor onions. Therefore it does not provide OTR like encryption features. Maybe not catastrophic but also not great. Source:

unMessage uses stronger encryption, Double Ratchet Algorithm for in application encryption, which is similar to OMEMO (which is similar to OTR). More details:

1 Like
16

The ā€˜Wireā€™ chat is created by Estonian ex-Skype mastermind (pre MS takeover) announced that they will opensource both client and server code. Multiple code audits over time show they are improving their codebase. The most recent by JP Aumasson (who uncovered bugs in Signal) confirms its robust crypto implementation. IM protocol uses Moxieā€™s ratchet. VoIP recently became E2E encrypted otherwise past notes say its RTP with SRTP. E2E encrypted group VoIP planned which no other major client has:

RTP is usually UDP based. Now that they are open source we can potentially ask for a TCP implementation like they did for Skype before. Maybe suggest Tor support too.

Licensing:

Server still has some proprietary components as of now (April 2017) but opening it up.

Both components client and server are released under strong copyleft licenses. However I noticed there are extra restrictions on client modification if the derivative app wants to connect to the Wire company server - that seems normal considering projects like Signal even forbid this from happening at all. They are aiming for a federated network anyhow so this restriction is less problematic long term.

Another point is contributions must happen under a CLA. Looking thru it: it seems a defensive agreement to make sure no one can abuse patents against them, copyrights are co-owned between contributors and them, promises that any contributions will be kept under an OSI or FSF license. Sounds reasonable.

1 Like
17

Relevant tickets:

https://f-droid.org/forums/topic/please-add-wire/

1 Like
18

Updates:

  1. When UDP not possible it falls back to TLS/TCP
  2. PQ Crypto considered too new for implementing by them
1 Like
19

Some progress on gajim was made. gajim has a separate thread:

https://forums.whonix.org/t/gajim-messenger

20

Odd fact: signal (android app) does not work on a phone without google installed. Requires google services to run.

Thereā€™s more. I have a few online friends who keep dragging me into signal. But my main problem isnā€™t signal requiring google (which Iā€™m not a fan of, for obvious reasons). My problem is that I donā€™t own a cellphone at all. I was glad when the users won the Linux battle on PC, but very sad when they lost the whole war by surrending to iOS/Android on their shiny smartphones. Most likely I would not buy a phone until it will be possible to install a standard Linux distribution on it, like I can do on my PC. I did a very superficial search online and it looks like signal also has a desktop app. Yet, to register an account, one still needs to have a phone to receive some authorization code to it. I would be glad to hear your feedback on this if you have anything to add.