Deltachat
Depuis un moment maintenant j’utilise DeltaChat, une application de messagerie instantanée. Il en existe déjà beaucoup, des très bien même, mais j’aimerais écrire ici pourquoi je trouve qu’elle vaut le coup de s’y pencher.
Précision: ma position politique globale fait que les messageries instantanées qui promeuvent le capitalisme, le fascisme, l’autoritarisme sont les entités à détruire. Les messageries instantanées qui ne promeuvent pas ça ne doivent pas être en compétition, il ne sert à rien d’en trouver une qui écrase les autres.
C’est quoi
Deltachat est une application semi-libre disponible sur Android, iOS, Windows, Linux et Ubuntu Touch. Semi, car la version de bureau se base sur Electron qui bien que techniquement libre repose sur Google. L’interface est relativement standard, on peut se créer plusieurs profils, chaque profil peut discuter avec plusieurs personnes, en 1-1 ou en groupe. L’entièreté des communications est chiffrée de bout-en-bout via PGP
Deltachat est fait pour fonctionner hors-ligne en priorité. On peut créer des groupes, y ajouter des membres, envoyer des messages sans connexion; tout sera envoyé comme voulu au moment à la prochaine connexion. Les groupes sont totalement égalitaires: il n’y a pas de rôle, tout le monde peut y ajouter ou enlever n’importe qui. Il faut donc veiller à faire confiance aux personnes qui y sont.
Il est possible d’utiliser plusieurs appareils pour un compte donné. Aucun appareil n’est plus important qu’un autre. Le moyen le plus simple pour faire des backups, ainsi, est d’avoir un appareil/bot additionel qui partage le même compte.
Pour ajouter une personne, il faut scanner son qr code ou entrer son lien: c’est une information privée accessible sur demande, et qui garantit le chiffrement de bout en bout (à condition que personne n’ait accès au QR code ou au lien: il vaut mieux scanner le qr code en présentiel, au pire des cas on peut envoyer le lien par un moyen tiers mais on doit faire confiance à ce moyen).
https://securejoin.delta.chat/
Du point de vue technique un compte est simplement une paire de clés PGP. Elle sert tout autant à identifier le compte qu’à chiffrer le contenu. Les messages sont de simples emails chiffrés. Il y a donc une ou plusieurs addresses à provisionner pour chaque compte. Chaque adresse pourra être utilisée pour envoyer et recevoir des messages, en passant par des serveurs mails. On peut utiliser une adresse existante, ou on peut utiliser les relais chatmail. Ce sont des serveurs mails sur lesquels sont ajoutés quelques petits bonus bien utiles pour le mode de fonctionnement de Deltachat:
- les emails non-chiffrés, en envoi comme en réception, sont refusés
- les adresses peuvent être créées automatiquement: si je tente de me connecter avec un identifiant et un mot de passe que je choisis et que l’adresse n’existe pas, elle est créée pour moi et considérée comme valide
- les adresses sont non-identifiables: le serveur peut créer lui-même des adresse aléatoires (c’est-à-dire que l’identifiant devant le @ est aléatoire) et c’est ce qu’utilise Deltachat
- Les messages sont inconditionnellement supprimés au bout d’un certain temps. Lorsqu’un compte n’a qu’un seul appareil celui-ci supprime les messages dès qu’ils sont reçus. S’il y a plusieurs appareils le relais permet de synchroniser les messages et leur état de lecture.
- Les addresses sont automatiquement supprimés au bout d’un certain temps d’inactivité
À noter: tous les détails techniques sont cachés des utilisataires. Il n’y a pas besoin de savoir comment ça marche pour utiliser Deltachat. La seule chose importante à retenir si on vient de l’extérieur: Deltachat envoie et reçoit des emails chiffrés avec PGP. Les emails ont des métadonnées particulières pour fonctionner proprement (modification de message, réaction, groupes, messages webxdc …) mais qui ne sont que des ajouts sur des emails classiques. L’interopérabilité est une base qui ne changera pas.
https://github.com/chatmail/core/blob/main/standards.md
Deltachat réfléchit à la manière de faire des groupes aux rôles hiérarchiques. En attendant d’avoir la solution miracle il est possible de créer des canaux de distribution: c’est comme un groupe, sauf qu’il n’y a qu’un seul compte qui peut écrire, les autres ne peuvent que lire, même pas réagir. Sans être une solution ce sera certainement une brique utile pour y arriver, et est déjà utile aujourd’hui.
Les applications WebXDC
Le gros point différenciant de Deltachat, ce sont les applications webxdc. Ce sont des documents html+css+js (un peu comme une webapp purement côté client) zippés.
Une application est un fichier partagé à l’intérieur d’un groupe de discussion donné. Les différentes applications à l’intérieur d’une même conversation sont totalement indépendantes: on peut partager plusieurs fois la même application mais elles ne se verront pas.
Pour éviter tout problème les applications sont exécutées dans un environnement cadenassé qui bloque toute communication avec l’extérieur (HTTP, DNS, webrtc, appareil, rien ne passe), sauf envoyer et recevoir des messages dans la conversation. Les messages envoyés dans la conversation seront ainsi reçus par toutes les personnes dans la conversation, accessibles uniquement à l’intérieur de l’application. Et comme les messages sont conservés, la conversation sert aussi de stockage de données.
Les applications WebXDC peuvent aussi ouvrir un canal iroh: c’est un tunnel direct entre les comptes qui sont connectés, chiffré de bout en bout, qui ne passe pas par le serveur (sauf la partie signalisation pour se trouver). Le tunnel permet ainsi de s’affranchir des limites de taille. Tout comme les messages, les paquets sont envoyés à tous les comptes connectés; il n’est pas possible de choisir individuellement dans le tunnel.
D'autres applications s'intéressent à ce format: cheogram et monocles, deux messageries instantanées basées sur XMPP, permettent de les utiliser. Bien sûr vu qu'elles ne parlent que XMPP elles ne peuvent pas dialoguer avec DeltaChat
https://github.com/n0-computer/iroh
Les points qui diffèrent
Par rapport à d’autres messageries voici ce qui m’intéresse et qui fait que je considère Deltachat comme intéressant, sans ordre de préférence:
- Les applications WebXDC redéfinissent complètement le concept de “fournir un service”. Au lieu d’avoir un serveur qui tourne 24/7, avec son matériel, sa base de données, ses comptes utilisataires (et donc un n-ième compte qu’il faut créer), … les applications fournissent la logique et Deltachat fournit le stockage, l’authentification, l’autorisation, la communication. Au lieu de créer un pad et d’envoyer le lien aux bonnes personnes, je crée un pad dans le groupe: toutes les personnes dans le groupe sont les bonnes et y ont accès. Créer, maintenir et sécuriser un service ne nécessite plus que la partie réellement fonctionnelle, infiniment plus accessible que faire tourner un serveur. En fait au lieu de considérer Deltachat comme un système client-serveur il est plusse correct de le considérer comme une application P2P dont les échanges sont facilités par les relais. C’est le principal problème des applis P2P, comment envoyer un message si les deux côtés ne sont pas allumés en même temps.
- Si mon compte est lié à un relai chatmail, ce qui est le cas par défaut, personne ne peut me contacter sans avoir ma clé publique. L’adresse mail n’est plus un accès à moi; en fait ce n’est même plus un identifiant pertinent. Puisque mon qr code et mon lien sont privés, il n’y a plus de spam possible
- Les groupes sont égalitaires parce que c’est le moyen le plus simple de gérer la participation lorsque les participant·es peuvent être hors-ligne pour une longue durée. Cela signifie donc que Deltachat n’est pas pour tous les cas d’utilisation: il faut faire confiance à tout le monde. Pour les groupes ouverts ce ne sera jamais possible, et Deltachat n’est pas utilisable. Pour les groupes fermés, cela force à se poser concrètement la question de la confiance et donc de réfléchir à l’organisation sociale du groupe… et donc de faire de la politique, finalement
- Deltachat est fait pour fonctionner hors-ligne le plus possible. Même les applications sont faites pour. C’est mentalement reposant de ne pas se dire qu’il y a un problème quand “le message n’a pas pu être envoyé”: c’est normal, ça marchera quand ça marchera
- Il y avait un article de Moxie, le créateur de Signal, qui disait que la décentralisation empêchait d’avancer et que seul une architecture centralisée pouvait résoudre le problème. Heureusement personne n’y croit plus, à raison. Une architecture centralisée, au sens où le fonctionnement du système passe par un point central, est problématique; mais là où Moxie avait raison c’est que les décisions de développement centralisées permettent de construire un système et même un écosystème robuste. Deltachat va à fond dans ce développement centralisé en créant sur une brique commune, chatmail-core, pour toutes les apps et les bots. Ce coeur permet d’avoir une expérience fonctionnelle sur toutes les plateformes, qui chacune développe ce qui lui est spécifique; des clients et des bots indépendants se sont créés par dessus ce coeur. Et le plus important est que le déploiement de l’infrastructure reste totalement décentralisé et dans les mains des personnes concernées
https://github.com/chatmail/core
- Deltachat ne fonctionne plus dans une vision client/serveur, dans laquelle le serveur fait ce qu’il veut et le client doit lui faire confiance. Le serveur a besoin d’être allumé, il doit être sécurisé, etc… À l’inverse, ici le serveur ne fait rien d’autre que transmettre des messages; il les supprime même automatiquement au bout d’un certain temps. Il n’y a rien qui puisse lui donner de l’importance, donc il peut être plus facilement remplacé, ou migré. Si un relai tombe en panne on peut en ouvrir un autre et migrer les DNS: les clients se reconnecteront avec leur mot de passe comme d’habitude, les adresses seront créées automatiquement, c’est suffisant dans la plupart des cas (des messages peuvent être perdus, mais ils peuvent être ré-envoyés)
- Deltachat met en place la possibilité d’avoir plusieurs relais. Ca veut dire que si un relai ne marche pas, les messages peuvent passer par d’autres relais. C’est un moyen de baisser encore l’importance de chacun de ces relais et d’envisager encore plus un fonctionnement qui ne vise pas le 24/7. En allant plus loin on peut même viser que chaque message passe par une nouvelle adresse à chaque fois.
- Il est prévu et même encouragé de se créer plusieurs comptes. Le coût d’entrée de chacun est nul. Avoir plusieurs comptes c’est segmenter ses communications, plutôt que de tout faire passer par un seul identifiant unique. En plus de ça chaque compte est prévu pour être utilisé avec plusieurs relais. In fine les seules métadonnées visibles par des tiers sont les adresses mail utilisées, la date et l’heure des messages, et leur taille; tout le reste est indéchiffrable. Et comme les adresses sont anonymes il y a au final très peu de métadonnées qui se baladent.
- C’est du PGP, et aujourd’hui il n’y a pas de Perfect Forward Secrecy ni de protection contre les ordinateurs quantiques. À cela, quelques objections: la Forward Secrecy protège dans le cas où l’entièreté de la conversation est conservée et déchiffrée après coup, surtout quand l’appareil est saisi et la clé extraite. C’est un vrai scénario, mais ce que le terrain a l’air de dire c’est que ce sont les métadonnées qui sont importantes, pas tant le contenu des messages (ça varie pour chaque cas d’utilisation bien sûr). Lorsque l’appareil est saisi la forward secrecy ne protège plus de rien; ce qui protège c’est l’historique qui est automatiquement supprimé (ce que peut faire Deltachat), ce sont les conversations temporaires (Deltachat permet de “cloner” un groupe avec exactement les mêmes personnes, rapidement), ce sont les comptes temporaires (ce sur quoi Deltachat se repose). Et si le besoin est vital il y a une application WebXDC qui fournit un chat accessible via le tunnel en temps réel iroh: iroh fournit de la Forward Secrecy donc tout ce qui y transite en profite.
- Les relais faisant si peu, ils sont faciles à déployer et maintenir. Un sondage informel de plusieurs admins dit qu’il faut moins de 2h d'administration par mois pour gérer un serveur avec plusieurs dizaines de milliers de comptes, qui peut tourner sur un VPS à 5 euros.
https://chaos.social/@delta/113307519686226505
Les limites
Tout n’est pas parfait bien entendu, il y a des points sur lesquels il faudrait plus de clarté:
- Le développement est centralisé mais la structure en question est opaque. Il y a une entreprise dans l’histoire et des gens qui sont dedans, mais d’autres qui ne sont pas dedans, les discussions internes sont privées. Il y a bien un forum public dans lequel beaucoup de choses sont discutées, le développement se fait sur github en public, mais les décisions ne le sont pas. D’un côté je comprends le besoin de se concentrer sur un groupe de personnes qui contribuent concrètement, de l’autre c’est quand même bof
- L’application officielle sur ordinateur utilise Electron. J’ai moins de problèmes avec que ce que d’autres peuvent avoir mais j’aimerais quand même ne pas dépendre autant de ça. Il y a des alternatives en cours de création.
- Certaines fonctionnalités pratiques ne sont pas possibles avec un fonctionnement P2P: récupérer un historique, gérer des rôles hiérarchiques, récupérer ses données quand on a perdu son seul appareil. Rien n’est fait spécifiquement de ce côté là
Pourquoi Deltachat est construit comme ça
Beaucoup d'imprécisions circulent sur Deltachat et pourquoi est-ce que c'est construit comme ça (pourquoi le mail, pourquoi PGP, ...). C'est une conséquence de l'historique de l'application: au début les développeur·euses pensaient pouvoir faire une application qui réutilisait un compte email existant, pour faire de la conversation instantanée en utilisant le même compte, à la fois pour des conversations format long et format court, le tout chiffré automatiquement avec PGP. C'est en ce sens qu'Autocrypt a été utilisé: si les échanges se font en clair, propager les clés PGP pour que petit à petit, ce dernier soit utilisé partout.
Cette façon de faire, intéressante à priori, a posé plusieurs problèmes:
- Le contenu reste en clair par défaut. Le basculement en chiffré est opportuniste, donc seulement si c'est possible de l'autre côté, et peut être facilement intercepté par les serveurs intermédiaires
- La communication peut passer de clair à chiffré, puis repasser en clair: les attentes sont plutôt qu'une fois chiffré on ne peut pas "revenir en arrière"
- Les messages chiffrés et non-chiffrés se mélangent dans la même boîte mail. Sauf que si Deltachat est capable de lire les deux, les autres appareils ne le sont pas, et se retrouvent avec des messages illisibles. Sauf que les autres applications ne montrent pas que c'est un message chiffré qu'elles ne peuvent pas déchiffrer, mais montrent un message bien réel avec du gloubi-boulga incompréhensible
- PGP est très manuel, il n'y a rien pour synchroniser facilement des clés privées
- Les adresses emails étant publiques, elles sont facilement victimes de spam. La réponse historiquement a été multiple: inscriptions de domaines mauvais sur des blocklists, maintenant dirigées par des boîtes privées qui y ont des intérêts commerciaux, quotas d'envois, ralentissement arbitraire des envois. Ces mesures sont peu compatibles avec une messagerie instantanée ouverte à tout le monde
À ce moment là déjà, la manière de fonctionner de Deltachat avait divergé: au lieu d'être identifié par une adresse email, chaque profil est identifié par une clé PGP. Les serveurs mails ne sont que de simples passe-messages. Pour éviter d'avoir à subir les problèmes évoqués plus haut, dans un premier temps l'équipe a mis au point les relais chatmail. Ce sont de simples serveurs mail (smtp+imap) avec une particularité: tous les comptes sont automatiquement provisionés à partir du moment où une personne essaie de s'authentifier (et que le compte n'existe pas déjà, bien sûr). Cela permet à l'application de créer un compte aléatoire et de l'utiliser pour communiquer. Le compte mail peut être supprimé et recréé, cela n'a pas d'importance: tant que la clé PGP est la même le profil ne change pas.
Également, Deltachat a changé la manière de voir les choses: puisqu'un profil est défini par sa clé publique, et que connaître cette clé publique permet de lui envoyer des messages, celle-ci n'est jamais directement manipulable dans l'interface. À la place la prise de contact se fait prioritairement en scannant un qr code, ou en échangeant un lien. Ce protocole est une partie de SecureJoin, mis au point pour éviter les MITM. Les relais ont également comme particularité qu'aucun message non-chiffré ne peut passer, ni en réception, ni en envoi. Avec ceci est venu la dernière évolution: puisque les relais ne sont que des relais, il est possible d'en utiliser plusieurs. Chaque profil a ainsi maintenant plusieurs boîtes par lesquelles les messages sont envoyés et reçus, sans que les relais ne sachent qui discute avec qui puisque les adresses mails sont créées aléatoirement. Les relais ne sont que de simples relais, ils ne savent rien de ce qu'il se passe dans les communications: qui parle à qui, qui est dans un groupe avec qui, qui a combien d'appareils, ...
SecureJoinQuelques questions courantes et leur réponse
Pourquoi utiliser le mail et pas XMPP comme fondation
SMTP/IMAP sont faits pour de la communication asynchrone, XMPP est fait pour du synchrone, cela devrait être pourtant logique ! SMTP/IMAP ont été choisis initialement pour leur déploiement massif existant. L'erreur initiale a été de croire qu'un compte existant pouvait être réutilisé sans problème. La nouvelle architecture aurait donc pu se faire sur XMPP mais
- le code ne partait pas de zéro. Utiliser XMPP voulait dire repartir de zéro
- il y a confusion entre "messagerie instantanée" et "synchronicité". Historiquement les deux étaient synonymes, on se disait bonjour et au revoir, mais les usages ont évolué. Une messagerie est une discussion au format chat, sans début ni fin
- l'asynchronicité de SMTP est une particularité sur laquelle Deltachat se construit. Toutes les opérations peuvent se faire localement, sans connection, et se synchroniser quand le message peut être envoyé. Les applications Webxdc sont faites pour être utilisées hors-ligne. L'asynchronicité est une force, pas un problème.
- XMPP c'est un coeur et des extensions. En pratique beaucoup d'extensions sont "attendues", comme par exemple celle pour les discussions de groupe. Sauf que ce fonctionnement est aux antipodes de celui de Deltachat: les serveurs ne savent rien, tout est géré par les appareils, un profil passe par plusieurs serveurs pour communiquer. Une nouvelle XEP aurait pu être écrite, mais à ce compte là réutiliser XMPP a-t-il encore autant d'intérêt ? Si la seule partie commune est le coeur aucune appli existante n'est compatible, est-ce qu'on y gagne ? "Basé sur xmpp", à ce niveau, est à peu près aussi utile que dire "basé sur tcp/ip": c'est techniquement vrai mais
- le coeur d'XMPP spécifie les bases pour router les messages et la présence. Deltachat, par son fonctionnement volontairement asynchrone, ne fait pas de présence et ne vise pas à en faire. La synchronicité de XMPP devient un poids
- XMPP est utilisable avec plusieurs appareils, mais chaque appareil aura sa "resource". Cela implique donc que le serveur sait quels sont les appareils de l'utilisataire: pas ouf
- D'un point de vue pur produit deltachat existe et marche sur toutes les plateformes en cherchant partout un unique nom. Pas de pbs de compatibilité. C'est la force de l'écosystème mais également sa plus grande faiblesse qui doit nous maintenir vigilant·es: tout est fait par une seule équipe, qui techniquement utilise un seul coeur commun wrappé par une ui spécifique à chaque plateforme. Plus le temps passe, plus une implémentation indépendante est dure à faire.
Le mail n'a pas de réactions/modifications/groupes, le sujet est en clair/on peut pas chiffrer les métadonnées etc
Certaines de ces fonctionnalités ont été standardisées en dehors de Deltachat, d'autres non; quelle que soit leur origine, tout est documenté, spécifié, parfois même dans des rfc
Les standards utilisés Les spécifications de messagerie spécifiques à DeltachatPourquoi réinventer la roue ?/C'est incompatible !
Le fonctionnement, ce sont des discussions potentiellement de groupes entièrement asynchrones: créer un groupe, le modifier, y inviter des personnes, réagir à des messages, entamer une discussion avec un nouveau contact, tout doit être complètement faisable hors-ligne. La roue n'existe juste pas. C'est nécessairement incompatible avec l'existant puisque l'existant ne permet pas de faire ce qui est demandé
Les mails en PGP c'est pas safe
Il y a plusieurs parties dans cette affirmation qui ont besoin d'être éclairées.
PGP est un format relativement vieux et qui date d'une époque où plusieurs des hypothèses ont été depuis cassées. Notons que c'est aussi le cas de TLS. Il n'y a donc rien de rédhibitoire à pgp en tant que tel, mais les implémentations doivent faire plus attention, ce qui est source de problèmes. OpenSSL par exemple n'est pas exempt de bugs critiques par le passé, mais son analyse continue fait qu'il est encore ok aujourd'hui. GnuPG a été source de problèmes également, et deltachat ne l'utilise pas mais a mis au point une implémentation indépendante et auditée, rpgp. Cette implémentation, et le format des messages de Deltachat, font que les failles que l'on a en tête ne marchent pas. Failles qui étaient plutôt de l'ordre d'une mauvaise gestion des emails que de pgp pour certaines, ou gpg qui est trop laxiste pour d'autres
Les audits de DeltachatOn remarquera que les personnes qui critiquent omemo ont comme standard Signal. Ce sont les mêmes personnes qui vont dire que pgp est sûrement pire
Puisque ce sont des serveurs spécifiques l'infrastructure déployée n'est pas réutilisable donc l'argument de l'infra est caduc
Les relais sont des serveurs postfix+dovecot, configuré avec dkim mais sans dmarc, arc ni spf, avec un wrapper qui a les fonctionnalités suivantes:
- les mails non chiffirés avec pgp sont refusés (note: c'est plus une optimisation qu'autre chose, un profil qui reçoit un message non-chiffré ou chiffré pour une autre clé n'en fera rien)
- les comptes sont automatiquement créés, s'ils n'existent pas déjà, quand un client se connecte
- les messages sont automatiquement supprimés au bout de X jours
- les comptes sont automatiquement supprimés si inutilisés au bout de Y jours
Bref, rien de spécifique. Les serveurs classiques peuvent tout à fait être utilisés, avec un compte mail spécifique (mais qui du coup perdra en anonymat). La plupart des déploiements ayant des mesures antispam (quotas, greylisting), ces mesures ralentiront les conversations. Si on a son propre serveur qu'on peut configurer on peut désactiver les mesures pour les comptes utilisés sur deltachat. Et on peut tout à fait utiliser un compte non-chiffré, mais uniquement pour les mails "classiques" donc non-chiffrés: ce sera comme un client mail classique mais au format messagerie.
Bref, l'infrastructure est réutilisable, pas forcément en l'état, mais c'est surtout une conséquence de l'état asseè triste de l'infra qu'autre chose