Hinweis: Diese Seite ist nur intern zugänglich – bzw. sollte nur intern zugänglich sein. :-)

Jabber-Server

In einer VM auf der dontpanic läuft ein XMPP-Server. Wir haben auch eine Website dazu.

Ins Leben gerufen wurde dieser Dienst am 27. April 20061 von mrks und mef (stimmt das? –nico). Wenig später war ein lauffähiger Jabber-Server plus Website online.

Software

Als Software wird prosody eingesetzt. Zusätzliche Komponente, mit der wir weitere Dienste anbieten, sind zur Zeit mu-conference für multi user chats und BOSH für XMPP over HTTP.

Früher (das heißt, bis zum 14. Januar 2007 um 03:20 Uhr mitteleuropäischer Zeit) lief zusätzlich noch ein MSN-Transport, der aber auf Grund von Problemen, die heutzutage vermutlich keiner mehr versteht, abgeschaltet wurde. Bis heute wurde er nicht wieder reaktiviert.2

Nutzerverwaltung

Accounts können per Kommandozeile oder per Ad-Hoc-Commands der eingetragenen Admins bei geeigneten Clients anlegt/gelöscht/verändert werden (siehe auch XEP-0050: Ad-Hoc Commands). Die In-Band-Registrierung wurde 2011 aufgrund erhöhtem Spamaufkommens vorübergehend abgeschaltet.

Anleitung zu Erstellung eines Accounts auf der Kommandozeile:

Natürlich kann man zur Verwaltung der Accounts auch prosodyctl passwd oder prosodyctl deluser nutzen.

Verbindungsstatistiken

Die aktuelle Anzahl der mit dem Jabber-Server verbundenen Benutzer (c2s) sowie die Anzahl der verbundenen Server (eingehende und ausgehende s2s-Verbindungen) können auf der Statusseite abgefragt werden.

Prosody bietet eine telnet-Schnittstelle an, über die die aktuellen Statistiken ausgelesen werden können. Diese werden alle 5 Minuten per cron über das Skript /usr/local/bin/get_rec.sh in einer rrd-Datenbank gespeichert und mit dem Skript /usr/local/bin/gen_pic.sh ein paar Bilder generiert, welche über die Statusseite eingebunden werden.

Zusätzlich wurde ein zusätzliches Munin-Modul installiert, um weitere Werte des Jabber-Servers zu visualisieren.

Befehl um die rrd-Datenbank-Dateien zu erzeugen:

rrdtool create /var/lib/prosody/statistics/users.rrd \
        --start `date +%s` \
        --step 300 \
        'DS:users:GAUGE:600:0:U' \
        'DS:ssl:GAUGE:600:0:U' \
        'DS:nossl:GAUGE:600:0:U' \
        'RRA:AVERAGE:0.5:1:288' \
        'RRA:AVERAGE:0.5:288:365'

rrdtool create /var/lib/prosody/statistics/serversin.rrd \
        --start `date +%s` \
        --step 300 \
        'DS:servers:GAUGE:600:0:U' \
        'DS:tls:GAUGE:600:0:U' \
        'DS:notls:GAUGE:600:0:U' \
        'RRA:AVERAGE:0.5:1:288' \
        'RRA:AVERAGE:0.5:288:365'

rrdtool create /var/lib/prosody/statistics/serversout.rrd \
        --start `date +%s` \
        --step 300 \
        'DS:servers:GAUGE:600:0:U' \
        'DS:tls:GAUGE:600:0:U' \
        'DS:notls:GAUGE:600:0:U' \
        'RRA:AVERAGE:0.5:1:288' \
        'RRA:AVERAGE:0.5:288:365'

DNS-Konfiguration

siehe /etc/bind/db.ulm.ccc.de auf der dontpanic, wichtig um die verfügbaren Ports für die Clients anzugeben:

_xmpp-client._tcp.jabber                10800   IN      SRV     11      0       5222    jabber.ulm.ccc.de.
_xmpp-server._tcp.jabber                10800   IN      SRV     11      0       5269    jabber.ulm.ccc.de.
jabber                                  IN      A       217.10.15.19
_xmpp-server._tcp.conference.jabber     10800   IN      SRV     11      0       5269    conference.jabber.ulm.ccc.de.
conference.jabber                       IN      A       217.10.15.19

