1,5 Jahre XMPP und warum ich es nicht mehr nutze

Vor 1,5 Jahren – fast genau zum Jahreswechsel 2015 / 2016 – begann ich, XMPP (Extensible Messaging and Presence Protocol) zu nutzen. Zunächst nur via Profanity, später auch via Conversations und kurz Gajim.

Nachfolgend ein kurzer Erfahrungsbericht und meine Meinung.

InhaltsĂĽbersicht

  1. XMPP als „Klassiker“ im Messengerbereich
  2. HĂĽrden und Vorteile, die nicht wirklich welche sind
  3. Der Bezug zur Informationssicherheit
  4. Zusammenfassung
  5. Nachtrag
  6. Changelog

XMPP als „Klassiker“ im Messengerbereich

XMPP gibt es bereits seit 2004 unter diesem Namen bzw. fünf Jahre länger als „Jabber“ und wird fälschlicherweise alleine deshalb von einigen Leuten mittlerweile als „altmodisch“ angesehen. Interessanterweise bildet XMPP aber die Grundlage von WhatsApp, was von Milliarden von Menschen täglich genutzt wird. Andere Implementierungen wie Google Talk oder Facebook haben XMPP nach einer temporären Nutzung wieder verlassen.

Immer auf aktuellem Stand bleiben?
Abonnier uns via RSS/Atom.

Eher ist ein Trend zu beobachten, dass Firmen ihre eigenen Nachrichtenprotokolle erstellen, um ihren Nutzern ein möglichst hürdenloses Benutzererlebnis zu ermöglichen. Dies hat zur Konsequenz, dass „Walled Gardens“ entstehen. Benutzer können folglich nur miteinander kommunizieren, wenn sie bei demselben Anbieter sind, aber nicht mit Nutzern anderer Anbieter ohne dort auch ein Konto anzulegen.

HĂĽrden und Vorteile, die nicht wirklich welche sind

Genau diese Hürden, die man durch geschlossene Plattformen niedrig halten will, findet man aber bei XMPP: Je nach Client (eine freie Wahl hat man nicht wirklich, siehe später) und genutztem Server variiert das Benutzererlebnis stark. Wenn man „Glück“ bei seiner Wahl hatte, funktionieren die gewünschten Features, wenn man „Pech“ hatte, funktioniert unter Umständen lediglich unverschlüsselter Einzelchat.

Das ist gewiss keine Schuld von XMPP, aber eine Realität, die man nicht verleugnen sollte. Ein neuer Nutzer muss sich erst einmal Gedanken machen, welche Clients auf seinem Betriebssystem funktionieren und ob diese Clients erwartete Funktionen unterstützen und dann hört es nicht auf. Nicht zuletzt muss er nämlich auch noch auf die Serverfeatures schauen.

XMPP-Server und Föderation, die nichts bringt

XMPP unterstützt Föderation. Unabhängig vom Client und Server können sich alle XMPP-Nutzer gegenseitig Nachrichten senden und empfangen. Die Idee dahinter ist, dass man ein offenes Netzwerk hat. Dies ist in gewisser Weise nicht so anfällig für staatliche Eingriffe wie Zensur und auch ein staatlicher Beobachter muss ein bisschen mehr tun, um Überwachung durchzuführen. Auch wäre es nicht schlimm, wenn ein gewisser Prozentsatz des Netzwerkes ausfiele.

Tatsache ist aber, dass dieses Föderationskonzept bei XMPP unzureichend zum Einsatz kommt. Genau wie im Diaspora-Netzwerk konzentrieren sich die meisten Nutzer auf wenige Server. Gleichzeitig gibt es sehr viele Server, die verhältnismäßig kaum Nutzer haben. Die Folge ist, dass die Nichtverfügbarkeit (sei es gewollt oder ungewollt) einer dieser stark genutzten Server die Verwendung von XMPP für Betroffene unmöglich macht. Ein Beispiel ist hier ein DDoS-Angriff, der jabber.at betraf. Dies ist bei geschlossenen Systemen (Beispiele gibt es genug) wesentlich schlimmer, allerdings kann man davon ausgehen, dass eine Firma, die ein solches geschlossenes System betreibt und damit Geld verdient, ein starkes Interesse hat, diese Nichtverfügbarkeit entweder zu verhindern oder auf ein Minimum zu beschränken.

Im Fall von XMPP-Servern begibt man sich in die Hände von Einzelpersonen oder Institutionen, die ihre Dienste „spendenbasiert“ oder nach einem anderen Finanzierungsmodell zur Verfügung stellen. Im Umkehrschluss heißt das, dass jederzeit Server abgeschaltet und eingerichtet werden können und auch werden. Hat man hier wieder „Pech“ und nutzt einen Server abseits der gut besuchten, kann es sein, dass man später wieder umziehen muss.

