Journal Quelques nouvelles en vrac de XMPP

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
52
20
jan.
2016
Ce journal a été promu en dépêche : XMPP à fond !.

Sommaire

Salut à tous,

En attendant de publier le prochain article de « parlons XMPP », voici quelques nouvelles en vrac du monde XMPP (particulièrement côté standard), parce que ça bouge beaucoup en ce moment :

Chiffrement

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.

Commençons par expliquer rapidement : XMPP fait du chiffrement naturellement entre client et serveur, et entre serveurs, chiffrement qui est obligatoire depuis 1 an 1/2. 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.

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.

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 (raison pour laquelle je l'utilise personnellement très peu). D'autre part il ne fonctionne qu'avec une conversation directe et il n'est pas possible de laisser un message hors ligne (parce qu'OTR est un protocole à confidentialité persistante – aussi connu sous le nom de « perfect forward secrecy »).

En parallèle est arrivé Aloxotl, qui corrige plusieurs défauts de 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. 2 XEPs 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. Aussi, et c'est un avis personnel, leur méthode de chiffrement pour les fichiers n'est pas bonne, car elle ne profite pas la souplesse de Jingle, mais ce sont des points qui vont très certainement s'améliorer à force de discussions sur la liste « standards ». À ma connaissance (corrigez-moi si je me trompe), les discussions de groupe type « MUC » sont prévues mais pas encore possibles.

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 ici. Méthode que j'aime particulièrement et qui – elle – chiffre la stanza complète !

Enfin, il y un travail en cours pour une nouvelle intégration, propre cette fois, d'OpenPGP dans XMPP, un brouillon est disponible ici. Je n'ai pas encore eu le temps de regarder ça en détails, aussi on en parlera peut-être une autre fois.

MUC2

La nouvelle version du protocole de discussions de groupe donc je vous avais parlé brièvement dans l'épisode 5 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é 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 par forcément liés à la messagerie de groupe.

Summit et 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: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:40). Je ferai moi même 2 conférences le samedi, une dans la devroom Python à 13:30 où j'expliquerai en quoi Python nous a aidé à développer SàT, et une dans la devroom RTC à 18:00 où j'expliquerai comment nous avons développé un moteur de blog décentralisé basé sur XMPP. Nous devrions également être présents comme l'année dernière au « XMPP lounge », mais pas en permanence, car nous assisterons aussi à d'autres conférences.

Enfin, nous avons décidé de nous rencontrer informellement autour d'une bière avec d'autres projets de communication, en particulier Diaspora. Si vous travaillez sur un de ces projets (ou pas d'ailleurs), n'hésitez pas à me contacter ou à venir me voir après une des confs.

Jingle

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 XEPs et des RFCs 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). Un nouveau transport HTTP est également sorti, à travers la XEP-0370.

Voilà, ce journal que je voulais faire rapide et en vrac m'a finalement pris 2 h, aussi on va dire que c'est un hors série de « parlons XMPP » hein :)

  • # Maître Goffi

    Posté par  . Évalué à 6.

    Merci.

  • # Adresses MIX

    Posté par  . Évalué à 2.

    Un grand merci pour ton journal.

    Les adresses MIX auront quelle forme?

    salon@mix.serveur.com ou mix.serveur.com/salon ?

    • [^] # Re: Adresses MIX

      Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 20 janvier 2016 à 13:35.

      Salut,

      les exemples donnés dans la XEP sont conversation@mix.example.com ou encore coven@mix.shakespeare.example, où mix.shakespeare.example est un domaine MIX. Très similaire à MUC donc.

      Par contre dans MUC les ressources correspondaient aux nicks (par exemple sat@chat.jabberfr.org/goffi pour m'envoyer un message privé sur notre salon), avec MIX ça n'est plus le cas.

  • # Mailing lists

    Posté par  (site web personnel) . Évalué à 4.

    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)

    Le deuxième avantage c'est qu'on peut découpler la présence (ie connecté ou pas, disponible a la conversation ou pas) de la participation au salon de discussion. Parce que par défaut, si je ne m'abuse, lorsque l'utilisateur se déconnecte il quitte automatiquement tous les salons ou il est, et les re-rejoint (automatiquement si c'est configure pour) quand il se reconnecte. Ce qui a du sens pour un protocole oriente messagerie instantanée type IRC, mais vu que XMPP permet les communications asynchrones, ce cote est perdu avec MUC. Avec MIX, on peut dire que l'on est intéressé par un salon et recevoir les messages, que l'on soit connecte ou non… Un peu comme une mailing list, en fait.

    • [^] # Re: Mailing lists

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      C'est vrai, même si techniquement c'est possible avec MUC + MAM (quand tu te reconnectes, tu peux récupérer l'historique), et je pense que les clients à la Conversations veulent partir dans cette direction.

      Je ne suis pas tout à fait convaincu par ça, vu que je pense que le blogage (on dit toujours microblogage parce que la XEP-0277 parle de « microblogging », mais c'est du blogage en fait) fait déjà le job et en mieux : gestion des commentaires, titres, tags, etc. J'ai même un peu peur qu'il y ait volonté d'utiliser le chat de groupe pour faire un « microblogage du pauvre ».

      La direction dans laquelle nous on aimerait partir, c'est utiliser le blog comme base, et fournir différentes « vues » à ceux qui le souhaitent, à grands coups de passerelles si nécessaire : comme une liste de diffusion, comme une forum, comme un blog, etc. On a déjà tout ce qu'il faut pour le faire aujourd'hui, sauf le temps disponible (ou les mains disponibles).

  • # dépêche?

    Posté par  . Évalué à 4.

    Je pense qu'il faut promouvoir ce journal qui a pris 2h à son rédacteur.

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Violences faites aux diptères

    Posté par  . Évalué à 3.

    D'autre part il ne fonctionne qu'avec une conversation directe et il n'est pas possible de laisser un message hors ligne (parce qu'OTR est un protocole à confidentialité persistante – aussi connu sous le nom de « perfect forward secrecy »).

    Sauf funeste erreur de ma part, ça n'a rien à voir. Le PFS est une propriété cryptographique, qui ne dépend pas (et heureusement) de la capacité à "stocker" un message. Après, la page Wikipedia d'OTR rappelle que GTalk disposait d'une option "off-the-records" qui ne faisait qu'annuler (au moins officiellement) l'archivage.

    ICE est une méthode pour faire du « TCP hole punching », une méthode pour traverser les NAT

    Encore sous réserve de bon fonctionnement de mes neurones, c'est à peu près exactement l'inverse : les petits trous du "hole punching" ne sont qu'une des techniques utilisées par l'ICE. En gros, l'ICE c'est "je tente de passer en direct… ah non zut ça passe pas, bah je vais essayer divers contournements de NAT alors …. ah ben non plus, vous auriez un relai TURN sivouplé?".

    • [^] # Re: Violences faites aux diptères

      Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 20 janvier 2016 à 16:35.

      Salut,

      Sauf funeste erreur de ma part, ça n'a rien à voir. Le PFS est une propriété cryptographique, qui ne dépend pas (et heureusement) de la capacité à "stocker" un message. Après, la page Wikipedia d'OTR rappelle que GTalk disposait d'une option "off-the-records" qui ne faisait qu'annuler (au moins officiellement) l'archivage.

      La formulation est sans doute raccourcie, mais c'est bien ce que je voulais dire (et ça n'est bien sûr par une confusion avec l'OTR de GTalk, je n'ai même jamais utilisé ce dernier). Bien entendu une fois que le message est déchiffré, tu peux en faire ce que tu veux, mais le principe de le confidentialité persistante, du moins telle qu'implémentée dans OTR, fait que tu as une clef temporaire, jetable, et qu'il faut être en ligne en même temps pour échanger le message, du coup c'est à cause de PFS que tu ne peux pas utiliser OTR hors ligne. Après je ne suis pas expert en chiffrement, il est possible que je me trompe.

      D'ailleurs dans le brouillon de la nouvelle XEP OpenPGP, ils mentionnent même l'absence de confidentialité persistante (PFS) comme un moyen de chiffrer ses archives MAM.

      Encore sous réserve de bon fonctionnement de mes neurones, c'est à peu près exactement l'inverse : les petits trous du "hole punching" ne sont qu'une des techniques utilisées par l'ICE. En gros, l'ICE c'est "je tente de passer en direct… ah non zut ça passe pas, bah je vais essayer divers contournements de NAT alors …. ah ben non plus, vous auriez un relai TURN sivouplé?".

      Une autre XEP que je n'ai pas encore implémenté, donc que je ne maîtrise pas. Il faudrait à ce moment changer comme suit:

      s/ICE est une méthode pour faire du « TCP hole punching », une méthode pour traverser les NAT/ICE est une méthode pour faire de la traversée de NAT/

      Si un modo passe par là…

      Merci pour la correction.

      • [^] # Re: Violences faites aux diptères

        Posté par  (site web personnel) . Évalué à 4.

        Si un modo passe par là…

        Corrigé, merci.

      • [^] # Re: Violences faites aux diptères

        Posté par  (site web personnel) . Évalué à 10.

        le principe de le confidentialité persistante, du moins telle qu'implémentée dans OTR, fait que tu as une clef temporaire, jetable, et qu'il faut être en ligne en même temps pour échanger le message, du coup c'est à cause de PFS que tu ne peux pas utiliser OTR hors ligne.

        Pas exactement. Il y a deux-et-demi choses importantes à séparer:

        • PFS, Perfect Forward Secrecy: La définition est simple: étant donné une clé lié spécifiquement à un correspondant sur le long terme (nécessaire pour l'identification et l'authentification) et une communication chiffrée avec quelqu'un d'autre, si la clé long-terme est leakée alors les conversations passées ne sont pas dévoilées. Par exemple, PGP, tel qu'utilisé partout (que ce soit dans les mails, dans l'ancienne XEP ou dans la nouvelle), n'a pas de PFS: si ta clé privée fuite alors toutes tes conversations seront en clair. Par contre si tu hackes le truc et que tu crées une nouvelle paire de clés asymétriques pour chaque message et que tu signes chacune de ces nouvelles paires avec ta clé identité long-terme, alors tu as du PFS: si la clé long terme fuite, il est impossible de déchiffrer les messages passés. La définition peut aller plus loin en disant que si une clé éphémère (cad celle utilisée pour chaque message) fuite, alors l'intégrité des messages précédents n'est pas compromise.
        • PFS', Perfect Future Secrecy: Le terme n'est pas très répandu parce que la plupart des gens ne voient pas la différence avec le point précédent, ou alors ils pensent que l'un inclue l'autre. En partant de la même configuration, à savoir une clé identité long-terme et une clé éphémère par message: un système a de la PFS' si une clé fuite et que l'intégrité des messages futurs n'est pas compromise. Les deux ne sont pas forcément équivalents. Si par exemple tu utilises une clé symétrique pour chiffrer un message, et qu'à chaque message que tu envoies tu prends la clé précédente et tu la passe dans un KDF, alors tu auras de la forward secrecy (vu que tu passes dans une KDF il est impossible de remonter le "courant") mais pas de la future secrecy (parce que suivre le "courant" vers l'aval est trivial).
        • otr, Off-the-Record: c'est quelque chose qui pour le coup vient du monde "physique", où deux participants à une conversation veulent qu'il n'y ait pas de traces de ce qu'il s'est passé. Il y a d'ailleurs une section là-dessus dans la XEP-0136 (Archive Management): l'émetteur dit simplement "n'enregistre pas ce message stp". Une autre manière de faire, c'est de donner les billes pour que techniquement, quelqu'un qui veut faire de l'otr puisse dire "c'est pas moi qui ai écrit ça, regardez, n'importe qui aurait pu écrire ça et se faire passer pour moi" (bien sûr ceci arrive après la conversation, de sorte que ceux qui discutent savent que l'autre est bien l'autre, mais qu'après coup un tiers n'en ait aucune assurance). On parle aussi de Plausible deniability. D'ailleurs le concept me plait moyen, mais c'est autre chose.

        Du coup quand on parle de l'archivage c'est pas lié à PFS, qui ne regarde que le chiffrement des messages en cours de transition, mais bien à la plausible deniability, où les participants veulent à tout prix effacer les traces et pour le peu qui subsistent faire comme si ils n'avaient jamais écrit ça. Malheureusement OTR est à la fois une politique de "pas de traces svp" et un protocole répandu dans XMPP, qui fait bien de la deniability mais aussi de la PFS. À cause de ça à chaque fois qu'on parle de chiffrement de bout en bout, il y a des gens pour se plaindre que les messages ne sont pas chiffrés au bout ou qu'il reste une trace, parce qu'ils s'attendent à avoir les même garanties qu'OTR.

        Un autre point: le fait qu'OTR nécessite que les deux partis soient en ligne pour discuter n'est pas lié au fait qu'OTR essaie de faire de la PFS où de la deniability, mais juste que c'est un mauvais protocole. J'en veux pour preuve la crypto dans Signal, à savoir Axolotl, qui est capable de fournir la même chose qu'OTR tout en fonctionnant hors-ligne. Bon, c'est un peu du marketing, parce que pour que ça fonctionne hors-ligne il faut quand même le support d'un serveur (que Signal fournit) pour que ça marche. Mais c'est possible.

        Pour (beaucoup) plus de détails, voir les articles de blog sur les parties crypto croustillantes de Signal (ex-TextSecure) par les gens d'OpenWhisper (c'est principalement de là que je sors tout ça):

        • Asynchronous Security, où ils montrent comment faire de l'asynchrone tout en ayant de la PFS
        • Simplifying OTR deniability, où ils regardent un peu plus précisément à quoi ressemble la deniability d'OTR, en quoi elle est pas parfaite et comment ils l'ont amélioré
        • Advanced Ratcheting, où ils rentrent en détails dans le protocol utilisé par Signal, à savoir Axolotl (cf lien précédent), et où ils font justement la différence entre forward secrecy et future secrecy, que c'est pas si simple que ça

  • # Chiffrement de bout en bout

    Posté par  . Évalué à 2.

    Pour le chiffrement de bout en bout, il y a le groupe de travail JOSE de l'IETF qui a sorti quelques RFC sur des formats pouvant être utilisés pour le chiffrement (entre autres). C'est l'un des buts affichés directement dans leur RFC décrivant des cas d'usage.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.