Upgrade 2010/2011

Ende 2010/Anfang 2011 wurde der Jabber-Server komplett überarbeitet:

Die verwendete Software wurde auf die neusten Versionen (aus den Upstream-Repositories, falls verfügbar) geupgradet. Zur leichteren Installation und für bestimmte Spezialitäten unseres Setups wurde eine ganze Menge an Patches hinzugefügt. Außerdem wurden einige kritische Bugs gefunden und weggepatcht. Die meisten dieser Patches sind schon upstream geflossen (siehe `dev`-Mailingliste). Weitere werden ab und zu nach kurzer Zeit, in der die Leserinnen und Leser von intern@ Gelegenheit haben, Kommentare dazu abzugeben, an die dev-Liste geschickt.

Upgrade 2014

Dank der neuen Hardware kann der Jabber-Server in einer neuen VM laufen. Da bei jabberd14 mit jadc2s ein Großteil der SSL-Verbindungen am Handshake scheiterte (unterstützte Ciphers?), wurde der Server durch prosody ersetzt. Insbesondere aufgrund der unterstützen Ciphersuites wird nicht die Debian-Wheezy-Version, sondern die aktuellere des Prosody-Repos verwendet.

Das Modul für verschlüsselte Passwörter wurde aktiviert, so dass nach und nach alle Passwörter in gehashte Versionen umgewandelt werden und nicht mehr wie beim alten System unverschlüsselt auf der Platte liegen. Die Umstellung erfolgt per User bei der erfolgreichen Anmeldung eines Clients.

Logging ist weitgehend deaktiviert (warn nach /var/log/prosody/prosody.log, error nach syslog und /var/log/prosody/prosody.err).

Die Konfiguration findet sich in /etc/prosody/prosody.cfg.lua. Sowohl die Konfigration als auch die Daten zu den Benutzeraccounts (unter /var/lib/prosody/jabber%2eulm%2eccc%2ede) werden in lua-Code (ordentlich formatiert - ähnlich gut lesbar wie JSON) notiert.

Benötigte Pakete

Neben dem Basissystem (debian stable) müssen folgende Packete installiert werden (weitere daraus entstehende Abhängigkeiten nicht aufgeführt):

Ja, prosody ist in lua geschrieben...

SSL-Ciphers

Seit Prosody-Version 0.9.2 werden per Standardkonfiguration RC4 deaktiviert und forward secrecy bevorzugt, so dass es auch ohne manuelle Eingriffe beim IM Observatory (c2s/s2s) für ein T (trust?) reicht (eigentlich durchgefallen F, aber nur wegen selbstsigniertem Zertifikat, sonst wäre es A). Nur die dhparams wurden aktiviert.

Auch der Webserver ist jetzt per https erreichbar, wenn ebenfalls auch nur mit selbstsigniertem Zertifikat (siehe ssllabs-Testergebnis).

TODO

Falls jemandem langweilig ist oder sie/er sich über irgendetwas unseren Dienst betreffend aufregt, ist hier die passende Stelle, um konstruktiv tätig zu werden. ;-)

(Wahrscheinlich unvollständige) Auflistung der Punkte, die an unserer Software bzw. an unserem Setup noch zu erledigen sind:

Krypto

Hinweis von bjoern: durch Umstellung auf prosody hoffentlich obsolet

Ja, dieser Abschnitt enthält auch Sachen die eher zur Vorbereitung von Nicos Chaosseminar-Vortrag taugen. Ist bekannt. Wird vielleicht mal geändert. –nico

c2s- und s2s-Verbindungen können theoretisch und prinzipiell sowohl sofort TLS sprechen als auch erstmal ne Verbindung herstellen, kurz Hallo sagen und dann auf TLS upgraden. Letzteres bezeichnet man oft als STARTTLS.6 Die IANA hat für XMPP die Ports 5222 und 5269 reserviert7, darauf wird STARTTLS gemacht.8 Für Jabber war es üblich, TLS (also kein STARTTLS) für die entsprechenden Dienste auf jeweils einem Port höher zu sprechen, also auf Port 5223 für c2s und 5270 für s2s.9 So genial ist das aber nicht, weil diese Port-Nummern nicht von der IANA dafür zugewiesen sind.7

