Table des matières

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).

Connexion au réseau

Il y a deux possibilités pour se connecter en XMPP aux canaux de discussions liés à FedeRez (hébergés sur le réseau IRC RezoSup) :
- directement en XMPP via les services de FedeRez avec un compte XMPP hébergé par FedeRez (nécessite une inscription) ;
- via une passerelle (souvent Biboumi) non-gérée par FedeRez pour se connecter directement à IRC.

Seule la première solution est réellement décrite ici (mais des éléments utiles à le 2e se trouvent dans la 2e partie).

Avec Gajim (client ordinateur)

Connexion au serveur XMPP

Tout d'abord, il faut évidemment lancer Gajim…

Si ce n'est pas la première fois que vous l'utilisez, dans le menu de Gajim, allez dans « Gajim », « Comptes » puis « Ajouter un compte… ».

Dans l'assistant qui s'ouvre, indiquez que vous avez déjà un compte, et indiquez « federez.net » comme serveur ainsi que que votre nom d'utilisateur et mot de passe du LDAP de FedeRez (si vous n'en avez pas, vous pouvez envoyer un mail à admin@federez.net ou demander au bureau de l'association dont vous êtes ou étiez membre).

Puis validez en demandant une connexion immédiate.

Accès aux canaux IRC

Dans le menu de Gajim, allez dans « Compte(s) » puis « Découvrir les services ».

Sélectionnez « Biboumi XMPP-IRC gateway » et utilisez « Rejoindre ».

Une fenêtre s'ouvre pour vous demander quel salon de discussion vous souhaitez rejoindre, vous pouvez par exemple choisir « #federez%irc.rezosup.org » pour vous connecter au canal #federez de RezoSup. Vous pouvez également choisir le pseudonyme que vous souhaitez avoir côté IRC.

Avec Conversations (client mobile Android)

  1. Installer l'application (payante sur le Play Store mais dispo sur F-droid)
  2. Ajouter un compte:
    • addresse XMPP : <username_federez>@federez.net (exemple : moamoak@federez.net)
    • mot de passe : <federez_ldap_password> (exemple : S3cr3T)
  3. Conversation devrait réussir à se connecter et affiche les utilisateurs connectés au même serveur (à savoir l'ensemble des gens qui possèdent un compte FedeRez même s'il n'ont jamais utilisé XMPP)
  4. Ajouter les chans IRC que vous voulez rejoindre;
    1. Choisir “Rejoindre le canal public”
    2. Utiliser le compte FedeRez (celui qu'on vient de créer) (exemple : moamoak@federez.net)
    3. Rentrer une addresse XMPP au format #<chan>%<irc_network>@<gateway_server> (exemple : #federez%irc.rezosup.org@irc.xmpp.federez.net)
    4. Vous devriez voir 2 conversations apparaitre : une pour le status IRC sur irc.rezosup.org (globalement, on s'en fout) et une pour le chan que vous venez de rejoindre (les futurs chans n'ajouteront qu'une conversation car celle du status est la même)
    5. Parlez sur votre chan favori. Votre pseudo IRC est votre nom d'utilisateur FedeRez (exemple : moamoak)

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"

Côté dragon, certbot est également utilisé pour générer les certificats qui seront utilisés par 'mod_http_upload' pour l'envoi de fichiers.

Au final, ejabberd gère donc les certificats: 

certfiles:
  - "/var/lib/ejabberd/ejabberd.pem" ← pour la connexion des utilisateurs
  - "/var/lib/ejabberd/ejabberd-http.pem" ← pour le reste (http-upload)

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:

À 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.

SSLH/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.

sslh est désormais déployé, est sa configuration se trouve dans /etc/sslh.cfg

DNS/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.federez.net. 18000 IN SRV 4 0 5222 xmpp.federez.net.
_xmpp-client._tcp.federez.net. 18000 IN SRV 3 0 443 xmpp.federez.net.
_xmpps-client._tcp.federez.net. 18000 IN SRV 4 0 5223 xmpp.federez.net.
_xmpps-client._tcp.federez.net. 18000 IN SRV 3 0 443 xmpp.federez.net.
_xmpp-server._tcp.federez.net. 18000 IN SRV 0 5 5269 xmpp.federez.net.
_xmpps-server._tcp.federez.net. 18000 IN SRV 0 5 5270 xmpp.federez.net.

Pour tester l'enregistrement DNS: 

dig srv _xmpp-client._tcp.federez.net
dig srv _xmpps-client._tcp.federez.net
...

Pour tester le multiplexing (et autres): 

# XMPP client classique
openssl s_client -connect xmpp.federez.net:5222 -starttls xmpp -xmpphost federez.net
# XMPP client multiplexé over 443
openssl s_client -connect xmpp.federez.net:443 -starttls xmpp -xmpphost federez.net
# XMPP client direct (multiplexé)
openssl s_client -connect xmpp.federez.net:5223 -alpn xmpp-client -xmpphost federez.net
# XMPP client multiplexé over 443
openssl s_client -connect xmpp.federez.net:443 -alpn xmpp-client -xmpphost federez.net
# XMPP server classique
openssl s_client -connect xmpp.federez.net:5269 -starttls xmpp-server -xmpphost federez.net
# XMPP server direct
openssl s_client -connect xmpp.federez.net:5270 -alpn xmpp-server -xmpphost federez.net

Todo / futures améliorationss