XMPP

XMPP (ou eXtensible Messaging and Presence Protocol) est un ensemble de protocoles standards ouverts de l’Internet Engineering Task Force (IETF) pour la messagerie instantanée, et plus généralement une architecture décentralisée d’échange de données. XMPP est également un système de collaboration en quasi-temps-réel et d’échange multimédia (Wikipédia).

On utilise comme serveur le logiciel ejabberd, écrit en erlang et développé avec des réseaux d'entreprise en tête. La plus populaire alternative est prosody (lua). Par rapport à prosody, ejabberd bénéficie d'un rythme de développement plus rapide (judicieux pour le support des dernières extensions du protocole), et d'une plus grande cohérence/qualité dans les modules à disposition (ce qui facilite grandement l'administration).

Mise en place du serveur

Installation

ejabberd est packagé dans pour stretch.

sudo apt install ejabberd

Configuration

ejabberd utilise le format yaml pour son fichier de configuration.

Le yaml est sensible à l'indentation, qui doit être faite uniquement avec des espaces…

La Documentation officielle est très complète (peut-être trop).

Voici un résumé des modifications par rapport au fichier par défaut :

hosts

/etc/ejabberd/ejabberd.yml

hosts:
  - "federez.net"

Certificats

Depuis la version 17.10, ejabberd implémente ACME et devrait donc pouvoir gérer lui-même ses certificats et leur renouvellement automatique. Dans la pratique, ça n'est pas possible car on souhaite fournir aux usagers un ID de la forme joe@federez.net (au lieu de joe@xmpp.federez.net), il faut donc que dodecagon (vers qui pointe le NDD) signe le certificat pour utilisation par dragon.

On a donc au minimum besoin d'ajouter les lignes suivantes au script /root/scripts/renew_letsencrypt_certificates.sh sur dodecagon:

/usr/bin/letsencrypt certonly --cert-name dragon.federez.net --config /etc/letsencrypt/cli.ini --non-interactive --quiet \
  -d federez.net \
  --text

ejabberd supporte un format de certificats concaténés:

cat /etc/letsencrypt/live/dragon.federez.net/privkey.pem /etc/letsencrypt/live/dragon.federez.net/fullchain.pem > /tmp/ejabberd.pem
scp /tmp/ejabberd.pem ejabberd@dragon.federez.net:~/ejabberd.pem

On oubliera évidemment pas d'adapter en conséquence le code de vérification.

Du coté de dragon, il faut ensuite ajouter la clé publique de root@dodecagon au fichier ~ejabberd/.ssh/authorized_keys. On ajoute au début de la ligne les restrictions suivantes :

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -t ~/ejabberd.pem" ssh-ed25519 AAAAC3...

On peut ensuite remplacer toutes les apparition de certfile: dans /etc/ejabberd/ejabberd.yml par:

certfile: "<ejabberd home>/ejabberd.pem"

Au passage vous pouvez en profiter pour décommenter les instances de - “no_tlsv1”.

Authentification LDAP

On souhaite fournir ce service à tous les membres de FedeRez, on utilise donc l'authentification LDAP.
ejabberd ne supporte pas ldap avec STARTTLS, on utilise donc ldaps sur le port 636.

On commente donc auth_method: internal et on remplit le bloc ldap:

auth_method: ldap
ldap_servers:
  - "ldap.federez.net"
ldap_encrypt: tls
ldap_port: 636
ldap_rootdn: "cn=xmpp,ou=service-users,dc=federez,dc=net"
ldap_password: "P455w02d"
ldap_base: "ou=users,dc=federez,dc=net"
ldap_uids:
  - "cn": "%u"

On n'oubliera bien-sûr pas de créer l'utilisateur ad-hoc sur le LDAP federez.

Access Control

On ne veut pas laisser le serveur grand ouvert, on va donc restreindre l'accès à certaines fonctionnalités:

  register:
    - deny

Bridge IRC

On utilise [admin:services:biboumi] pour relier le serveur XMPP à IRC.
Par défaut, [admin:services:biboumi] se connecte sur le port 5347, on modifie donc le bloc ejabberd_service en conséquence :

  -
    port: 5347
    module: ejabberd_service
    access: local
    shaper_rule: fast
    ip: "127.0.0.1"
    privilege_access:
       roster: "both"
       message: "outgoing"
       presence: "roster"
    hosts:
      "irc.xmpp.federez.net":
        password: "<gateway password>"

