Aktualisierungen im Changelog, als RSS-Feed
oder im [matrix] Raum #prhdb-changes:nitro.chat

Privacy Handbuch

Jabber/XMPP hat mich und andere Nerds seit vielen Jahren begleitet. Die Software ist OpenSource und ein kooperatives, weltweites Netz von tausenden Servern wird von Enthusiasten betrieben. Bei Jabber/XMPP lebt noch der Geist des frühen Internet ohne Amazon oder Google Cloud.

Übergriffe auf die Privatsphäre durch Datendiebstahl (z.B. Adressbücher) hat es bei Jabber/XMPP nie gegeben. Der Account kann frei gewählt werden, unabhängig von der Telefonnummer.

Neben 1:1 Chats gibt es bei Jabber/XMPP spezielle Konferenzräume als Gruppenchats und der Austausch von Bildern und Dateien ist mit allen Clients möglich. Audio- und Videotelefonie ist grundsätzlich als Feature definiert, wird aber nicht von allen Jabber/XMPP Clients implementiert.

Bei der Ende-zu-Ende Verschlüsselung gibt es mehrere Alternativen:
  1. Off-the-Record (OTR) wurde 2001 mit dem Ziel entwickelt, möglichst einfach einsetzbar zu sein. OTR ist nicht Multi-Device fähig und verschlüsselt nur direkte Chats. Gruppen­chats und Dateitransfer werden nicht verschlüsselt.

  2. OpenPGP wurde bereits bei der Verschlüsselung von E-Mail behandelt. Die Erstellung und Austausch der Schlüssel ist etwas komplizierter als bei OTR und OMEMO. Die Vertrauenswürdigkeit der Verschlüsselung muss aber nicht extra verifiziert werden, da sie durch das Vertrauen in die OpenPGP-Schlüssel gegeben ist. OpenPGP verschlüsselt nur Chats.

    Bei OpenPGP gibt es zwei Standards. Die meisten Jabber Clients implementieren XEP-0027, der inzwischen für obsolet erklärt wurde, da er einige Sicherheitslücken enthält. Der neuer XEP-0373 ist bisher noch als "experimentell" gekennzeichnet.

  3. OMEMO (OMEMO Multi-End Message and Object Encryption, XEP-384) ist die neueste Ende-zu-Ende Verschlüsselung für Jabber/XMPP. Sie basiert auf Axolotl Ratchet, das für Signal App entwickelt wurde. Sie bietet wie OTR einen autom. Schlüsseltausch, Forward Secrecy und Deniability. Zusätzlich bietet OMEMO verschlüsselte Offlinenachrichten und verschlüsselten Dateitransfer via HTTPUpload. Mit XEP-391 gibt es einen Standard für den verschlüsselten Jingle Dateitransfer, der bisher aber nur von wenigen Jabber Clients umgesetzt wird. (Man kann sich nicht darauf verlassen, das dieser Transfer von Dateien verschlüsselt erfolgt.)

Vergleich mit Signal App und Threema hinsichtlich kryptografischer Sicherheit

Im Vergleich zu den im Punkt Sicherheit führenden Messengern hinkt Jabber/XMPP bei der Umsetzung moderner Sicherheitsfeature hinterher. Die Ursachen dafür liegen in der föderalen Serverstruktur und der Community-basierten Entwicklung. Gerade diese beiden Punkte sind für Open Source Dogmatiker die Pluspunkte von Jabber/XMPP und werden vehement verteidigt, ohne die resultierenden Nachteile bezüglich Sicherheit zu erwähnen.

