XMPP à fond !

En attendant de publier le prochain article de Parlons XMPP, voici quelques nouvelles en vrac du monde XMPP — particulièrement côté standard.

XMPP bouge beaucoup en ce moment :

• chiffrement de bout en bout ;
• protocoles de discussion de groupe ;
• 19^eXMPP Summit à Bruxelles ;
• FOSDEM 2016 ;
• Jingle ;
• implémentations.

Sommaire

• Chiffrement
  • Bout en bout : OTR vers Axolotl
  • Client à serveur et serveur à serveur : TLS
  • L’ancienne méthode : OpenPGP
  • Le bout en bout un peu fouillis : OTR
  • Le bout en bout moderne : Aloxotl
  • Côté IETF
  • Et re-OpenPGP
• Les salons de discussion
  • MIX
  • MUC light
• XMPP Summit et FOSDEM
  • FOSDEM
  • XMPP Summit
  • Rencontre réseaux sociaux XMPP
• Jingle
  • ICE-TCP
  • Transport HTTP
• Implémentations
  • Openfire 4.0 !
  • Movim 0.9
  • Prosody 0.9.9
  • Gajim 0.16.5
• Dépêches régulières ?

Chiffrement

Bout en bout : OTR vers Axolotl

Côté chiffrement de bout en bout, déjà. Vous avez peut‐être entendu parler de OMEMO ? C’est une nouvelle méthode de chiffrement basée sur Axolotl, qui a pour objectif de remplacer OTR.

Client à serveur et serveur à serveur : TLS

Commençons par expliquer rapidement : XMPP fait du chiffrement naturellement entre client et serveur, et entre serveurs, chiffrement qui est obligatoire depuis un an et demi, et qui se fait via TLS. Mais, comme tout le monde n’a pas son propre serveur, il est possible que vous n’ayez pas confiance en votre administrateur. Ou alors vous avez confiance en lui, mais vous ne savez pas si sa machine est sûre (par exemple, elle peut être hébergée en France — ou ailleurs — où des boîtes noires sont possibles). Pour protéger votre communication, même aux yeux de l’administrateur, il faut alors utiliser du chiffrement de bout en bout et c’est un domaine où XMPP n’a pas encore trouvé de solution convenable.

L’ancienne méthode : OpenPGP

Il y a eu d’abord une XEP pour utiliser OpenPGP, qui était une XEP dite « historique », c’est à dire basée sur l’usage existant. Cette XEP (la XEP-0027) posait des problèmes de sécurité et a été dépréciée pour cette raison.

Le bout en bout un peu fouillis : OTR

Quelques tentatives plus tard, OTR est apparu et est devenu la mode. Si bien que plusieurs clients XMPP se sont mis à l’utiliser, mais sans XEP. Autrement, dit c’était un peu la fête, surtout qu’OTR dispose de sa propre méthode de découverte indépendante du discovery de XMPP, que certains s’amusaient à mettre du XHTML dans le message sans rien pour le préciser (amenant à des situations comme « j’essaye de décoder du XHTML, pas d’erreur ? Si ? Alors, je prends ça comme du texte. »). Heureusement, une XEP a été publiée récemment pour améliorer la situation, la XEP-0364. On voit bien ici l’intérêt de la standardisation, c’est un cas d’école.

D’autres problèmes sont liés à OTR : il ne chiffre que le contenu du <body/>, c.‐à‐d. le cœur du message. Comme des tas d’extensions ajoutent des informations en dehors du <body/>, il est risqué de les utiliser avec OTR. Autrement dit, il vaut mieux que le client désactive tout quand il utilise OTR. D’autre part, il ne fonctionne qu’avec une conversation directe et il n’est pas possible de laisser un message hors ligne.

Le bout en bout moderne : Aloxotl

En parallèle est arrivé Aloxotl, qui corrige plusieurs défauts d’OTR. Désirant l’implémenter, les développeurs du client Conversations ont pu bénéficier du Google Summer of Code, sous l’égide de la XSF, à condition qu’ils rédigent une XEP.

