paulez a écrit 387 commentaires

Parce que justement dans le cas de XMPP c’est impossible d’imposer un client, parce déjà il n’y a pas un seul client multi-plateforme.
Donc tu dois dire à tes utilisateurs:
* Sous Windows Gajim (pour lequel il faut explicitement ajouter un plugin pour activer OMEMO, résultat personne ne le fait)
* Sous Android Conversations
* Sous iOS ChatSecure, Siskin.im?
* Avec un navigateur web, ???

De plus au fil du temps ça change, tel ou tel client n’est plus maintenu sur telle ou telle plate-forme. Donc on se retrouve avec des utilisateurs qui utilisent de plus en plus de clients différents.

Par exemple j’avais installé Jappix qui fonctionne très bien, mes utilisateurs l’utilisent et apprécient. Mais le projet n’est plus maintenu donc ne supporte pas OMEMO, MAM et toutes les nouvelles extensions XMPP.
Je fais quoi, je garde un truc qui marche, ou je fais migrer tout le monde vers un truc qui si ça se trouve aura le même problème dans 2 ans ?

Je comprends le choix de Signal d’imposer un seul client. C’est impossible de garantir un niveau de sécurité équivalent avec une multitudes de clients.

C’est sympa tous les arguments théoriques, et oui OMEMO est une belle avancée, mais ça ferait du bien d’être un peu réaliste et d’accepter les limitations de XMPP pour mieux faire avancer le schmilblick.

J’utilise au quotidien XMPP avec des proches, et la situation est la suivante:

• Je n’ai pas de client web qui supporte OMEMO, donc quand je veux utiliser un client web (au boulot par exemple qui bloque XMPP) mes communications sont en clair.
• Utiliser OMEMO dans un groupe de discussion est compliqué, donc au final aucune discussion de groupe n’utilise OMEMO dans notre cas.

J’utilise et je pousse pour utiliser XMPP avec mes proches. Je constate que même dans ce cas la confidentialité est moins bonne qu’avec Signal ou Whatsapp, aka je pourrais espionner pas mal de discussions passant sur ce serveur.

Au final ça marche parce que mes utilisateurs me font confiance. C’est pour ça que je pose la question décentralisation/confidentialité.

XMPP ça marche pour nous grâce à la décentralisation et la confiance qu’ont mes utilisateurs que je ne vais pas abuser les données que je pourrais récolter. Mais dès qu’on élargit le cercle cette confiance n’existe plus.

Les Flame Graphs sont vraiment super puissants, il y a pas mal d’exemples ici: http://www.brendangregg.com/flamegraphs.html

Je ne connaissais pas Hotspot, merci pour la découverte. Super article !

Seulement l’admin du serveur peut le vérifier (encore faut-il être suffisamment compétent pour ne pas se faire véroler son serveur), pas les utilisateurs.

Même dans un monde «idéal» où chacun ne fait confiance à personne et héberge son propre serveur, tu dois passer par un autre serveur pour communiquer avec quelqu’un qui utilise un serveur différent. Et tu n’as aucun moyen de vérifier le code utilisé par ce serveur.

C’est pour ça que le seul moyen de garantir la confidentialité est d’utiliser un protocole qui la garantisse, plutôt que de devoir faire confiance au serveur, comme le font Signal et Whatsapp.

Dans le monde XMPP il y a l’extension OMEMO qui fait ça, mais qui n’est supportée que par un nombre réduit de clients. Résultat, la plupart des utilisateurs ne vont pas l’utiliser.

Par exemple un module pour loguer les messages d’un serveur Prosody: https://modules.prosody.im/mod_message_logging.html

• une conséquence de tout ceci : impossibilité de vérifier que le code source serveur publié est bien celui qui tourne sur les serveurs de Signal.

C'est tout autant impossible avec XMPP, et avec à peu près n'importe quel logiciel avec lequel tu interagis au travers du réseau.

C'est une question de choix : au niveau confidentialité et sécurité XMPP est largement moins bon que Signal et Whatsapp. Question décentralisation, c'est l'inverse.

