Lonewolf v0.3.0 ajoute la fédération XMPP et le support TLS direct

Les mainteneurs du serveur XMPP Lonewolf ont publié la version 0.3.0, une mise à jour majeure qui introduit des capacités de fédération entre serveurs. Publiée le 13 novembre 2026, cette version permet aux instances Lonewolf isolées de communiquer avec des utilisateurs sur d'autres réseaux XMPP, marquant un pas important vers l'interopérabilité pour cette plateforme de communication auto-hébergée.

Ce qui s'est passé

L'ajout le plus notable dans cette version est la fédération, qui permet aux serveurs Lonewolf d'échanger des messages, des informations de présence, des IQs et des abonnements au roster avec des serveurs XMPP externes. Cette fonctionnalité s'active automatiquement si l'hôte possède un certificat valide et un nom DNS public, ne nécessitant aucune configuration supplémentaire de la part de l'administrateur. Le système authentifie les serveurs pairs exclusivement via des certificats, exigeant que le serveur distant présente un certificat de confiance et prenne en charge SASL EXTERNAL. Notamment, Lonewolf ne prend pas en charge l'ancien mécanisme Server Dialback pour l'authentification.

Lorsque les deux serveurs le prennent en charge, ils établissent une seule connexion partagée pour le trafic bidirectionnel, conformément à XEP-0288. De plus, les serveurs échangent leurs limites de taille de stanza et d'inactivité au préalable via XEP-0478 pour optimiser l'utilisation des ressources. Pour garantir la sécurité, Lonewolf vérifie les listes de révocation de certificats (CRL) publiées par l'autorité de certification, en les récupérant via HTTP simple. Si une CRL ne peut pas être téléchargée, la connexion se poursuit malgré tout, bien que les administrateurs puissent désactiver ces téléchargements ou pointer vers des fichiers locaux en utilisant des indicateurs de configuration spécifiques.

Au-delà de la fédération, la version introduit le support TLS direct pour les clients et les serveurs, permettant des connexions chiffrées dès le premier octet tel que défini dans XEP-0368. De nouveaux écouteurs dédiés gèrent ces connexions, et la découverte de fédération sortante identifie désormais les points de terminaison STARTTLS et TLS directs. La mise à jour améliore également la compatibilité avec les clients de bureau en activant Private XML Storage pour les paramètres et les favoris, ainsi que les requêtes Software Version qui identifient le serveur sans révéler le système d'exploitation sous-jacent sauf si cela est explicitement configuré.

Détails clés

• La fédération est activée par défaut pour les hôtes disposant d'un nom DNS public et d'un certificat valide, reposant uniquement sur l'authentification basée sur les certificats.
• Le TLS direct (XEP-0368) est pris en charge via de nouveaux écouteurs dédiés, permettant le chiffrement dès l'octet initial de la connexion.
• Les listes de révocation de certificats sont récupérées via HTTP simple, mais les connexions se poursuivent même si ces listes sont indisponibles.
• L'authentification SCRAM-SHA-512 est disponible en option, bien qu'elle provienne d'un Internet-Draft expiré plutôt que d'une RFC officielle.
• L'activation de SHA-512 modifie la manière dont les identifiants sont stockés, rendant le retour à la version 0.2.0 difficile pour les comptes affectés.
• L'outil de benchmark a été renommé de lonewolf-bench à lonewolfbench, nécessitant des mises à jour de tous les scripts de build existants.

Contexte

XMPP, ou Extensible Messaging and Presence Protocol, est un standard ouvert pour la communication en temps réel qui alimente de nombreux systèmes de chat auto-hébergés. La fédération est un concept central dans XMPP, permettant à différents serveurs d'interagir comme le font les fournisseurs de messagerie électronique. Sans fédération, les utilisateurs sur un serveur ne peuvent communiquer qu'avec ceux de la même instance, créant des silos isolés. Activer la fédération nécessite des mesures de sécurité robustes, telles que l'authentification mutuelle TLS, pour garantir que les serveurs se font confiance avant d'échanger des données utilisateur.

Le TLS direct diffère de la méthode traditionnelle STARTTLS, où une connexion commence en clair puis est ensuite améliorée vers le chiffrement. Avec le TLS direct, la poignée de main de chiffrement se produit immédiatement, réduisant la surface d'attaque associée à l'échange initial de données non chiffrées. Cela est particulièrement pertinent pour les normes de sécurité modernes qui découragent toute transmission en clair, même brièvement. Les administrateurs auto-hébergés doivent gérer les certificats avec soin pour maintenir ces connexions sécurisées, surtout lorsqu'ils traitent des certificats à courte durée de vie provenant de fournisseurs comme Let's Encrypt.

Pourquoi c'est important

Pour les équipes qui gèrent leur propre infrastructure de communication, la capacité de fédérer brise les barrières d'isolation. Auparavant, adopter Lonewolf signifiait s'engager envers un groupe fermé d'utilisateurs au sein d'un seul serveur. Désormais, les organisations peuvent conserver le contrôle de leurs données tout en collaborant avec des partenaires, des clients ou des membres de la communauté sur différents serveurs XMPP. Cette flexibilité est cruciale pour les petites et moyennes entreprises qui souhaitent la souveraineté sur leurs outils sans sacrifier la connectivité.

Cependant, le modèle de sécurité repose fortement sur une gestion appropriée des certificats. Puisque Lonewolf authentifie les pairs uniquement via des certificats et récupère les listes de révocation via HTTP simple, les administrateurs doivent s'assurer que leur infrastructure TLS est robuste. Le changement dans le stockage des identifiants pour SCRAM-SHA-512 introduit également un risque de migration. Les équipes expérimentant des méthodes d'authentification plus fortes doivent être conscientes que le retour en arrière n'est pas simple, ce qui pourrait les verrouiller dans la nouvelle version pour les comptes utilisateurs affectés.

Ce que vous pouvez faire

• Vérifiez que votre serveur dispose d'un nom DNS public valide et d'un certificat TLS de confiance pour activer la fédération automatiquement.
• Examinez votre configuration pour décider s'il faut désactiver la récupération des CRL ou utiliser des fichiers locaux si les téléchargements via HTTP simple posent problème.
• Mettez à jour tous les scripts de build ou de déploiement pour référencer lonewolfbench au lieu de l'ancien nom lonewolf-bench.
• Testez la compatibilité des clients de bureau en vous assurant que Private XML Storage et les requêtes Software Version fonctionnent comme prévu.
• Faites preuve de prudence lors de l'activation de SCRAM-SHA-512, en notant que cela modifie les formats de stockage des mots de passe et empêche un retour en arrière facile.
• Surveillez attentivement l'expiration des certificats, surtout si vous utilisez des profils à courte durée de vie, car Lonewolf renouvellera tôt lorsque les profils changent.