Unser Server unterstützt für c2s unverschlüsselt und STARTTLS auf Port 5222 und TLS auf Port 5223 (stört also damit das Internet ;-p ). Für eingehende s2s-Verbindungen steht Port 5269 zur Verfügung, ebenfalls entweder unverschlüsselt oder mit STARTTLS. (Verbindungen auf Port 5270 werden von uns nicht unterstützt, das war schon immer so; sie sind wohl auch eher unüblich. Die von uns eingesetzte Software hat keine Default-Konfiguration in der Richtung.)

Wenn ein Client oder Server mit unserem Server kommunizieren möchte und (START)TLS spricht, sind nur bestimmte kryptografische Verfahren dabei möglich. Diese heißen im Fachjargon „Cipher Suites“. Eine Cipher Suite ist quasi ein Paket aus kryptografischen Algorithmen:

Für jeden dieser Punkte handeln zwei über TLS kommunizierende Parteien aus, welche Algorithmen für sie akzeptabel sind und welche nicht. Anschließend wird ein für beide Parteien akzeptabler Algorithmus für die entsprechende Funktion aktiviert. Zusätzlich kann auch noch ein Kompressionsverfahren ausgehandelt werden.

Sollte es für irgendeine dieser fünf Gruppen keinen von beiden Parteien akzeptierten Algorithmus geben, können sie nicht über TLS kommunizieren.

Unser Setup verwendet zur Zeit OpenSSL für c2s- und GnuTLS für s2s-Verbindungen. Das ist unproblematisch, aber hat ein paar Auswirkungen, die man im Hinterkopf behalten sollte. (OpenSSL und GnuTLS unterstützen nämlich unterschiedliche TLS-Versionen, Cipher Suites und Kompressionsalgorithmen.10)

Um sich gegenüber Clients und gegenüber anderen Servern ausweisen zu können, hat unser Server ein X.509-Zertifikat. Im Moment ist es ein selbst-signiertes mit einem RSA-Public-Key der Schlüssellänge 4096 Bit. Für c2s- und s2s-Verbindungen wird das gleiche Zertifikat (ergo natürlich das gleiche Schlüsselpaar) benutzt.

Für die vom Server angenommenen (c2s, s2s) oder eröffneten (s2s) Verbindungen möchten wir Perfect Forward Secrecy11 (PFS) haben. Gar nicht so sehr wegen uns, sondern eher für unsere lieben User. (Natürlich wollen wir immer möglichst sichere Systeme, weil wir ja vom CCC sind und daher Die Guten™, aber im Prinzip könnte es uns ja egal sein, wenn Unterhaltungen unserer User gelesen werden.)

Um PFS zu bekommen, werden bei TLS per DH Sitzungsschlüssel ausgemacht, mit denen die beiden Kommunikationspartner ein (jedem von ihnen und sonst niemandem bekanntes) bei beiden gleiches Geheimnis erzeugen, von dem Schlüsselmaterial zur symmetrischen Verschlüsselung der übertragenen Daten abgeleitet wird. Die Sicherheit des Verfahrens beruht dabei darauf, dass die privaten Teile der DH-Schlüssel nach erfolgtem Schlüsselaustausch weggeworfen werden (in OpenSSL 1.0.0c ist das akzeptabel implementiert –nico). Man nennt diese DH-Schlüssel „ephemeral keys“12 (deutsch etwa: kurzlebige/flüchtige Schlüssel).

Wir erlauben also für die c2s-Kommunikation nur Cipher Suites, bei denen solche ephemeral keys erzeugt und verwendet werden.13 Auf der dontpanic sind im Moment für c2s-Verbindungen folgende Cipher Suites14 möglich (das kann, je nach Updates von OpenSSL, variieren), Reihenfolge entspricht Vorliebe (tollste oben):

Triple-DES hat unser Server nicht so gerne, weil es viel mehr Rechenzeit erfordert als AES. Längere Schlüssel bei AES findet er schöner als kürzere. Da derzeit kein X.509-Zertifikat mit DSA-Key zur Verfügung steht, sind die entsprechend DSS-Cipher-Suites nicht nutzbar.