Qu'est-ce que qui est le plus important, la sécurité et la confidentialité, ou la décentralisation ?

Marrant de voir comment « Des regions ENT affectées et des applications indisponibles ne sont pas hébergées chez Ovhcloud » est transformé en « les régions affectées ne sont pas hébergées chez Ovhcloud ».

Les causes sont multiples, les acteurs se tirent dans les pattes, et les médias renforcent la confusion.

Bravo à tous les niveaux !

Parce que c'est beaucoup de boulot de maintenir Firefox non ESR. Il y a des mises à jour très régulièrement, qui requièrent un compilateur et Rust à jour. Donc souvent il faut mettre à jour LLVM, Clang, et Rust, donc pas forcément possible pour une distribution stabilisée.

Il y a beaucoup de pays où les FAIs ne sont plus neutres (blocage d'IP, DNS menteurs), voir d'autres où le trafic est analysé voire restreint (et pas qu'en Chine).
Peut-être que nous en France ne voyons pas trop l'intérêt mais ça sert à d'autres.
J'utilise un VPN principalement pour éviter les restrictions liées à la localisation de l'IP, pour ça j'ai choisi un fournisseur qui supporte Wireguard, qui est censé être plus léger qu'OpenVPN.

En effet le paquet à installer sous Mint semble être android-tools-adb.

Concernant le rootage je n'ai pas de conseil, j'ai seulement fait ça sur des téléphones faciles à rooter (Nexus 5X).

Un paquet de transition est un paquet qui va potentiellement être renommé ou découpé en plusieurs paquets.
Tu n'as pas vraiment à t'en inquiéter, apt install adb devrait installer l'outil adb comme attendu.

C'est tout à fait possible que le site utilise quelque chose de plus avancé pour détecter le navigateur.
Tu pourrais essayer de lancer Edge dans une machine virtuelle Windows. Après généralement arrivé à ce niveau d'emmerde je change de fournisseur de contenu :D

Essaie de changer le User-Agent envoyé par ton navigateur. En gros ça permet de prétendre que ton navigateur est Edge sous Windows (avec le user agent idoine) pour tromper le site.
Winedevine est une solution DRM utilisée pour protéger les contenus vidéos. Apparemment ce site prétend qu'il y a une faille dans l'implémentation Winedevine fournie par Chrome et Firefox (je ne sais pas c'est vrai) et bloque les navigateurs autres que spécifiés.

Il ne faut pas croire que Rust va résoudre tous les problèmes de sécurité par magie. Certainement ça permet de réduire une certaine classe d'erreurs, mais refaire X11 en Rust par exemple n'apporterait pas grand chose niveau sécu.

Clairement les systèmes Linux peuvent beaucoup améliorer leur niveau de sécurité.

Mais certains points de l'article me paraissent discutables:

• Désactivation de Secure Boot: plusieurs distros permettent d'utiliser Secure Boot, telles que Fedora, Debian, etc. Même si Secure Boot peut théoriquement être contournée à cause d'une faille récente dans Grub.
• X11 est un trou de sécurité: certainement, et c'est pour ça que Wayland existe, et qu'il est activé par défaut sous Fedora.
• CVE non corrigée sous Debian pour Chromium: je ne pense pas que ça soit un exemple représentatif de la réactivité de Debian pour corriger des CVE. Chromium est un cas particulier car sa maintenance est difficile, d'ailleurs le wiki Debian recommande de ne pas l'utiliser pour cette raison. Debian est probablement une des distributions non rolling release les plus rapides et productives pour corriger des CVE.
• Sandboxing Flatpak inutile: en quoi est-il inutile ? Intéressant pour un article qui prétend se baser sur des faits de balancer une affirmation sans arguments.
• Utilisation de langages non memory safe: je sais qu'il y a une certaine hype autour de Rust (à bon escient) mais tous les OS couramment répandus sont aussi écrits C à ma connaissance.

Globalement c'est vrai qu'aujourd'hui que pas mal de distros Linux n'ont pas vraiment d'avantage technologique majeur au niveau sécurité sur Windows ou MacOS. Certaines distros sont plus "durcies" que d'autre par défaut (Fedora avec SELinux par exemple).
Ces trois systèmes ont régulièrement des failles plus ou moins majeures qui sont découvertes et publiées.
Mais justement Linux est devenu tellement important au niveau infra que beaucoup d'acteurs s'impliquent pour améliorer la situation à ce niveau, ce qui est rendu possible par le modèle ouvert de Linux.
Je ne pense pas que ni Windows ni MacOS aient autant de personnes impliquées dans l'exploration et la correction de problèmes de sécurité que Linux.
Mais clairement utiliser Linux n'est pas suffisant au niveau sécurité, il faut avoir toute une politique autour pour l'utiliser de manière sûre.

Si c'est au travail, tu passes peut-être par le proxy de ta boîte qui génère suffisamment de trafic depuis une seule adresse pour être identifié comme suspect. Contacte l'admin réseau s'il y en a.

Qu'est-ce qui t'empêche de le faire tourner ? Tu peux installer ton propre serveur Signal, il faudra ensuite modifier le client pour qu'il s'y connecte.

J'ai aussi écrit un logiciel assez simpliste de messagerie en AGPL, il ne supporte pas la fédération parce que je n'en ai pas besoin, que c'est compliqué, etc. mais il reste libre pour autant.

Si un jour Signal disparaît ou adopte un comportement qui n'inspire plus confiance, quelqu'un peut récupérer le code et faire un service équivalent. Ça n'est pas du tout le cas de Whatsapp et consorts.

Il y a plein de raisons de préférer des solutions décentralisées, comme tu l'as exposé.
Mais comme tu l'as aussi dit, ça vient avec pas mal d'inconvénients qu'on n'a jamais réussi à résoudre.
Tu parles de confiance, et justement, l'expérience montre que les utilisateurs vont utiliser des solutions dans lesquelles ils ont confiance.

Les gens utilisent Whatsapp, parce qu'ils ont confiance que ça marche, qu'il n'y a pas de problème majeur de sécurité, parce que leurs proches l'utilisent aussi, que ça a des étoiles sur le Google store et qu'en sais-je. Quand la confiance est perdue comme récemment, ils se tournent vers d'autres acteurs comme Signal.
Avec XMPP et Matrix, il y a plein de petits acteurs vers qui se tourner. À qui faire confiance ? Au final aucun acteur n'est vraiment connu (à part peut-être Framasoft qui a un succès certain) et les utilisateurs préfèrent se tourner vers une entité en qui ils ont confiance.
Je propose un service XMPP et les seuls qui me font assez confiance pour l'utiliser sont ma famille proche. Comme quoi la confiance est une énorme difficulté pour toute solution décentralisée.

Quant à dire qu'un Signal non libre est la même chose qu'un Signal libre, au final le logiciel libre n'a donc aucun intérêt ?

Pour moi, l'arrivée de Matrix a surtout permis de renforcer les GAFAM.

Je ne pense pas. On le voit bien avec le succès de Signal en ce moment que des solutions libres peuvent remporter un peu d'adhésion chez le public.

Par contre aucune solution décentralisée n'a eu du succès chez le public. Je me suis rendu à l'évidence: les solutions décentralisée n'intéressent que très peu de monde. En ce focalisant sur la décentralisation, on a laissé libre cours aux solutions proprio et fermées des GAFAM. Signal montre qu'une solution libre mais centralisée peut avoir du succès, mais est arrivé trop tard.

Pour moi c'est l'obsession de la décentralisation qui a laissé libre cours aux GAFAM.

Javascript est partout, HTTP est partout, XMPP est nul part ou presque. Je le sais bien ça fait 15 que je gère un serveur XMPP, j'ai essayé de convaincre mes amis et famille de l'utiliser pendant bien longtemps.
Le coût de repartir de zéro est énorme quand tout le monde utilise un protocole ou une techno. Quand elle n'est pas utilisée, il est quasi nul, vu qu'il n'y a personne à migrer.
Je comprends tout à fait le point de vue de Matrix, justement c'est bien qu'il y ait une autre tentative de techno de messagerie instantanée ouverte car au final il n'y avait que XMPP avant, et c'est un échec.

Désavantage parce qu'il faut gérer tout un tas de legacy. Il y a une armée de clients XMPP non maintenus, et qui potentiellement ne supportent pas la nouvelle méthode d'authentification. Il faut donc faire le choix de les supporter, ou d'expliquer aux utilisateurs pourquoi ça ne marche pas quand ils choisissent d'utiliser tel ou tel client non supporté.
Avec un protocole plus jeune on évite ce genre de problème, la base commune est plus récente.
Bien sûr il y aussi des avantages, comme une plus grosse maturité par exemple. Même si justement je trouve ça discutable, vu que XMPP est basé sur pas mal de choix de son époque (XML par exemple) qu'il est difficile de changer. Un protocole plus récent peut avoir plus de maturité dans sa conception en se basant sur les erreurs de l'époque de XMPP.

Tout ça est bien manuel, il faut gérer sa blocklist à la main, contacter les serveurs qui envoient du spam, etc. Je suppose donc que la plupart des serveurs n'ont pas le moyen de maintenir tout ça, et sont donc ouverts aux spammeurs.
J'avais ouvert les inscriptions à mon serveur il y a longtemps, et le spam était une plaie ingérable. Bon courage aux admins de serveurs publics !
Dans le monde du mail, il y a énormément de services qui permettent de filtrer la plupart du spam, les outils sont bien plus performants.

De plus, alors que les utilisateurs acceptent de recevoir de temps à autre du spam dans leur boîte mail, sur de la messagerie instantanée pas du tout. Il n'y a pas de spam sur Whatsapp and co, alors pourquoi accepter d'utiliser un service sur lequel on reçoit du spam ?

Oui il y a l'équivalent de allow et block lists. J'ai essayé au début d'utiliser une block list, mais les spammeurs utilisent suffisamment de serveurs différents pour que ça ne résolve pas le problème.
Si j'utilise une allow list, qu'est-ce que je mets dedans ? Ça revient presque à désactiver la fédération.

Mon gros problème avec la fédération, c'est le niveau de spam.

Je fais tourner un serveur Prosody pour ma famille, et j'ai du désactiver la fédération pour que ça soit utilisable.

Difficile de vendre la solution à sa famille quand les utilisateurs reçoivent régulièrement des messages de spammeurs russes vendant des pilules magiques.

Il y a des solutions efficaces contre ça ?

Je me rappelle avoir eu cette discussion il y a 15 ans, et à l'époque il n'y avait pas de bonne réponse, il fallait stocker le mot de passe pour faire tourner un serveur XMPP.

Le wiki de Prosody a une bonne explication. Pour résumer, XMPP ne supporte qu'une méthode d'authentification ne nécessitant pas de stocker le mot de passe côté serveur seulement depuis 2010. Si un serveur veut être compatible avec les clients n'implémentant pas cette méthode, il doit stocker le mot de passe.

Comme quoi utiliser des protocoles qui ont 20 ans ou plus a de sérieux désavantages (je pense à XMPP, mais aussi SMTP et compagnie).

Je déteste passer des heures à bidouiller la configuration de mon éditeur pour avoir quelque chose d'utilisable. J'ai arrêté Vim car c'était vraiment trop de perte de temps pour arriver à le configurer pour avoir quelques fonctions d'IDE.
J'ai ensuite utilisé Visual Studio Code qui est super agréable à utiliser, mais j'ai trouvé un peu dommage d'utiliser un produit Microsoft pour programmer.
J'ai commencé à configurer moi-même Emacs avec un résultat à peu près utilisable après quelque temps. Spacemacs m'a permis de faire un bond significatif en confort et efficacité d'utilisation.
Chacun ses préférences bien sûr ! Je trouve dommage qu'il n'y ait pas de bonne alternative d'éditeur "clé en main" à Visual Studio Code.