Hier soir, j'ai fait mes premiers pas sur OTR (chiffrement de bout en bout (le chiffrement commence sur la machine du premier interlocuteur et termine sur la machine du second interlocuteur, quel que soit le nombre de serveurs traversés par la communication pour relier les deux interlocuteurs) des messageries instantanées (XMPP, IRC,...)) suite à l'insistance d'un nouveau contact (nouveau sur XMPP, connu depuis plusieurs années sur d'autres canaux). Depuis le temps que c'était dans ma TODO, ça ne pouvait pas me faire de mal de m'y mettre, pensais-je...
J'utilise Gajim comme client XMPP. Gajim m'indique que mon interlocuteur veut faire de l'OTR mais qu'il me faut un plugin pour ça. Soit, je vais dans le menu Édition -> Plugins -> Available (on notera l'absence de traduction...), je coche Off-the-Record Encryption et je clique sur le bouton « Upgrade » à moitié masqué derrière la liste des plugins disponibles (la qualité de conception habituelle de Gajim, normal quoi).
Je teste avec un premier contact : je clique sur le bouclier OTR apparu dans la fenêtre de notre conversation. Vu qu'on a déjà signé nos clés OpenPGP, je lui envoie un mail chiffré+signé (chiffré pour que personne d'autre ne soit au courant, signé pour qu'il puisse être sûr que ça vient bien de moi) avec un secret partagé (une chaîne de 40 caractères minuscules+majuscules+chiffres+autres générée aléatoirement). Je décoche la case « use question? » puisqu'il sait déjà ce que je vais lui demander. On saisit chacun le secret partagé et... ça juste fonctionne. Jusque-là, je suis émerveillé. :O
Je teste avec un deuxième contact. On n'a jamais signé nos clés OpenPGP donc il va falloir trouver un autre moyen de s'authentifier mutuellement. Mon interlocuteur a dégainé avant moi et le plugin OTR me propose de répondre à sa question : quel est le contenu d'un fichier sur un serveur sur lequel nous sommes tous les deux adminsys. Ho, excellente idée, c'est de là que je le connais en plus donc ça tombe bien puisque ce que je cherche à savoir en réalité, c'est si ce mec sur XMPP est bien le copain adminsys que je connais ! Je vais chercher la réponse (on notera que cette phase dépend de ma configuration SSH pour les algos de chiffrement utilisés et sur une bonne vérification antérieure de l'empreinte de la clé du serveur) et je réponds à la question dans le plugin OTR.
Cette fois-ci, surprise : lui me voit comme un contact authentifié mais pas moi... Je dois lui poser une question... C'quoi l'embrouille ?! Sur l'instant je suis perdu et c'est *très mauvais* signe en crypto : si vous ne comprenez pas ce que vous êtes en train de faire, la crypto est totalement inutile, vous êtes foutu, de base ! Je réfléchis avec le premier contact qui a déjà touché de l'OTR. On ne comprend pas : nous avons réussi à utiliser un secret partagé tous les deux mais là, ça semble être le mode question/réponse... Je mets en cause la qualité des implémentations mais... on utilise tous les trois Gajim @ Debian...
En fait, le problème, c'est l'ergonomie du plugin OTR de Gajim : si tu coches « use question? », tu utilises le mode « question/réponse » d'OTR donc chaque interlocuteur doit répondre à une question de l'autre. Si tu décoches cette case, tu passes au mode « secret partagé » d'OTR. Vas-y pour comprendre ça quand t'es pas initié... Je maintiens : l'interface du plugin OTR de Gajim est naze. On est au niveau de l'ergonomie d'Enigmail (extension de chiffrement des mails avec OpenPGP pour Thunderbird). Ce n'est pas possible.
Mes premières conversations OTR établies, je me dis que je vais creuser un peu plus les options de ce plugin OTR. Déjà, dans la description du plugin, je lis « Read
https://github.com/python-otr/gajim-otr/wiki before use. ». Oki, allons lire. Et là, c'est le drame : « What's the status of python-otr and gajim-otr on GitHub or the gajim-plugin repository? *It's dead.* [...] However, I do not recommend using this software, as *it's completely unaudited and written by non-cryptographers. I would not be surprised if it provides absolutely no security in any sense.* ». Oki donc je croyais être plus en sécurité mais c'est peine perdue, je n'ai rien gagné... Encourageant, n'est-ce pas ?
Je ne baisse pas les bras, peut-être y'a-t-il un autre plugin OTR pour Gajim non référencé dans le dépôt officiel des plugins ? Une rapide recherche sur le web ne met rien en évidence. Je voulais juste faire du chiffrement de bout en bout qui fonctionne out-of-box sans prise de tête, pas me retrouver à changer de client XMPP car cette réponse est inacceptable pour un non-initié ("je ne vais pas apprendre un nouveau logiciel, voyons !") à juste titre !
Je décide d'en apprendre un peu plus sur OTR et je lis la page Wikipedia qui lui est consacrée et là, c'est encore plus le drame : « OTR uses a combination of AES symmetric-key algorithm with 128 bits key length, the Diffie–Hellman key exchange with 1536 bits group size, and the SHA-1 hash function. ». Je lis les spécifications (
https://xmpp.org/extensions/xep-0364.html et
https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html, la version 3 n'apporte aucun changement à ce niveau là) et oui, l'intégrité et l'authenticité du message reposent bien sur SHA-1... En 2016 (
https://sites.google.com/site/itstheshappening/) ! Oui, SHA-1 n'est pas encore troué mais en crypto, il faut toujours voir plus loin, avoir de l'avance. On est donc plutôt mal parti avec OTR.
Aeris me pointe cette actualité
https://linuxfr.org/news/xmpp-a-fond#chiffrement . Et là, j'ai envie de me trancher les veines :
« 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.
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. »
Une seule expression pour qualifier tout ça : le bordel intégral ! On espère vraiment populariser le chiffrement de bout en bout avec ça ?! Sérieusement ?
Où je veux en venir ? On n'arrivera jamais à faire percer la crypto avec :
1) des logiciels à l'ergonomie vaseuse (Enigmail et gajim-otr, même combat) ;
2) des logiciels complètement cramés d'un point de vue de la sécurité ;
3) des algos foireux, dépréciés et non sécurisés activés de base (GPG et OTR, même combat) ;
4) XXXX méthodes de chiffrement/signature dont aucune n'atteint l'objectif et n'est réellement utilisable par des non-initiés (on a le même problème avec le chiffrement des SMS... SMSSecure, TextSecure, Signal, Telegram... à part SMSSecure, toutes sont vaseuses/dangereuses (voir
http://shaarli.guiguishow.info/?CGDOlw et
http://shaarli.guiguishow.info/?vungLg ) et SMSSecure ne semble pas être accessible aux non-initités).