Daneben gibt es noch weitere Probleme: Als potenzieller XMPP-Nutzer kann man nicht einfach einen beliebigen XMPP-Server nutzen, sondern teilweise verhindern die Server gewisse Clientfunktionen wie HTTP-Upload. Daniel Gultsch (maßgeblicher Entwickler des Conversations-Clients und einer der Betreiber von conversations.im) stellt hierzu einen Compliance Checker zur Verfügung. Auch wenn dieser nicht alle Server auf der Welt berücksichtigt und nicht jedes XEP (das sind Erweiterungen des XMPPs) wichtig ist, sieht man aber schon, wie wenig Server eigentlich in eine engere Auswahl genommen werden können. Denn nicht jeder Server, bei dem alles grün ist, kann genutzt werden. Entweder ist die öffentliche Registrierung abgeschaltet (wie bspw. bei jabber.rwth-aachen.de) oder der Server hat eine schlechte TLS-/Cipher-Suite-Konfiguration, die von anderen Servern nicht akzeptiert wird.

XMPP-Clients – viel Masse, wenig Klasse

Auf der anderen Seite sieht es bei den Clients wenig besser aus. Conversations ist unbestreitbar ein sehr guter Messenger. Allerdings ist er derzeit nur auf Android-Geräten lauffähig. Wer alleine schon XEP-0384 OMEMO einsetzen will, kann derzeit nur zwischen vier Messengern wählen. Diese Messenger unterstützen dann aber wieder irgendein anderes Feature nicht oder laufen nur auf bestimmten Betriebssystemen. Aus Sicht der Informationssicherheit führt aber kein Weg an OMEMO vorbei, welches neben OTR die einzige moderne Verschlüsselung für XMPP darstellt. OTR ist aber im Messengerbereich heute nicht wirklich brauchbar.

Vertrauen und optionale VerschlĂĽsselung

Die Probleme im Server- und Clientbereich haben die Konsequenz, dass selbst Conversations vom Modell der automatisch aktiven OMEMO-Verschlüsselung abgerückt ist. Verschlüsselung ist folglich etwas Optionales. Das bedeutet im schlechtesten Fall, dass man unverschlüsselt chatten muss. Aus 1,5 Jahren Erfahrung kann ich sagen, dass dies bei (zu Höchstzeiten) 21 Kontakten des Öfteren der Fall war. Insbesondere die Kommunikation zwischen Conversations und ChatSecure kann ein Minenfeld sein.

Unverschlüsselte Chats erfordern aber das Vertrauen in den Serverbetreiber, dass dieser die Kommunikation nicht ausliest, denn XMPP ist eben auch kein metadatenfreies Protokoll (auch nicht, wenn Tor verwendet wird), bei dem nur auf Clients Gesprächsverläufe entstehen. Hier muss man sich selbst fragen, welchem Serverbetreiber man bei gleichzeitigem Risiko, dass die Verschlüsselung nicht (mehr) einschaltbar ist, vertrauen will.

Albtraum verschlĂĽsselter MUC und SchlĂĽsselaustausch

Bei XMPP sind Multi-User-Chats (kurz MUCs) möglich. Diese MUCs werden auf einem Server eingerichtet und ermöglichen dann die Gruppenkommunikation. Im öffentlichen Bereich ist dies relativ unkritisch, was aber auch bedeutet, dass man (sinnvollerweise) keine Verschlüsselung aktivieren kann.

Im Privatbereich, bspw. für die Familie oder für den Freundeskreis, kann man einen nicht-öffentlichen MUC einrichten. Da kann dann auch OMEMO aktivieren, allerdings nur, wenn alle Teilnehmer die öffentlichen Schlüssel miteinander getauscht haben. Das funktioniert in Conversations inzwischen auf fragliche Weise, nämlich völlig automatisch ohne jede Nutzerinteraktion. Wieder optional kann man dann den Fingerprint seines Gesprächspartners verifizieren, bei Gajim wird man hingegen gezwungen, den Fingerprint zu verifizieren. Diese optionale Verifikation in Conversations ist aber sicherheitskritisch. ChatSecure-Nutzer müssen derzeit bei OMEMO-geschützten MUCs generell „draußen bleiben“.

Wenn dann einer der Beteiligten einen anderen oder neuen Schlüssel erhält, geht das Spiel wieder von vorne los. Während dieser Zeit ist OMEMO im MUC deaktiviert für den Betroffenen. Dieser kann also selbst kein OMEMO aktivieren. Selbst wenn nur seine Nachrichten in diesem Zeitfenster unverschlüsselt bleiben, so kann ein Angreifer durchaus daraus Rückschlüsse auf die anderen Nachrichten ziehen.

Der Bezug zur Informationssicherheit

Die drei klassischen Schutzziele der Informationssicherheit sprechen von Vertraulichkeit, Integrität und Verfügbarkeit. Bezogen auf die Verwendbarkeit im Mobilbereich muss man hier folglich OMEMO einsetzen, damit man die ersten beiden Schutzziele erfüllt. Verfügbarkeit kann Kryptografie nicht erreichen.