Einschub: für mögliche EC-Krypto-Benutzung:

Laut RFC 4492 sollten alle Server TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (in OpenSSL: ECDHE-RSA-AES128-SHA) und TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (in OpenSSL: ECDHE-RSA-DES-CBC3-SHA) können. Das wäre für EC-Algos also der kleinste gemeinsame von uns akzeptierte Nenner. Natürlich bevorzugen wir AES statt 3DES wegen weniger Rechenaufwand. Wenn ein Client nur die ECDH_ECDSA-Varianten implementiert, hat er also Pech gehabt.

ECDHE_*-Cipher-Suites bieten gemäß diesem RFC Forward Secrecy, und ECDH_* nicht.

Ende EC-Einschub.


Für die Kommunikation mit Clients funktioniert dieses System recht gut. Ein paar wenige Benutzer waren allerdings seit Anfang Januar über unverschlüsselte Verbindungen online. Wir konnten sie aufspüren und Marcel hat sie mal benachrichtigt.

Windows-Clients

Es gab auch ein paar Support-Anfragen an Marcel von Leuten, die kaputte Software einsetzen und daher nicht über eine verschlüsselte Verbindung mit unserem Server sprechen konnten, aber Marcel und Nico hielten es nicht für tragbar, einen Internet Explorer in Version 615 noch zu supporten. Das wurde den betroffenen Usern von Marcel mitgeteilt und wir warten auf Feedback (Nicos Stand am 2011-01-19).

Windows ist definitiv ein Problem für die User, wenn sie einen Client verwenden, der die Krypto-Bibliotheken von Windows benutzt. Für uns war es nur sehr schwer bis gar nicht möglich, herauszufinden, welche Cipher Suites die Windows-Bibliotheken überhaupt unterstützen und unter welchen Windows- bzw. Library- bzw. Internet-Explorer- bzw. Service-Pack-Versionen. Selbst die Mitarbeiter von Microsoft sind offenbar nicht in der Lage, diese Information aufzuspüren.16 Folgende, möglicherweise hilfreiche, Daten konnten wir (nach langem Suchen) allerdings bisher finden:

Akzeptable Cipher Suites

Die Liste der für unsere c2s-Verbindungen akzeptierten Cipher Suites ergibt sich aus folgendem OpenSSL-ciphers-String13:

Für normale Menschen bedeutet das:

Übrig bleiben dann die oben genannten Cipher Suites.

Kurz könnte man auch sagen:

Das klappt mit jeder Art von Kompression, die OpenSSL anbietet (im Moment wohl nur NULL21).

Das Ganze nochmal für s2s

Wie bereits erwähnt, wird s2s von jabberd (Paket jabberd14) und nicht vom jadc2s gemacht. Die verwendete TLS-Bibliothek ist GnuTLS.

Mögliche Cipher Suites für s2s sind zur Zeit:

GnuTLS unterstützt zwar noch einige mehr, aber die kann der Code von jabberd14 noch nicht verarbeiten.

Für die Kompression wird ggf. LZO; DEFLATE oder NULL unterstützt.

Problem mit ejabberd

ejabberd kann kein DHE. Das liegt an schlechter Implementierung. Nico hat das mal schnell gepatcht und vt100 den Patch geschickt, damit unser Server wieder verschlüsselt mit jabber.ccc.de sprechen kann. Der Patch könnte aber noch etwas Bereinigung vertragen (aber ist im Moment nicht gefährlich oder schädlich).

TODO: Diese Erklärungen noch etwas ausbauen.

Siehe dazu auch den Upstream-Bugreport für ejabberd.

Lesestoff

Man lese zu den ganzen Krypto-Sachen folgende Spezifikationen:

Falls man sich sehr langweilt (und – bei manchen – Geld hat oder die Teile in der Uni-Bibliothek oder ähnlichem findet), auch noch folgende:

Hinweise zu Clients

Weil wir vom CCC sind – und damit Die Guten™ –, ziehen wir privatsphärensensitive Software jener vor, die schädlich oder gefährlich für Benutzer ist.

