Schlagwort-Archive: xmpp

Zulip raus und Matrix rein

Seit August betrieb ich auf einer VM einen Zulip-Server zum Testen. Ich dachte, dass sich das Ding in der Familie evtl. ausbreiten würde, als Ergänzung zu unserem XMPP-Server. Dem war aber nicht so, was vor allem daran lag, dass die Android-App von Zulip wenig intuitiv daher kam und weil die Inhaltsverschlüsselung für Chats fehlte. Jetzt also Matrix-Synapse mit OLM als Verschlüsselung – wie einst Zulip hier im Haus auf einer VM betrieben mit ddnss als DynDNS Betreiber.

So richtig datenschutz-sauber ist Matrix bzw. die Android App Riot nicht. Auch dann nicht, wenn man die build aus FDroid verwendet. Diesbezüglich führt unser XMPP-Server weiterhin das Feld an und bleibt deswegen auch die Kommunikationszentrale der Familie. Aber was bei den ersten Tests von Matrix sofort überzeugte, ist die Zuverlässigkeit, mit der auch die dicksten Anhänge zugestellt werden.

Was ebenfalls für Matrix spricht ist die einfache Installation und Konfiguration. XMPP – selbst mit Prosody – und die gefühlt immer verwickelten Konfigurationsorgien bei den benötigten XEP-Modulen sind da schwerer in den Griff zu bekommen.

XMPP continued

Der XMPP Server unter Prosody läuft einfach. Etwas hakelig erwies sich die Konfiguration der Chaträume, die meinem Eindruck nach auch von den Fähigkeiten der mit dem Server verbundenen Clients abhängig ist: deren Zusammenspiel mit Prosody erzeugt einige Inkonsistenzen. Bei den folgenden Einstellungen für Prosody

erlaubte es mir Conversations nicht, einen Chatraum einzurichten. Leider klappt das auch nicht mit

das ja eigentlich das Recht zur Raumerstellung auf die Admins beschränken sollte. Das funktionierte bei meinen Versuchen ein einziges mal – danach dann nicht mehr. Warum, war den Logs für mich nicht zu entnehmen. Da stand

(blabla steht hier für den gewählten Raumnamen) aber ich googlete mich in die Ecke ohne schlau zu werden. Ich stellte deswegen auf

um und überwache zur Sicherheit das Verzeichnis mit den Raumdefinitionen, auf dass ich mitbekomme, was mein Server so alles hostet. Diese liegen hier:

Eine weitere Hürde auf dem Weg zu eigenen MUCs war, dass mein Zertifikat für den Server nur auf domain.tld und www.domain.tld läuft. Der Standard für MUCs scheint aber conference.domain.tld zu sein. Ich hätte mir demnach ein extra Zertifikat besorgen oder richtig Geld in die Hand nehmen müssen, was mir schlicht zu blöd war. Startssl muss reichen. Also sind die Chaträume nun eben unter www zu finden. Für die eigenen Bedürfnisse geht das.

Überhaupt: Die Clients.

Meine Erfahrungen beschränken sich auf xabber, tigase, yaxim und conversations. Von diesen beherrscht nur conversations in Zusammenspiel mit Prosody den (fast) reibungslosen Versand von Dateien und Bildern, den Austausch von OTR-verschlüsselten Nachrichten sowie nun auch die Einrichtung und Verwaltung (privat / öffentlich, Einladungen verschicken und annehmen) von Räumen.

Screenshot_2015-06-04-09-11-42

Beim Versand von Bildern und Dateien mit Conversations / Prosody muss man allerdings darauf achten, dass die Beteiligten gegenseitig ihren Online-Status sehen dürfen und auch beide online sind (grüner send / camera button) – sonst fällt der Prozess kommentarlos auf die Nase.

Eine Option zur Zwischenspeicherung von Dateien und Bildern auf dem Server habe ich in Prosody nicht gefunden und dafür scheint es auch kein Modul zu geben. Das Modul mod_storage_internal kann nur mit Text umgehen und auch mod_offline behandelt lediglich Text. Ich muss mir mal mod_storage_sql ansehen. Evtl geht ja da was (auch wenn die Beschreibung der DB-Felder für mich nicht so aussieht).