Einige Bespiele für kryptografische Schwächen bei Jabber/XMPP:
  1. Certificate Pinning für die TLS Transportverschlüsselung zwischen Apps und Servern ist seit Jahren Bestandteil der Sicherheitsempfehlungen für die Entwicklung von Smartphone Apps, um Angriffe auf die TLS Verschlüsslung zu verhindern, die IT-Sicherheitsforscher bereits 2009 in der wiss. Arbeit Certified Lies - Detecting and Defeating Government Interception Attacks against SSL beschrieben haben.

    Bei Jabber/XMPP ist es aufgrund der föderalen Infrastruktur nicht möglich Certificate Pinning einzuführen. Im Gegensatz zur Threema oder Signal ist Jabber/XMPP damit weiterhin anfällig für man-in-the-middle Angriffe auf die TLS Verschlüsselung mit gefakten TLS Zertifikaten. (Einige Jabber Client wie ChatSecure oder CoyIM speichern die zuletzt verwendeten SSL Zertifikate der Server und warnen bei unerwarteten Änderungen, um diese Schwäche teilweise zu kompensieren. Die Warnungen muss man allerdings verstehen und nicht einfach "Ok" klicken.)

    Diese Schwäche hat es einem (vermutlich) staatlichem Angreifer 2023 ermöglicht, monatelang den TLS-verschlüsselten Traffic der Jabber Server jabber.ru und xmpp.ru als man-in-the-middle abzuhören. Die Abhörtechnik wurde in den Rechenzentren von Hetzner und Linode installiert (wo die beiden russischen Jabber/XMPP Server gehostet werden) und nutzte ein falsches TLS-Zertifikat, welches von Let's Encrypt ausgestellt war.

    Threema und Signal App nutzen CA-Pinning mit eigenen CAs, um diese Angriffe zu verhindern.

  2. Alle Kontaktlisten, Mitgliedschaften in Gruppenchats und persönliche Informationen wie Profilfotos u.ä. (VCards) werden bei Jabber/XMPP unverschlüsselt auf den Servern gespeichert, damit man von unterschiedlichen Geräten mit unterschiedlichen Clients darauf zugreifen kann.

    Neben den Techies (Admins der Server) haben auch Behörden darauf Zugriff. Die im Rahmen des Gesetzentwurfes zur Bekämpfung von Rechtsterrorismus und Hass­kriminalität vorgelegten Anpassungen am Telemediengesetz sollen es jedem Dorfpolizisten ohne richterliche Prüfung erlauben, diese Daten abzurufen.

    Bei Threema und Signal App werden diese Daten ausschließlich auf den Clients gespeichert. Die Server Betreiber haben keine Informationen über Kontaktlisten, Mitgliedschaften in Gruppenchats, Profilfotos o.ä. Das schränkt die Flexibilität bei der Verwendung unterschiedlicher Geräte etwas ein zugunsten der Sicherheit.

  3. Signal App und Threema haben ein Sicherheitskonzept, bei dem die Ende-zu-Ende Verschlüsselung der gesamten Kommunikation zwischen den Nutzern (inkl. Audio- und Videotelefonie sowie Gruppenchats) fester Bestandteil und durch Audits bestätigt ist.

    Bei Jabber/XMPP sind bisher alle Versuche einer Ende-zu-Ende Verschlüsselung unvollständig und können nicht sicherstellen, dass die gesamte Kommunikation zwischen zwei oder mehreren Partnern sicher verschlüsselt wird.

    • Teilweise werden XEPs zur Verschlüsselung durch die Community-basierte Entwicklung nur langsam umgesetzt und es dauert mehrere Jahre, bis man davon ausgehen kann, dass sie von einer Mehrheit der Clients unterstützt werden.
    • Teilweise sind die Standards selbst unvollständig und umfassen nicht die Verschlüsselung des gesamten möglichen Datenaustausch zwischen zwei oder mehreren Nutzen, wie beispielsweise auch bei OMEMO (XEP-384). Es gibt bisher keinen Standard (XEP), der die Ende-zu-Ende Verschlüsselung der gesamten Kommunikation bei Jabber/XMPP als Zielstellung definiert hat, da es unübersichtlich viele Erweiterungen gibt.

      (Man kann aber einen reduzierten Jabber Client bauen, der nur Features bietet, die von der einer Ende-zu-Ende Verschlüsslung unterstützt werden. CoyIM mit OTR ist so ein Beispiel. Mit CoyIM kann man nur chatten, kein Austausch von Dateien, keine Gruppenchats. Aber wenn OTR aktiviert wurde, kann man sicher sein, das alles was mit CoyIM möglich ist auch verschlüsselt wird.)
    • Teilweise liegt es auch an mangelnder konzeptueller Vorarbeit. Es wird einfach erstmal irgendwas verschlüsselt - wird schon ok sein. Das Audit von OMEMO bemängelt beispielsweise gleich im ersten Absatz, dass es kein Angreifermodell gibt, gegen das die OMEMO Verschlüsselung schützen soll und keine Anforderungen beschrieben wurden. Damit ist es eigentlich unmöglich, OMEMO zu auditieren, weil man ohne Zielvorgaben nicht prüfen kann, ob sie erfüllt werden.
  4. Das Audit von OMEMO zeigte, das nicht-verifizierte Verbindungen anfällig für Man-in-the-Middle Angriffe sind, die den Multi-Device Support von OMEMO ausnutzen. Ein Man-in-the-Middle kann ein zusätzliches Gerät im Namen des Opfers registrieren und dann die verschlüsselten Chats mitlesen, ohne dass das Opfer es bemerkt. Nach dem Audits wurde die Möglichkeit der Verifikation von Schlüsseln eingeführt, die den Multi-Device Support (ursprünglich als Killerfeature von OMEMO promotet) einschränkt. (Das die gegenseitige Verifikation der Fingerprints der Schlüssel für eine größere Gruppe von Nicht-IT-Nerds umsetzbar ist, scheint mir zweifelhaft.)

    Threema und Signal App sind gegen vergleichbare Angriffe robust, da man ein zusätzliches Gerät für einen Nutzer nicht ohne physischen Zugriff auf das entsperrte Smartphone mit dem Hauptaccount des Nutzers hinzufügen kann. Eine gegenseitige Verifizierung der Schlüssel ist möglich, aber wesentlich weniger wichtig.

  5. In der Regel speichern Jabber/XMPP auch die Ende-zu-Ende verschlüsselte Kommunikation unverschlüsselt in den lokalen Logs ab. Dieses Verhalten ist als "Mannings" Bug bekannt.

    Es ist inzwischen anerkannter Standard bei sicherheitsoptimierten Produkten, das Ende-zu-Ende verschlüsselte Kommunikation auch lokal sicher verschlüsselt zu speichern ist.

  6. Eine Letzte Bemerkung: einige Jabber/XMPP Clients speichern auch die Login Credentials (Passwörter) unverschlüsselt in den lokalen Konfigurationsdateien ab.

    Unter Linux sollte ma darauf achten, dass die Nutzung der verschlüsselten im Speicherung im GNOME Keyring oder KWallet aktiviert wird, wenn es konfigurierbar ist.