Ceci a donné OMEMO, qui apporte principalement une synchronisation entre les ressources XMPP (et donc entre les appareils) et les messages hors ligne. Deux XEP ont donc été proposées (cf. le lien précédent), l’une pour le cœur d’OMEMO, l’autre pour son utilisation avec le transfert de fichiers Jingle. Malheureusement, elle souffre du même défaut qu’OTR, c’est‐à‐dire qu’elle ne chiffre que le <body/> du message. [N. D. L. A. : aussi, et c’est un avis personnel, leur méthode de chiffrement pour les fichiers n’est pas bonne, car elle ne profite pas de la souplesse de Jingle, mais ce sont des points qui vont très certainement s’améliorer à force de discussions sur la liste « standards »]. Les discussions de groupe type MUC sont prévues mais pas encore possibles.

Côté IETF

Mais ça n’est pas tout ! Il y a eu également un travail sur une méthode de chiffrement faite par l’IETF, dont on peut consulter le brouillon. Méthode qui, elle, chiffre la stanza complète !

Et re-OpenPGP

Enfin, il y un travail en cours pour une nouvelle intégration, propre cette fois, d’OpenPGP dans XMPP, dont un brouillon est disponible.

Les salons de discussion

MIX

La nouvelle version du protocole de discussion de groupe (mentionnée brièvement dans l’épisode 5 de Parlons XMPP) a désormais une XEP officielle ! Elle est très intéressante et a un gros potentiel, on ne parle plus de MUC 2 désormais, mais de MIX pour Mediated Information eXchange (échange d’information avec modération), spécifiée dans la XEP-0369.

Les avantages sont nombreux, en voici quelques-uns :

• tout est basé sur PubSub ;
• ça fonctionne bien avec différentes ressources qui partagent le même surnom (« nick »), avant ça n’était possible qu’avec des bidouilles plus ou moins sales ;
• les présences, qui étaient à la base de MUC, sont facultatives dans MIX. L’absence de présence est surtout utile pour réduire (de beaucoup) le trafic (et donc améliorer la durée de vie de la batterie sur appareils mobiles) ;
• bien meilleure synchronisation, plus besoin de logs sur un site séparé : il suffit de retourner dans le salon pour savoir tout ce qui s’est dit pendant votre absence ;
• possibilité de suivre un salon en « invisible » ;
• la gestion du surnom (« nick ») d’une entité est découplée de la façon de s’y adresser, ainsi on peut continuer de s’adresser à quelqu’un de la même façon, même après un changement de pseudo ;
• devrait pouvoir fonctionner en « MUC fédéré » (XEP-0289), c.‐à‐d. (en gros) un salon réparti sur plusieurs serveurs ;
• extensible, la technologie peut être utilisée pour autre chose que des conversations de groupe, ou pour partager tout type de données.

Sans trop entrer dans les détails, en gros un salon MIX agit comme un service PubSub et contient des « nœuds » qui sont facultatifs. Chaque nœud gérant une information (présence, messages, sujet sur salon, configuration, etc.), on interagit avec le nœud qui nous intéresse de la même façon que pour un nœud PubSub traditionnel.

La XEP étant toute récente, elle comporte encore beaucoup de zones non remplies, elle risque d’évoluer très fortement au cours de l’année, et on verra peut-être des nouvelles utilisations pas forcément liées à la messagerie de groupe.

MUC light

Erlang Solutions (serveur MongooseIM) a également proposé son extension pour les salons de discussions, son nom est MUC light pour l’instant, mais il est probable que cela change. L’extension a été proposée et refusée avec commentaires, donc elle évoluera. De plus, elle entre un peu en compétition avec MIX, chose commune dans le petit monde des standards.

L’approche est intéressante car très simple : MUC light reprend MUC, tout en le simplifiant et en l’optimisant pour le mobile (consommation de bande passante et de batterie). Les implémentations auront donc un effort minimaliste à produire. De plus, elle implémente un ensemble de besoins concrets de vrais clients de l’entreprise, qui ont poussé cela en production. Le code du serveur est libre : branche muc_light du dépôt MongooseIM.

Les avantages sont nombreux, en voici quelques‐uns :

