ChatSecure est un client de messagerie XMPP chiffré pour iOS. Il est publié sous licence GPL v3.
Jusqu’ici ChatSecure chiffrait ses messages avec OTR. La version 4.0 de ChatSecure permet d’utiliser OMEMO pour chiffrer ses conversations. Cette nouvelle fonctionnalité a été ajoutée avec l’aide de Daniel Gultsch, le développeur du client Conversations et superviseur du développement par Andreas Straub du protocole OMEMO.
Trois personnes utilisant chacune soit ChatSecure, soit Conversations.im (Android) soit Gajim (Windows & GNU/Linux) peuvent tenir une conversation chiffrée avec OMEMO.
Sommaire
- Historique
- À quoi sert OMEMO ?
- Avantages d’OMEMO et XMPP par rapport aux autres logiciels
- OMEMO dans ChatSecure
- Autres nouveautés de ChatSecure
- À venir
- Hébergements XMPP à jour conseillés
- JabberFR cherche un développeur ou une développeuse Web
Historique
ChatSecure est un client XMPP pour iPhones et iPads permettant de chiffrer ses discussions. Il est proche de The Guardian Project, qui vise à développer et promouvoir des logiciels de chiffrement pour téléphones mobiles. Entre 2013 et 2016 une version Android était développée par une autre équipe, mais celle‐ci a dérivé le projet sous un autre nom : Zom. Ce projet se veut plus facile d’utilisation et plus jovial. Cependant, il lui est reproché de mettre au second plan, voire d’empêcher, la fédération avec le reste de l’écosystème XMPP.
Dorénavant, l’équipe de ChatSecure iOS conseille Conversations.im comme client XMPP pour Android.
À quoi sert OMEMO ?
OMEMO pour « OMEMO Multi‐End Message and Object Encryption » soit « OMEMO chiffrement de messages et objets pour plusieurs destinations ».
OMEMO est une adaptation pour XMPP du protocole Signal-Axolotl initialement développé par Open Whisper Systems et utilisé dans les applications de messagerie Signal, WhatsApp et Google Allo. Il a été développé par Andreas Straub durant un GSoC (Daniel Gultsch, le développeur du client Conversations pour Android, ayant été son « mentor ») et il est normalisé par la XEP-0384 au statut encore expérimental.
OTR, qui est le protocole de chiffrement de bout en bout le plus répandu, a de nombreux problèmes, car il a été conçu pour des ordinateurs de bureau et des conversations synchrones. Par exemple, si vous n’avez pas de session OTR active, vous ne pouvez pas démarrer de nouvelle session si votre contact est hors ligne. Même si vous avez une session OTR active, elle peut être abandonnée si l’un des utilisateurs ferme son client (dans le cas de ChatSecure, ça peut être un arrêt automatisé par le système pour manque de mémoire disponible). Ce qui amène à des messages qui disparaissent sans avoir la possibilité d’indiquer quels messages n’ont pas pu être déchiffrés. Il est important de noter que, pour des raisons de confidentialité, ces fonctions peuvent aussi être vues comme des avantages, d’où l’intérêt de garder OTR à disposition.
Un des avantages d’OMEMO est sa compatibilité avec MAM (voir ci‐dessous la description de cette XEP) : on peut synchroniser les messages chiffrés dans l’archive et tout appareil qui a déjà signalé sa prise en charge d’OMEMO (et a été vérifié, selon la politique de sécurité en vigueur) au moment de la discussion peut les déchiffrer et donc fournir un changement d’appareil indolore à l’utilisateur.
OMEMO permet de commencer une conversation chiffrée sur un client, par exemple un téléphone mobile, puis de la poursuivre sur un autre, par un exemple un ordinateur de bureau (en utilisant Gajim et le greffon qui va bien avec), sans rompre la session chiffrée.
OMEMO permet aussi de chiffrer une conversation de groupe. Conversations.im et Gajim supportent déjà cette fonctionnalité. ChatSecure 4 ne la gère pas encore, mais c’est sur la feuille de route pour la version 4.1.
Une autre propriété importante d’OMEMO est la confidentialité persistante (forward secrecy en anglais). En plus des clefs publiques et privées utilisées par les correspondants, des clefs de session sont générées, puis effacées après utilisation. Ainsi, si un attaquant intercepte les discussions et récupère les clefs privées des correspondants, il ne pourra pas déchiffrer les messages. Cependant, il est important de savoir que cette confidentialité persistante est assurée pour les messages lors de leur transport. Or, par défaut et pour des raisons pratiques, les applications Signal, WhatsApp, Conversations, ChatSecure, etc., stockent quand même l’historique des conversations en local. Ainsi, un attaquant peut prendre connaissance de ces conversations en subtilisant ou piratant les terminaux ou les clients où elles sont enregistrées.
Une page récapitule l’avancement de la prise en charge d’OMEMO par les différents clients XMPP.
On peut noter que ni Gajim, ni Conversations, ni ChatSecure n’utilisent l’actuelle version standard, ils utilisent tous une version basée sur libsignal, alors que le standard utilise olm (variante spécifiée par les équipes de Matrix). Ceci dit, la mise à jour devrait être relativement simple (si olm est disponible dans les langages utilisés).
Avantages d’OMEMO et XMPP par rapport aux autres logiciels
Les clients XMPP utilisant OMEMO (ChatSecure, Conversations et Gajim) bénéficient de plusieurs avantages par rapport aux autres clients de messagerie chiffrée, en particulier du point de vue de la sécurité.
Par rapport à WhatsApp ou des clients similaires, ces clients XMPP ont l’avantage de reposer entièrement sur du code source publié et recompilable pour son propre usage. Cela permet d’auditer le code et vérifier l’absence de porte dérobée.
Par rapport à Signal ou des clients libres similaires, XMPP est fédéré. On peut donc utiliser son propre hébergement. Ce point est un avantage, à condition d’avoir confiance en son hébergeur XMPP et en les hébergeurs de nos correspondants.
Par ailleurs, les clients XMPP ne lient pas l’identité à des numéros de téléphone, ce qui peut être pratique pour renforcer l’anonymat.
Enfin, XMPP étant lui‐même un protocole « push », ce qui est important pour ne pas vider la batterie, il n’est pas nécessaire d’utiliser des services annexes fournis par Google, comme le Google Cloud Messaging. Cependant, sur iOS, on est obligé d’utiliser le service push d’Apple.
Enfin, en termes d’ergonomie, notamment pour vérifier la validité des clefs de chiffrement, ces clients sont proches de Signal, WhatsApp, etc. (voir ci‐dessous).
OMEMO dans ChatSecure
Prendre en charge OMEMO d’un point de vue logiciel est important, mais il est aussi important que l’utilisateur puisse vérifier la stabilité des clefs de chiffrement. ChatSecure a donc ajouté une interface permettant de faire un contrôle visuel des clefs.
Par ailleurs, ChatSecure a adopté un comportement appelé TOFU pour « Trust On First Use » (confiance lors du premier usage). Cela consiste à demander à l’utilisateur de confirmer la légitimité d’une clef de chiffrement lors du premier contact, y compris pour chaque nouvel appareil utilisé par un correspondant.
Ce comportement peut être lourd, notamment lorsqu’on doit valider les clefs de nombreux correspondants. Certaines applications comme WhatsApp ont choisi de simplifier l’utilisation en faisant confiance sans demander une validation de l’utilisateur. Ce choix amène d’autres problèmes de sécurité.
Une solution médiane a été proposée par Daniel Gultsch : « Blind Trust Before Verification » (confiance aveugle avant vérification). Cela consiste à ne pas demander confirmation de la clef lors du premier contact, mais une fois qu’un utilisateur fait la démarche pour valider la clef, alors tout nouveau changement de clef nécessitera une confirmation. Cette technique est utilisée par Conversations, mais elle n’a pour l’instant pas été implémentée pour ChatSecure.
Autres nouveautés de ChatSecure
Cette nouvelle version a d’autres améliorations, telles qu’une file des messages sortants qui gère le chiffrement (pour renégocier automatiquement les sessions chiffrées, si nécessaire, en cas d’échec d’envoi du message).
À venir
La version 4.1 va voir arriver la prise en charge de MAM. Message Archive Management (XEP-0313) est la nouvelle extension de gestion des archives de messages côté serveur. Elle permet de synchroniser l’historique avec le serveur et d’en demander des portions de façon indépendante pour les consulter.
Le chiffrement de conversations de groupe dans des salons en utilisant OMEMO a été reporté pour la version 4.1. Cela ne fonctionnera que si tous les participants présents dans le salon utilisent des clients qui prennent en charge OMEMO.
ChatSecure en a profité pour annoncer qu’il est prévu de développer une version bureau de leur logiciel XMPP. Cependant, aucune date n’a été indiquée.
La version 4.1 intégrera également la prise en charge des chat markers (XEP-0333), qui permettent de savoir si le message a été reçu, affiché, ou lu (ce dernier état étant accompagné d’une interaction utilisateur).
Enfin, une amélioration du partage de fichiers est également prévue, avec notamment un chiffrement des fichiers envoyés via OMEMO.
Hébergements XMPP à jour conseillés
Récemment XMPP a beaucoup évolué. Par exemple, pour ne plus vider rapidement la batterie des téléphones mobiles. Maintenant, grâce à MAM il permet aussi de continuer une conversation sur un autre client ou de stocker les messages non délivrés. De nombreuses autres fonctionnalités améliorent l’ergonomie sur téléphone mobile et ordinateur de bureau.
Mais ces fonctionnalités exigent des serveurs à jour des dernières XEP. Pour se repérer, Daniel Gultsch publie un tableau qui classe les services d’hébergement selon leur conformité.
Actuellement, trois hébergeurs à jour des récentes évolutions permettent d’utiliser notre propre nom de domaine, nous permettant ainsi de ne pas être dépendant de leurs services :
- celui de JabberFR ;
- celui de Conversations.im ;
- celui de Mailbox.org.
Il est vivement conseillé de les utiliser. Le service d’hébergement avec DNS personnalisable de Conversations.im est présenté dans un journal‐tutoriel publié sur LinuxFr.org.
Pour l’auto‐hébergement, le serveur XMPP installé par Yunohost et sa configuration doivent encore s’améliorer. En particulier la prise en charge en charge de MAM est prévue pour les versions futures. Pour le serveur, le passage de Metronome à Prosody est prévu.
JabberFR cherche un développeur ou une développeuse Web
Cette dépêche a été réalisée grâce à l’aide de mathieui (ainsi que Goffi et palm123).
mathieui, avec Link Mauve, travaille au renouveau de JabberFR, en particulier son service d’hébergement XMPP. Celui‐ci a été hérité de l’APINC, qui aujourd'hui n’existe plus, et nécessite notamment une modernisation et une évolution de son interface Web. Comme cela a été annoncé lors d’une précédente dépêche, ils sont à la recherche d’un développeur ou d’une développeuse Web pour les aider.
Pour l’instant, personne ne s’est présenté. Donc, si le cœur vous en dit, n’hésitez pas à les contacter. Voici le message initialement publié :
Recherche de volontaires pour moderniser le site Web
Comme exposé plus haut, JabberFR a tout un héritage de services, notamment Web, qui lui permettent d’être une vitrine pour les fonctionnalités offertes par XMPP. Cependant, il y a des éléments dont l’âge se fait sentir, tels que le design du site Web ou des choses moins visibles comme le code derrière. Il n’est, bien sûr, pas question de devenir un site flashy réclamant du JavaScript pour tout avec des animations dans tous les sens (ce serait mal nous connaître), mais JabberFR est quand même à la recherche de volontaires pour donner un coup de fraîcheur visuelle et technologique pour son site.
Aller plus loin
- ChatSecure (301 clics)
- Annonce de la publication de ChatSecure 4 (57 clics)
- Le protocole OMEMO (87 clics)
- Code source sur GitHub (63 clics)
# Licence, et (non-)libertés
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 26 janvier 2017 à 11:23.
GPLv3+
Mais ça me titille… la GPLv3 est connue pour poser des problèmes avec les DRM (donc avec iOS), j'ai l'impression que l'upstream se garde le droit de publier sur iOS (car le seul "attaquant" potentiel est l'upstream) sans donner ce droit aux autres, est-ce qu'il y a un endroit qui dit que l'upstream n'appliquera pas une des limitations de le GPLv3 à quiconque oserait publier un fork sur iOS?
Ha… J'ai vu :
"If you would like to relicense this code to distribute it on the App Store, please contact me at chris @ chatsecure.org."
OK, libre, mais bon faut discuter (quelle discussion? financière?) pour pouvoir de faire pareil que l'upstream pour l'objectif principal du produit (faire sur iOS)…
Pourquoi ne pas donner le droit à tous de "distribute it on the App Store" afin d'éviter le problème de l'île déserte et/ou du bon vouloir de l'upstream (le libre ayant pour objectif d'éviter de dépendre de l'upstream)? Pourquoi ne pas en discuter publiquement et/ou dire "avec exception iOS"?
OK c'est libre, mais avec peu de libertés en pratique (impossible de diffuser sur la plate-forme cible, en pratique "la liberté de modifier le logiciel et de redistribuer les versions modifiées" n'existe pas).
Note : ça reste libre, ne nous méprenons pas, mais je regarde la pratique, et la pratique fait que iOS a des DRM et que donc la licence choisie ne permet pas de faire des modifications et les redistribuer sur iOS sans discussion avec l'upstream.
[^] # Re: Licence, et (non-)libertés
Posté par RyDroid . Évalué à 2.
Oui (en grande partie). https://www.fsf.org/news/2010-05-app-store-compliance
Les problèmes sont les conditions de l'Apple AppStore. Sur iOS, on peut installer une application sans lui, même si c'est clairement découragé.
Ça vient d'Apple, pas des gens de ChatSecure, même si ce n'est pas cohérent avec le fait de publier sur l'Apple AppStore.
[^] # Re: Licence, et (non-)libertés
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 27 janvier 2017 à 13:24.
Ho le côté biaisé…
Le problème vient des DEUX côtés : Apple et upstream, le deux ne voulant pas céder.
Les DEUX mettent de la mauvaise volonté, la différence est que l'un est bien plus gros que l'autre.
Une autre différence est que "bizarrement" l'upstream ne s'applique pas la même licence que ce qu'elle donne aux autres, ils se gardent des droits dont ils usent, et la désolé j'ai tendance à ne pas avoir confiance quand des gens utilisent des droits qu'ils ne donnent pas aux autres.
C'est surtout être privé de 99.999% des utilisateurs.
Tu met le point précis : Si le problème venait que d'Apple et qu'on voudrait "patcher" ce problème sans Apple, la licence serait explicite et donnerait l'exception qu'ils se donnent à eux.
Mais non, ils demandent de les contacter en privé plutôt que de donner le droit à tous. Je demande juste publiquement pourquoi, et on a eu des réponses à tous les autres commentaires mais pas celui la.
Note : Si vous voulez avoir le droit d'avoir Microsoft Windows en libre, pas de soucis veuillez contacter Microsoft, c'et une boite avec plein d'actionnaires prêts à faire un prix sur cette demande. Oui, c'est généralement ça quand on dit de contacter en privé.
Désolé, mais perso ça me pose de gros doutes sur la volonté d'ouverture de l'upstream, ça ressemble à du business proprio (ce qui est bankable, avoir des utilisateurs, est une chasse gardée ou à négocier) avec verni libre (où le libre n'est la que pour avoir des développeurs gratos sans qu'ils puissent concurrencer si jamais l'idée leur vient de ne pas être d'accord avec l'upstream). Notez aussi qu'on n'est pas dans le mode dual-licensing (qui pareil se garde des droits), ici en pratique on ne peut rien faire (en pratique) même en libre (avec MySQL, si on reste en libre on peut redistribuer).
Je propose que l'upstream soit clair sur ce sujet : l'idée est-elle de sous-licencier moyennant thune, de proposer le droit gratuit à part si trop concurrent, de sous-licensier automatiquement dès qu'on envoit un mail? Et si c'est ce dernier point, pourquoi ne pas le mettre dans la licence?
Le diable est dans les détails… Si vous comptez participer, soyez juste conscient des limites à distribuer vos versions modifiées en pratique.
PS : vu la note du commentaire au dessus, vous semblez ne pas juger l'avertissement utile. Admettons, je trouve perso rigolo de ne pas faire attention à votre liberté, du moment où il y a des "mots magiques" qui vont font plaisir, l'important est l'affichage sans doute.
[^] # Re: Licence, et (non-)libertés
Posté par groumly . Évalué à 6.
Et si tu leur posait la question directement, plutôt que d'écrire des pavés ici? C'est des ricains, ils lisent pas linuxfr, c'est aussi pertinent que de demander à ton voisin pourquoi Trump ne veut pas publier ses feuilles d'impôts.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Licence, et (non-)libertés
Posté par RyDroid . Évalué à 1.
Si je tiens à ma liberté, c'est pourquoi je n'utilise pas iOS. http://www.nicola-spanti.info/fr/documents/articles/computing/mine/you-should-not-buy-or-use-an-idevice.html
[^] # Re: Licence, et (non-)libertés
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
D'ailleurs, je ne comprends pas pourquoi les équipements tournant sous Apple iOS sont encore autorisés à la vente dans l'union Européennes en 2017. Il est plus que temps de réglementer cela avant que cette pratique (impossibilité de spécifier un 'magasin' alternatif) ne se répandent sur tous les OS.
# ortho
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
bonjour,
est-ce qu'un modo peut corriger:
On peut noter que ni Gajim, ni Conversations, ni ChatSecure n'utilise ==> On peut noter que ni Gajim, ni Conversations, ni ChatSecure n'utilise*nt*
merci :)
[^] # Re: ortho
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
[^] # Re: ortho
Posté par Apichat (site web personnel) . Évalué à 2.
Merci, est-ce possible de modifier aussi ce titre :
Avantages d'OMEMO et XMPP par rapport autres logicielsAvantages d'OMEMO et XMPP par rapport aux autres logiciels
[^] # Re: ortho
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# partage d'images
Posté par tuxicoman (site web personnel) . Évalué à 5.
Si l'envoi de texte fonctionne assez bien entre logiciels xmpp, c'est une autre histoire pour le partage de fichiers multimédia.
Est ce que gajim, conversations, chatsecure peuvent s'envoyer des photos?
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
ça dépend de ce que tu entends par là.
Le téléversement de photos fonctionne avec Gajim, Conversation (je ne sais pas pour ChatSecure) et avec une bonne partie des clients activement développés. Le problème est que sauf si tu maîtrises ton propre serveur (ou si tu fais confiance aux admins), tu ne sais pas qui peut voir ces photos, combien de temps c'est stocké, et tu ne peux pas les supprimer (ce qui est – me semble-t-il – le cas sur la plupart des plateforme de messagerie, XMPP ou pas, si vous avez des contre-exemples je veux bien des infos).
L'envoi en pair à pair est disponible au moins sur Gajim, je pense que Conversations implémente Jingle et ChatSecure je ne sais pas. Gajim malheureusement utilise une ancienne version du protocole.
Plus d'infos sur l'envoi en pair à pair dans les épisode 9 et épisode 10 de parlons XMPP.
Pour le chiffrement des fichiers en pair à pair, je crois que Conversations utilise une méthode non standard avec OMEMO (proposée à la standardisation mais pas retenue), et il n'y a pas encore de méthode standard (il y a une méthode utilisant TLS qui devrait avoir un numéro officiel mais qui semble perdue).
Enfin pour l'envoi avancé (sous forme d'album), il y a des extensions permettant un début d'implémentation, mais rien de concret à ma connaissance. Ça devrait être un de nos chevaux de bataille pour 2017 avec SàT.
[^] # Re: partage d'images
Posté par Le Gab . Évalué à 2.
Pour l'échange de fichier:
Je dirais pour les images/sons/video de
Conversation -> Conversation (en clair et OMEMO, 1@1 ou multi: OK)
Gajim -> Conversation (non)
Conversation -> Gajim, pour ce dernier, en clair et OMEMO, toutefois le fichier est illisible sur Gajim.
Une alternative est l'utilisation d'un server HTTP proxy (inclu dans le server XMPP, dans mon cas ejabberd) ou "inline" (pour les petits fichiers), mais les fichiers passent en clair, je force l'URL en HTTPS mais je pense que côté client il ne gère pas les cert auto-signés et ne propose pas d'ignorer l'erreur
.
Alors dés fois, Gajim/Conversation interprêtent l'URL et te présentent directement l'aperçu de l'image donnant cette impression de transparence dans le transfert de fichier et dés fois, non. Sans doute après trop de triturage de ma part car j'essayais de corriger un autre problème avec MAM.
On va dire que le client Android Conversation offre la meilleure expérience XMPP quasi proche de l'equivalent IM proprio tant qu'on reste sur Android.
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
t'es en train de dire que Conversations est capable d'envoyer un message chiffré à plusieurs personnes en même temps ? T'es certain de ce que tu dis ?
Parce qu'à l'heure actuelle, tu peux utiliser Jingle (avec l'utilisation d'OMEMO – ce qui n'est pas standard pour le moment – comme je l'ai expliqué plus bas), mais ça n'est possible qu'entre 2 contacts, ou HTTP upload qui stocke le fichier en clair sur le service (mais la transmission est chiffrée via HTTPS), et il n'y pas (encore) de méthode (standard du moins) pour chiffrer le fichier.
Du coup je suis très étonné par ce que tu dis, est-ce que j'ai mal compris ou est-ce que tu dis bien qu'il est possible de chiffrer un fichier pour plusieurs destinataires en même temps ? Si oui ça marche pour gros et petits ? Tu fais comment (je testerai pour être sûr) ?
Gajim gère HTTP upload donc il est possible de partager un fichier, mais je veux bien que ça ne fonctionne pas avec Jingle vu que Gajim utilise une version obsolète (et conversation ne gère probablement pas Stream Initiation, ce qui n'est pas plus mal).
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Apparemment il utiliserait une méthode de chiffrement avec clef dans l'URL, le problème est que ça n'est pas standard et ça demande un HTTP upload spécifique, ça ne marchera donc pas avec n'importe quel serveur.
[^] # Re: partage d'images
Posté par Apichat (site web personnel) . Évalué à 1. Dernière modification le 27 janvier 2017 à 14:47.
En allant voir sur le site de Conversations et celui d'OMEMO il semble bien que le transfère de fichiers soit pris en charge, y compris en conférences (après j'ai pas testé dans tous les sens) :
voir aussi : https://github.com/siacs/HttpUploadComponent
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
le transfert de fichier est possible via Jingle, mais pas avec plusieurs destinataires en même temps.
C'est HTTP upload qui est utilisé dans ce cas (avec apparemment un chiffrement spécifique à Conversations dans certains cas).
Ce tableau est d'ailleurs incorrect, puisqu'il n'y a pas de méthode de transfert de fichier standard à l'heure actuelle avec OMEMO (il est plus ou moins au même point que OX de ce côté, avec une protoXEP en plus mais non officielle).
[^] # Re: partage d'images
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
bon je rectifie, j'avais mal compris. Le fichier est envoyé normalement sur le HTTP upload, mais la clef de déchiffrement est mise dans la partie « fragment » (après le « # ») de l'URL. Du coup pas besoin d'un HTTP upload spécifique, et les clients qui gèrent ça vont avoir le fichier, pour les autres il sera illisible.
[^] # Re: partage d'images
Posté par Le Gab . Évalué à 1.
Oui en mode MUC, les messages passent mais je ne suis plus certains pour le transfert de fichier.
J'ai stoppé mon server jabber depuis quelques semaines car MAM ne rendait dingue.
Le gros soucis qui reste, c'est l'usage multi-client, si tu as plusieurs sessions tu ne sais jamais quand que ton message est repliqué à toutes tes sessions ouvertes.
# Olm vs libsignal
Posté par Maclag . Évalué à 2.
Il y a une raison particulière pour que tous ces clients utilisent autre chose que le standard?
Surtout que si je comprends bien, il y a déjà des projets qui implémentent chacun d'eux:
Signal pour libsignal
Matrix pour olm
Donc ça doit pas être tellement une question de maturité, si?
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 26 janvier 2017 à 16:54.
OMEMO a été basé historiquement sur libsignal, et la première proposition de XEP a été faite avec.
Cette proposition a été rejetée parce que :
De leur côté, les gens de Matrix ont développé Olm, standardisé et sans les problèmes mentionnés, il a donc été retenu pour une nouvelle proposition de OMEMO, cette fois acceptée.
Un exemple où Matrix et XMPP peuvent collaborer, une relation un peu plus seine que ce qu'on a vu l'année dernière.
Seulement il y a un « standard » de fait avec la première version de OMEMO (pas celle de la XEP donc), car c'est celle utilisée par Conversations et tout le monde veut être compatible avec.
De son côté, Conversations est bloqué pour passer à Olm parce qu'il n'y a pas encore de bibliothèque Java.
Les nouvelles implémentations partent actuellement toutes sur la version brouillon à cause de ce standard de fait, mais il ne devrait pas être difficile de passer d'une version à l'autre une fois que tout le reste est en place (interface utilisateur, gestion des messages chiffrés, autre XEPs nécessaires à l'utilisation, etc). Il est aussi tout à fait possible de fournir les 2 versions en même temps, mais aucun client ne le fait à l'heure actuelle.
Autre changement, une documentation de Double Ratchet a été mise dans le domaine public entre temps, donc il est possible de repasser à une implémentation basée dessus. J'ai suivi cette partie de loin, mais je sais qu'il est question d'en discuter au XMPP summit qui aura lieu ce week-end.
Tout ça va rapidement se stabiliser, il y a une petite excitation sur le sujet en ce moment , mais d'ici quelques mois ça devrait être stable.
[^] # Re: Olm vs libsignal
Posté par Maclag . Évalué à 2.
Merci, c'est clair!
On arrive hors sujet, mais là par contre, t'en as dit trop ou pas assez!
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
J'ai fait une belle faute surtout (saine) :)
Il y a eu une petite tension entre Matrix et la communauté XMPP l'année dernière (et un peu l'année d'avant), parce que pour se faire connaître ils se sont mis sur un angle d'attaque très agressif envers XMPP, que ce soit dans les interventions (par exemple au FOSDEM il y a 2 ans, là où j'ai entendu parler d'eux la première fois d'ailleurs) ou par écrit.
Le problème n'est pas tant la critique en soit, c'est aussi qu'ils ont propagé un certains nombre de fausses vérités, notamment sur leur FAQ (qui n'est d'ailleurs toujours pas terrible même si c'est mieux) au point que la communauté a dû répondre, par exemple avec cette page (ainsi que des réponses sur différents réseaux).
À ça s'ajoute des gens (a priori des groupies, même si on ne sait pas trop si c'est des gens impliqués dans le projet ou pas) qui font de la propagande systématiquement pour Matrix dès qu'un article un peu visible parle de XMPP (en particulier sur hackernews ou reddit, mais on a vu des remarques désagréables même ici). Là encore pas vraiment un problème de parler d'un projet, mais quand c'est sous pour insinuer que XMPP est dépassé (ce qui est faux) et que l'herbe est plus verte chez eux, forcément à force c'est fatiguant.
Enfin bref, maintenant que Matrix est plus connu ça s'est un peu calmé, et c'est préférable de voir qu'il est possible de collaborer.
[^] # Re: Olm vs libsignal
Posté par Maclag . Évalué à 6.
Je t'avoue que je n'y connais rien en protocole. Enfin si, on va dire que j'y connais un tout petit peu ce que tu as écrit dans la série XMPP, mais ça ne fait pas de moi un expert qualifié pour avoir un avis sur un protocole plutôt que l'autre.
Par contre, je trouve regrettable de constater ça:
-Riot, client Matrix multiplateforme (bon, ok, c'est une webapp, je suis pas naïf), peut faire messagerie, groupe, appels audios et vidéos y compris sur mobile. Je ne sais pas où en est le chiffrage bout-à-bout mais je crois comprendre que c'est bien avancé.
-Aucun client XMPP mobile actuellement maintenu n'est capable de faire audio et vidéo!
Jitsi sur Android n'est plus développé. L'équipe de Conversations ne semble même pas intéressée par l'audio et la vidéo. La prochaine version de Movim devrait être capable de faire ça, mais si tu veux le chiffrage bout-à-bout il faudra jongler avec autre chose.
Je ne dirai encore rien sur Cagou, parce qu'il est trop jeune pour tout demander.
Du coup, je me demande toujours et encore:
Comment Matrix/Riot a pu arriver à un ensemble "complet" avec serveur et client pour la messagerie, les salons, l'audio et la vidéo qui marche sur web, PC et mobile aussi rapidement alors que XMPP existe depuis tellement plus longtemps et… on attend encore et toujours un équivalent?
Qu'est-ce qui ne va pas dans le monde XMPP Libre et qui a si bien marché pour Matrix/Riot? Ils ont eu plus de moyens? Ils attirent plus de volontaires? Ils lèvent des fonds?
Comme je l'écrivais dans un autre journal: Whatsapp est une appli complète initialement basée sur XMPP (je ne sais pas à quel point ils ont modifié leur protocole ensuite). Alors il est clair pour moi que le problème n'est pas le protocole lui-même. Ou sans grosse modif nécessaire.
C'est juste rageant de voir qu'un acteur propriétaire a utilisé XMPP, et raflé autant de marché au nez et à la barbe de tous les projets Libres.
Whatsapp aurait dû être un client XMPP Libre!
[^] # Re: Olm vs libsignal
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
La question est très bonne, et vu de l'extérieur ça peut sembler surprenant, mais en y regardant de plus près ça n'est pas très difficile à comprendre.
Il y a déjà – et surtout – un budget bien plus important pour Matrix, et des développeurs (je ne sais pas combien, mais à vu de nez quelques uns) qui y travaillent à plein temps. C'est une très grosse boîte derrière Matrix (Amdocs). En comparaison, la plupart des clients se font sur le temps libre : Gajim c'est principalement une personne qui a peu de temps libre, Movim c'est principalement 1 seule personne aussi, pour SàT on a été temporairement 2 à plein temps (donc une grosse partie a été utilisée pour participer à des événement), mais c'est actuellement 1 seule personne sur son temps libre (moi), et on peut dire la même chose de la plupart des projets actifs (si ce n'est tous pour les clients libres, pour les serveurs c'est un peu différent).
Conversations fait figure d'exception avec 1 (seule !) personne qui arrive à être à plein temps dessus, et ça se sent dans le soin apporté dans les détails et la com', et qui contribue à son succès.
D'autre part il y a un choix du tout web en effet, et les technologies ont énormément évolué ces dernières années. La vidéo-conférence était un défi technique à la naissance de Jingle, aujourd'hui WebRTC gère toute la complexité. Je me souviens à la conf Matrix que j'avais vu au Fosdem des applaudissement nourris pour la vidéo alors que ce n'est qu'une mise en place de WebRTC, il y a aujourd'hui des très petits projets qui arrivent à faire de même.
Il faut bien se rendre compte de la complexité d'une vidéo-conférence, ce n'est pas juste envoyer un flux à un participant, il faut gérer les débits variables, annuler l'écho, gérer les codecs, adapter la transmission aux conditions, etc. Tout ceci est devenu presque trivial en web grâce aux développements de Google ou Mozilla.
Par contre sur bureau c'est toujours très compliqué, donc ça explique les difficultés des clients non web (pour notre part on met ça de côté pour le moment par exemple). Des clients s'appuyant sur des outils avancés comme Gajim avec Gstreamer, ou dont c'est une fonctionnalité principale comme Jitsi s'en sortent mais ça reste un boulot bien plus important que sur le web.
Pourquoi ne pas faire pareil pour les clients XMPP webs ? Et bien ils le font justement, Movim gère la vidéo dans le version de dév, Jappix (qui n'est plus maintenu) le faisait également, et probablement d'autres. Quand nous nous y intéresserons dans SàT, il est fort probablement que nous implémenterons en premier dans Libervia (frontal web) avec WebRTC.
Ce que j'affirme est tout de même à prendre avec des pincettes : je n'ai pas encore travaillé moi même sur la visio-conférence, aussi mon ressenti n'est peut-être pas juste.
Même en dehors de la vidéo, il y a beaucoup de problèmes qui sont plus simples aujourd'hui à gérer parce qu'il y a plus d'outils et bibliothèques disponibles, parce qu'on a plus d'outil de messageries existants dont on peut s'inspirer.
Ensuite les objectifs peuvent être différents. Pour Whatsapp le but principal évident était (et est toujours) de monétiser. Pour Matrix, je pense que c'est assez clairement le but aussi à moyen ou long terme. Ces choix font mettre les moyens et les priorités dans l'esthétique, les fonctionnalités populaires et le marketing, et on se retrouve avec X applications qui font peu ou prou la même chose et se ressemblent fortement, et qui plaisent parce que les gens s'y retrouvent.
Selon les projets, les objectifs peuvent être très différents (j'allais élaborer un peu là dessus, mais je manque de temps donc je vais finir ce message sur cette remarque).
# Chiffrement de conversations
Posté par RyDroid . Évalué à 1.
Ça pourrait être mal compris. De ce que je comprends de XMPP (mais je me trompe peut être), il peut y avoir du chiffrement pour les conversations de groupe, via TLS donc de point-à-point et pas de bout-en-bout comme OMEMO, ce qui est bien moins grave que pas de chiffrement.
[^] # Re: Chiffrement de conversations
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Le chiffrement de point à point (
client <==> serveur <==> MUC (conversations de groupes) <==> autres serveurs <==> autres clients) est effectivement obligatoire dans XMPP depuis plusieurs années. Le chiffrement de bout en bout est principalement utile si tu n'as pas confiance en l'un des entités entre toi et ton/tes contact(s) (donc ton serveur, le service MUC, et un des serveurs de tes correspondants).Dans le cas par exemple ou tu communiques avec un ou des proches sur le serveur que tu gères toi même (avec le service MUC très probablement sur la même machine), le chiffrement de bout en bout n'est pas utile.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.