Wir möchten keine bestimmten Hersteller benachteiligen, haben allerdings eine Liste von XMPP-Clients zusammengestellt, deren Funktionsweise für Benutzer nicht wünschenswert ist. Von der Benutzung hier gelisteter Software müssen wir aus technischen und/oder Privacy-Gründen abraten. Diese Liste ist wahrscheinlich nicht vollständig. Hinweise zu weiterer gefährlicher Software nehmen wir gerne entgegen.

Software

Kommentar

Meebo

Diese Systeme bauen eine Verbindung zu unserem Jabber-Server von einem Server des Herstellers/eines Providers auf. An dieser Stelle ist ein Mitlesen deiner Daten (inkl. deines Passwortes) für diesen Provider möglich.
Manche Hersteller betonen deutlich, dass die Übertragung von Daten (wie z. B. deines Passworts) von dir zu ihnen verschlüsselt geschehe. Wir zucken da nur mit den Schultern, denn unser Argument ist damit nicht entkräftet. Der CCC Erfa Ulm rät ausdrücklich davon ab, Accountdaten wie Passwörter Dritten zur Verfügung zu stellen.

SHAPE Services IM+

Miranda IM in Version 0.9.1622 oder älter, insbesondere unter Microsoft Windows in einer Version vor Windows 2000 und ohne auf PolarSSL basierendem SSL-Plugin23

Die Entwickler von Miranda IM bekommen bedauerlicherweise ihre Krypto nicht auf die Reihe. Gegenüber einem unserer User haben sie sich 2011-01/2011-02 in der Beziehung leider als uneinsichtig und unfähig gezeigt.
Die genannten Konstellationen mit Miranda IM als XMPP-Client können von uns aus technischen Gründen24 nicht mit unserem Jabber-Server zum Laufen gebracht, auf unserem Server unterstützt oder von uns mit Support beworfen werden.25

Für Miranda IM unter Windows hat ein lieber User unseres Servers das Plugin ‚SSLPL‘ kompiliert, das wir unseren Usern nun zum Download anbieten (ohne irgendwelche Versprechen/Zusagen, versteht sich): https://ulm.ccc.de/~marcel/miranda/

Am 2011-02-08 hat Nico die Meebo-Leute kontaktiert, weil ihr System kaputt zu sein scheint (Cc: marcel, phil). Auch wenn wir deren Kram nicht gutheißen, reagieren wir damit auf eine Anfrage von $USER unseres Servers (Verbindungsaufbau zu unserem Server über Meebo funktioniere nicht). Laut Nicos Debugging ist Meebo kaputt, weil es bei STARTTLS nach dem TLS-Verbindungsaufbau nicht einen neuen XML-Strom aufmacht26, sondern einfach gar nichts sendet. Wir haben einen URI bekommen, über den wir auf unsere „service request“ zugreifen können müssten: https://meebo.smartanswer.com/?cmd=ticket&key=1420ZF7600D0A683EB140658C7E8EFCE7C688 Funktioniert nur leider nicht. Angeblich kümmern sich aber die Leute vom „Meebo IT Team Help Desk“ um die E-Mail. Tracking-Nummer für die Sache ist die eins-zweiundvierzig-null: # 1420. :-D

Danke

Thanks fly to leo :-) für die Suche nach XMPP-Server-Software, deren vorläufige Untersuchung und die Mitarbeit beim Versuch, solche Software in ein Chroot zu installieren.

Herzlichen Dank an macky für das Verifizieren und Aufschreiben der Jabber-Server-Abhängigkeiten (Debian-Pakete).

Großes Danke an juergen :-) für die Sachen das Backup-Skript betreffend.

Vielen Dank an uli für die interessanten Informationen zum Thema Debugging.

Marcel gebührt Dank dafür, einigen User-Support zu machen und wichtige Dinge bezüglich der Windows-Clients von Usern weiterzuleiten. Ihm und phildom danke für eine lustige Debugging-Session27, die neue Kenntnisse auftat.

Danke an unseren User, der uns Windows-Binaries für das PolarSSL-Plugin für Miranda IM kompiliert und geliefert hat.