À noter : le mot de passe est le même que celui défini dans la conf de biboumi.

Biboumi n'est pas packagé pour debian, il faut donc le compiler depuis les sources:

un checkout du dépôt git officiel se trouve dans dragon:/home/lhark/build/biboumi.
depuis ce dossier, la compilation se fait avec cmake . && make -j5 && sudo make install
Biboumi fournit un fichier d'unit systemd, donc service biboumi start suffit pour lancer le service

À l'heure actuelle, Biboumi stocke les logs des utilisateurs dans une base de données sqlite: /var/lib/biboumi/biboumi.sqlite
Depuis la version 7, il est possible d'utiliser postgresql pour ça, et migrer sur un serveur pg backupé est un point d'amélioration intéressant pour la pérennité des logs IRC.

Todo / futures améliorations

MAM archives: En l'état les logs des utilisateurs sont stockés dans mnesia, dont la taille limite est de 2GB. Comme biboumi, ejabberd supporte PostgreSQL, il serait judicieux de migrer l'archivage des messages hors mnesia, et utiliser ejabberdctl delete_old_mam_messages périodiquement en attendant.
http-upload, direct tls, multiplexing, …: En l'état, ejabberd écoute sur une série de ports (5222, 5280, 5444) pour fournir certains services côté client (XMPP-server, bosh+websockets, http upload) qui, du coup, peuvent se retrouver indisponibles derrière des connexions censurées (hôtel, aéroport, public hostpot, café, …) ne laissant généralement que le 80/443 ouverts. L'idée est de multiplexer ces services via le port 443 en utilisant sslh. Ci-dessous une possible conf sslh adaptée à XMPP:

listen:
(
    { host: "dragon IP"; port: "443"; }
);

protocols:
(
     # ssh over 443 for road warriors
     { name: "ssh"; service: "ssh"; host: "localhost"; port: "2222"; },

     # XMPP supports connections over 443 from startls and direct tcp
     { name: "tls"; host: "localhost"; port: "5223"; alpn_protocols: [ "xmpp-client" ]; log_level: 0;},
     { name: "xmpp"; host: "localhost"; port: "5222"; },

     # Apache listens for redirected trafic on 8443
     { name: "http"; host: "localhost"; port: "80"; },
     { name: "tls"; host: "localhost"; port: "8443"; log_level: 0; },
     { name: "anyprot"; host: "localhost"; port: "8443"; }
);

SRV records: XMPP supporte désormais un mode de connexion qui autorise l'envoi de SSL direct (ce qui évite un round-trip comparé à starttls), et sslh permet de multiplexer ce type de streams. Afin que les clients (surtout mobiles) en bénéficient, il faut le renseigner dans les DNS

_xmpp-client._tcp.example.com. 18000 IN SRV 0 5 5222 xmpp.example.com. (C2S défaut)
_xmpp-client._tcp.example.com. 18000 IN SRV 0 4 443 xmpp.example.com. (XMPP over 443 avec starttls)
_xmpps-client._tcp.example.com. 18000 IN SRV 0 3 443 xmpp.example.com. (XMPP over 443 avec direct tls)
_xmpp-server._tcp.example.com. 18000 IN SRV 0 5 5269 xmpp.example.com. (S2S défaut)
_xmpps-server._tcp.example.com. 18000 IN SRV 0 5 5270 xmpp.example.com. (pas franchement nécessaire, S2S direct)

Pour tester l'enregistrement DNS:
dig _xmpp-client._tcp.tamytro.org SRV (défaut C2S)
dig _xmpps-client._tcp.tamytro.org SRV (direct C2S)

Pour tester le multiplexing:

openssl s_client -connect tamytro.org:443 -starttls xmpp
openssl s_client -connect tamytro.org:443 -alpn xmpp-client

Todos update status:

SSLH est installé et fonctionnel, mais pas testé les différentes options de multiplexage car pas de DNS record pour les solliciter
Certificate mismatch pour http-upload à corriger
DNS à mettre à jour