Dazu kommt: Verschickt man über Conversations dickere Dateien (getestet habe ich mit bis zu 16MB), dann fällt auch dies gelegentlich auf die Nase, obwohl sich die Beteiligten gegenseitig sehen. Hier scheint das Zusammenspiel zwischen Conversations und Cyanogenmod (Energieeinstellungen) eine Fehlerquelle zu sein: schaltet sich der Bildschirm ab, dann bricht häufig auch die Dateiübertragung zusammen.

Insgesamt betrachtet: Die grundlegenden Dinge funktionieren nun – bei vielen Details ist noch Luft nach oben.

XMPP

Ich habe meine Metadaten gerne unter Kontrolle und mir deswegen einen XMPP Server unter Prosody gegönnt. Hier einige Notizen rund um die Installation.

Basis

Prosody Paketquellen einbinden um von der trägen Paketverwaltung in den Ubuntu Repos unabhängig zu werden:

Den Key der Paketquelle holen und in APT werfen:

Prosody installieren:

Einstellungen für den Benutzer prosody in /etc/passwd kontrollieren, der nur /bin/false als Shell erhalten darf:

Prosody Konfiguration anpassen – unter Lua ist ein doppeltes Minus ein Kommentarzeichen:

Die Konfigurationsdatei ist gut strukturiert und weitgehend selbsterklärend, so dass beim Lesen kaum Fragen offen bleiben. Im Zweifel alle Restfragen über die sauber strukturierte Dokumentation bei https://prosody.im klären.

In der Konfiguration

  1. den Admin für den XMPP Server festlegen
  2. die Sektion Module durchsehen und z.B. version sowie uptime deaktivieren, damit wir nach Außen hin nicht gleich alle Angriffspunkte verraten.

Ebenfalls kontrollieren, ob Registrierungen über Clients abgelehnt werden. Das scheint nötig zu sein, damit man nicht mit Konten zugespamt wird:

Wir wollen die Verbindung zwischen Client und Server Zwangsverschlüsseln:

Das geht im Prinzip auch für s2s (Server to Server) Verbindungen. Hier liegt auch der Grund, warum wir dringend OTR Verschlüsselung haben wollen, wenn wir nicht auf der eigenen Domain chatten.

Die Passwörter der Benutzer verschlüsselt speichern, auch wenn die Nebenwirkung ist, dass manche Clients länger brauchen, um sich anzumelden:

SSL Key einbinden. Hierbei für Zwischenzertifikate ein PEM basteln wie für Dovecot und Freunde ebenfalls üblich.

Siehe zu intermediären Zertifikaten auch: https://prosody.im/doc/certificates?s[]=pem#certificate_chains

Unser Zertifikatsspeicher für Prosody verwendet schlicht Symlinks, um sich die Arbeit einfacher zu machen, wenn Zertifikate erneuert werden:

Die Hosts einrichten:

Prosody neu starten:

Nach Fehlern suchen:

Einen Fehler finden und wohl erst einmal schlicht hinnehmen:

Siehe hierzu auch https://prosody.im/doc/depends#luaexpat und den Hinweis, dass man in diesem Fall auf compression verzichten sollte (das ist der Default).

Die Benutzer anlegen – den oben eingetragenen Admin hierbei nicht vergessen:

Jetzt mit den ersten Clients eine Verbindung aufbauen und den Verbindungen zusehen, wie sie reinkommen:

Einen Blick in den Benutzerkontenbereich werfen:

Dort nachsehen, ob die *.dat Dateien auch wirklich nur verschlüsselte Passwörter enthalten.

Am Ende den gesamten Server auf den Prüfstand stellen: https://xmpp.net/

Sicherheit

Siehe zum folgenden Abschnitt: https://code.google.com/p/prosody-modules/wiki/mod_log_auth und auch https://jabber.lqdn.fr/securing-our-jabber-server-with-fail2ban-securisation-du-serveur-jabber-avec-fail2ban/

Im Modules Verzeichnis von Prosody ein weiteres Modul hinterlegen:

Das Modul umbenennen, damit es läuft:

Das Modul in der Konfiguration einschalten

Prosody neu starten und kontrollieren, ob nun die Connects mitgeschrieben werden:

Einen Filter für fail2ban anlegen:

Inhalt:

In der jail.local hinterlegen:

Die Dienste neu starten:

In Check_MK die Service discovery für den XMPP-Server-Host neu anschubsen, damit man auch dort sieht, was passiert.

Die nächsten Schritte: Für meine Schule muss das auch noch eingerichtet werden – dann allerdings mit LDAPs Anbindung, damit es jeder gleich nutzen kann und die Benutzerverwaltung einfacher wird.