Danke auch an alle anderen, die sich an Diskussionen auf intern@ und/oder beim Montagstreff beteiligt haben.

Und natürlich noch vielen Dank allen anderen, die leider hier vergessen wurden. Sie sollten noch nachgetragen werden.

  1. Siehe https://jabber.ulm.ccc.de/news.html, News-Meldung „Inspiration“ vom 27. April 2006, 10:31 Uhr mitteleuropäischer Zeit. (1)

  2. Siehe auch https://jabber.ulm.ccc.de/news.html, News-Meldung „Transports“ vom 9. Februar 2007, 23:36 Uhr mitteleuropäischer Zeit. (2)

  3. siehe Cipher Suites in Schannel (Windows) (3 4 5)

  4. BSI 2011; TODO: Referenz korrigieren (6)

  5. War offenbar mal – zumindest im Testbetrieb – installiert/aktiv. Quelle: Diff uralter jabber.xmls, die in /root/jabber/ rumgammelten. –nico (7)

  6. Im Gegensatz dazu wird ersteres wird landläufig sehr häufig als „SSL“ bezeichnet, aber das hält Nico für verwirrend. (8)

  7. PORT NUMBERS, Stand: 2011-01-14. (9 10)

  8. RFC 3920, insbes. Abschnitte 15.9, „Port Numbers“, und 5, „Use of TLS“. (11)

  9. RFC 3920, Anhang D.1, „Channel Encryption“. (12)

  10. siehe OpenSSL: Documents, ciphers(1) (Warnung: Dokumentation ist nicht auf dem gleich neuen Stand wie der Code; man lese lieber den Code – man muss natürlich auch die Benutzung dieser vielen Defines prüfen!) und All the supported ciphersuites in GnuTLS - GnuTLS 2.10.4 (13)

  11. Definition von „perfect forward secrecy“ im Telecom Glossary 2007 (Stand: 2011-01-19) der Alliance for Telecommunications Industry Solutions (ATIS). Laut Definition von „forward secrecy“, ebenfalls aus dem ATIS Telecom Glossary 2007, siehe auch ANSI X9.42. (14)

  12. siehe NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised), 2007-03-08, in Kombination mit NIST Special Publication 800-57 Part 1: Recommencation for Key Management – Part 1: General (Revised), 2007-03-08. (15)

  13. Siehe auch „Krypto des Jabber-Servers“: Mail von Nico an intern@ am 2010-11-28. (16 17)

  14. links Syntax aus RFCs, rechts und in Klammern OpenSSL-Syntax (18)

  15. Da kommen offenbar die Krypto-Bibliotheken für Windows her. Nach 2010-07-13 definitiv nicht mehr von Microsoft gewartet, siehe Microsoft Product Lifecycle Search: „Internet Explorer“ und Lifecycle Supported Service Packs, Internet Explorer (19)

  16. Siehe Antwort von Nicholas Li vom 2010-12-27T08:11Z(?) im Thread „Supported cipher suites for IE8“. (20)

  17. siehe SSP Packages Provided by Microsoft (Windows) (21)

  18. d. h. Schlüssellänge min. 128 Bit, siehe ‚HIGH‘ in OpenSSL: Documents, ciphers(1) (22)

  19. TODO: Referenz ergänzen (23 24 25)

  20. Gilt als gebrochen, siehe TODO: Referenz ergänzen. (26)

  21. Code nicht geprüft. (27)

  22. neuere Versionen haben wir nicht überprüft (28)

  23. Es sind noch weitere Konstellationen betroffen, aber die zu beschreiben würde die Angaben noch schwieriger lesbar machen. (29)

  24. kurz gesagt: Windows kann das nicht und die Miranda-IM-Entwickler workarounden das Problem nicht (30)

  25. … und jetzt geh weg und hol dir einen gescheiten Client … :-p Pidgin ist für dich vermutlich am besten geeignet. (31)

  26. siehe RFC 3920, Abschnitt 5.3, Seite 24, Punkt 7 (32)

  27. mit gdb am 2011-02-02; c, c, c, … :-) (33)

JabberServer (zuletzt geändert am 2014-08-26 10:33:56 durch CCCips)