Man sollte daraus nicht die Schlussfolgerung ziehen, dass Jabber/XMPP unbrauchbar ist. Wer Spaß daran hat, kann es weiterhin verwenden, wenn der Sicherheits­level ausreichend ist. Bei der Diskussion über Alternativen sollte man aber nicht dogmatisch auf "Open Source" und "föderale Strukturen" bestehen, ohne die Mängel in der Kryptografie einzugestehen.

Jabber/XMPP Server

Um Jabber/XMPP für die Kommunikation nutzen zu können, muss man einen Account auf einem Jabber Server anlegen. Es gibt eine große Auswahl von Servern und es fällt schwer, eine Auswahl zu treffen. Folgende Kriterien sind zu beachten:
  1. Um die moderne OMEMO Verschlüsselung verwenden zu können, muss der Server die notwendigen Erweiterungen XEP-0163 und XEP-0280 unter­stützen. Ob der bevorzugte Server diese Extensions unterstützt, kann man entweder selbst mit dem Java Programm ComplianceTester for XMPP prüfen oder auf der Webseite von D. Gultsch nachschauen, wo man Ergebnisse der Tests für viele Server findet.
  2. Wenn man Jabber/XMPP auch auf Android Smartphones verwenden möchte, kann ein Server mit Push Notifications (XEP-0357) den Akku schonen.
  3. Der Server sollte eine SSL/TLS Verschlüsselung nach dem Stand der Technik bieten. Das kann man beim IM Observatory prüfen oder mit dem CryptCheck, indem man folgende URL aufruft: https://tls.imirhil.fr/xmpp/<domain.tld>
  4. Für langfristige Nutzung ist es wichtig, ob es ein Konzept zur Finanzierung der Server gibt oder ob man mit dem Risiko leben möchte, dass der Betrieb kurz­fristig eingestellt werden könnte weil der Admin keine Lust mehr hat. Bei spenden­finanzierten Servern kann man für private Accounts 10-15 € pro Jahr investieren, um den Betreiber zu einem langfristigen und stabilen Betrieb des Dienstes zu motivieren.
Ein kleine Liste von empfehlenswerten XMPP-Servern:
Server Bemerkungen
conversations.im    kostenpflichtig (8 € pro Jahr), von XMPP-Profis betreut
draugr.deseit 2005 online, spenden-finanziert
dismail.deebenfalls spenden-finanziert, mit Webchat Interface
mailbox.org nur für Kunden von mailbox.org
jabber.cat auch Frauen können IT und die Jabber-Katze ist gut
trashserver.net mit Spenden finanziert, mit Webchat Interface
Die Aufzählung ist unvollständig, als kleine Anregung gedacht. Umfangreichere Listen gibt es bei D. Gultsch, bei jabberes.org, bei xmpp.org oder ubuntuusers.

Jabber/XMPP Clients

Mit Conversations für Andoid oder ChatSecure für iPhones stehen moderne Apps für Smartphones zur Verfügung. Man kann OMEMO und OpenPGP für die Verschlüsselung nutzen (bei ChatSecure auch OTR) und den OrBot als Anonymisierungsdienst.

Für Linuxer gibt es mit Dino.im einen modernen XMPP Client, der auch verschlüsselte Audio- und Videochats unterstützt. Außerdem gibt es Gajim oder Pidgin für alle Desktop Betriebssysteme.