• basée sur MUC : l’effort pour prendre en charge cette extension est donc minimaliste par rapport à MIX ;
• pas basée sur PubSub, qui est très verbeux, et pas complètement pris en charge par les implémentations (MUC est très largement pris en charge) ;
• pas de présence, ce qui allège considérablement le trafic ;
• basé sur un ensemble de besoins de vrais clients concrets, qui ont vraiment des group chats en production (cela ne part pas de discussions théoriques, dont les implémentations ne sont que probables et à des dates lointaines et inconnues) ;
• implémentation serveur existante ;
• fonctionne avec MAM (XEP-0313: Message Archive Management).

XMPP Summit et FOSDEM

FOSDEM

La semaine prochaine aura lieu le 19ᵉ XMPP Summit à Bruxelles, immédiatement suivi du FOSDEM, où XMPP fait son grand retour dans une devroom « RTC » (real-time communications, communications temps réel) avec SIP. Le programme est alléchant (cf. https://fosdem.org/2016/schedule/track/real_time/), avec notamment Nÿco, bien connu ici, qui aura une conférence samedi à 12 h 50 (soyez à l’heure, les conférences sont souvent courtes au FOSDEM). Edhelas de Movim aura également une conférence, mais dans une autre salle (salle H.2215 samedi à 17 h 40). Goffi fera deux conférences le samedi, une dans la devroom Python à 13 h 30, où il expliquera en quoi Python a aidé à développer SàT, et une dans la devroom RTC à 18 h à propos du développement d’un moteur de blog décentralisé basé sur XMPP. Les différents participants vont également être présents comme l’année dernière au XMPP lounge, mais pas en permanence (beaucoup assistent aussi à d’autres conférences).

XMPP Summit

Le Sommet XMPP a lieu deux fois dans l’année, dont une au FOSDEM à Bruxelles, et l’autre à l’OSCON. Ce sommet a lieu en marge du FOSDEM, les deux jours précédents. Le programme est en cours d’écriture.

Rencontre réseaux sociaux XMPP

Plusieurs membres de projets de communications (notamment Diaspora, Movim et SàT) ont décidé de se rencontrer informellement autour d’une bière. Si vous travaillez sur un de ces projets (ou pas, d’ailleurs), n’hésitez pas à nous contacter (en commentaire, par exemple) ou à venir nous voir après une des confs. Nous aimerions bien voir des gens de GNU Social, Friendica, Hubzilla, SeenThis, etc.

Jingle

ICE-TCP

Pour finir, on peut noter qu’il y a de l’activité autour de Jingle (épisode expliquant le fonctionnement à venir), notamment par le bien connu Peter Saint‐Andre — déjà auteur ou coauteur d’une très grande partie des XEP et des RFC XMPP —, en particulier le transport ICE-TCP est à paraître et va compléter le ICE-UDP déjà disponible (ICE est une méthode pour faire de la traversée de NAT).

Transport HTTP

Un nouveau transport HTTP est également sorti, à travers la XEP-0370: Jingle HTTP Transport Method.

Implémentations

Openfire 4.0 !

Dave Cridland nous a produit un effort remarquable : il a publié Openfire 4.0 ! Le vénérable serveur XMPP développé en Java sous licence Apache 2.0.

Movim 0.9

Movim est sorti en version 0.9 ! Ne vous y trompez pas, malgré le numéro de version inférieur à 1, c’est une version majeure. La liste des changements est impressionnante ! Une dépêche complète arrivera bientôt.

Vous pouvez déjà tester cette nouvelle version sur les Pods français : pod.movim.eu, néerlandais : nl.movim.eu et italien : it.movim.eu ou jeter un œil sur le site officiel.

Prosody 0.9.9

Une nouvelle version du populaire serveur Prosody est également sortie, principalement de sécurité. L’annonce est visible ici.

Gajim 0.16.5

Gajim continue son chemin avec une version mineure améliorant principalement l’implémentation de MAM.

Dépêches régulières ?

Comme l’activité de XMPP est très dynamique en ce moment, nous sommes plusieurs personnes à vouloir rédiger des dépêches collectives régulières (1 fois/mois) pour donner des nouvelles sur XMPP, un peu dans l’esprit des dépêches noyau.

Si d’autres personnes sont intéressées à participer, n’hésitez pas !

Aller plus loin

• Journal à l’origine de la dépêche (258 clics)