Daneben gewährleisten sowohl OTR als auch OMEMO „glaubhafte Abstreitbarkeit“, damit ist das Schutzziel Nicht-Abstreitbarkeit (auch Verbindlichkeit) nicht erfüllt (das bedeutet nicht automatisch etwas Schlimmes). Das Schutzziel Authentizität kann zwangsweise erst erfüllt sein, wenn man den öffentlichen Schlüssel (bei OMEMO den des Geräts) vernünftigt verifiziert hat. Zuletzt gewährleistet OMEMO Perfect Forward Secrecy.

Zusammenfassung

Wie hoffentlich deutlich wurde, richtet sich diese Meinung nicht gegen XMPP selbst, sondern gegen die Weise, wie man gezwungen ist, es zu benutzen. Wenn zwei Personen an zwei Laptops verschlĂĽsselt miteinander chatten wollen, reichen auch heute noch XMPP mit OTR und (fast) jeder beliebige Client und Server aus.

Wer XMPP aber im Mobilbereich nutzen will, deswegen zwangsweise OMEMO einsetzen muss, kommt kaum an Conversations vorbei. Hat man dann den falschen Server oder einen MUC und Gesprächspartner ohne Android, hat man im schlimmsten Fall „Pech gehabt“.

Am Ende des Tages schrecken genau diese Hürden viele potenzielle Nutzer ab und XMPP handelt sich den Ruf ein, „altmodisch“ oder „kompliziert“ zu sein. XMPP mit OMEMO einzusetzen, bedeutet unter Umständen Kompromisse eingehen zu müssen, ein technisches Grundverständnis und Lesefreude im Zusammenhang mit GitHub-Issues und Foren mitzubringen (= erfordert Zeit, wenn man nicht gerade sowieso aus dem Informatikbereich kommt) und eine hohe Frustrationstoleranz zu haben.

Was man aber ganz nebenbei erzeugt: Die geächteten Walled Gardens, denn so ganz föderiert und offen wie XMPP auf den ersten Blick scheint, ist es in Wahrheit für sicherheitsbewusste Anwender nicht.

Nachtrag

Leider wurde dieser Artikel hauptsächlich von „XMPP-Verteidigern“ missverstanden und einzelne Sätze aus dem Zusammenhang gerissen, um so darzustellen, wie widersprüchlich der Artikel doch sei. Wir könnten genauso die Sätze auswählen, die die nachfolgende zusammengefasste zentrale Aussage des Artikels darstellen:

Die Nutzung von XMPP ohne eine Ende-zu-Ende-Verschlüsselung erfüllt weder Vertraulichkeit noch Authentizität. TLS gewährleistet diese Ende-zu-Ende-Verschlüsselung nicht. Abgesehen davon ist TLS nicht unbedingt verpflichtend und TLS kann unter Umständen so konfiguriert sein, dass kein Perfect Forward Secrecy unterstützt wird und verwendete Kryptoprimitive als unsicher gelten.

Als Ende-zu-Ende-VerschlĂĽsselung fĂĽr XMPP stehen erst einmal OpenPGP, OTR sowie OMEMO zur VerfĂĽgung. Aufgrund der weit bekannten Nachteile von OpenPGP sowie OTR wurde eben OMEMO entwickelt, um eine alltagstaugliche Ende-zu-Ende-VerschlĂĽsselung fĂĽr den Mobilbereich zu haben. Genau in diesem Mobilbereich werden sicherlich die meisten Messenger heutzutage genutzt.

Daraus ergibt sich, dass OMEMO eine Grundvoraussetzung ist, wenn man XMPP „sicher“ nutzen will. Genau auf die starken Einschränkungen, die man dann als Nutzer erfährt, wenn man OMEMO nutzen will, geht dieser und der Folgeartikel „Messengerkampf: Signal, Conversations, WhatsApp“ ein. Dabei interessiert es einen potenziellen Nutzer aus unserer Sicht auch nicht, ob „irgendwann“ mehr Clients mit OMEMO-Support zur Verfügung stehen.

Wer sich nach dem Lesen angegriffen fühlt, weil er den Eindruck hat, dass XMPP hier ungerechtfertigt schlecht dargestellt wird, sollte noch einmal nachlesen, was Informationssicherheit bedeutet. Auch die Personen, die XMPP aufgrund seiner Offenheit verteidigen und dies wieder einmal vorteilhaft für ihre Eigendefinition von Datenschutz sehen, sollten sich einmal fragen, zu welcher Zeit personenbezogene Daten geschützt werden, wenn sie öffentlich und/oder unverschlüsselt chatten und Daten wie Profilinformationen oder Chatkontakte unverschlüsselt auf Servern von Dritten gespeichert werden.

Changelog

  • 25.08.17: Nachtrag eingefĂĽgt.

War der Beitrag verständlich?
Gibt es Fragen, Anmerkungen, Korrekturvorschläge?
Schreib uns.