AurionMail : Unifier CryptPad et le mail chiffré sous un seul mot de passe

Services Mail
1

Salut tout le monde !

Je me permets de faire un petit post ici parce que je me dis que ce que j’ai bricolé cet été pourrait intéresser du monde par ici. Si les modos pensent que cela n’a pas sa place ici, qu’ils n’hésitent pas à supprimer.

Au départ, je suis parti d’un constat tout bête : jongler entre des documents chiffrés et du mail chiffré, c’est souvent la galère. Entre les outils cloisonnés, les extensions de navigateur comme Mailvelope ou la gestion de deux mots de passe différents, c’est trop pénible. Quand je propose ce genre de stacks à mes amis, la réponse est souvent : « Merci pour tes efforts, vraiment, mais je vais rester sur Proton :sweat_smile: » Et en vrai, ils n’ont pas tort.

Du coup, j’ai développé AurionMail Suite. C’est la colle qui relie CryptPad, Stalwart Mail Server (JMAP), Bulwark Webmail et Ory Hydra dans un flux unifié qui reste chiffré de bout en bout.

J’en ai aussi profité pour rafraîchir un peu l’interface de CryptPad (et l’app de texte native) pour que ça colle avec le design du webmail. D’ailleurs, si vous voulez juste piquer le look & feel pour votre propre instance, c’est possible : j’ai simplement modifié le dossier customize ! Normalement, il y a un GIF pour montrer le workflow et l’ UI, mais je n’arrive pas à l’uploader ici, vous pouvez le retrouver là : docs/screenshots/demo.gif at main · AurionMail/docs · GitHub

En résumé, ce que ça propose :

  • Un seul mot de passe : On le retape une seule fois par session maximum pour dériver les clés en mémoire (RAM) à la fois pour le webmail OpenPGP et l’espace CryptPad.
  • Standards ouverts : Du JMAP via Stalwart et de l’OpenPGP pour le mail.
  • Gestion de session unifiée : Déconnexion globale et changement de mot de passe synchronisés entre les services.
  • Déploiement : En plus du setup Docker classique, j’ai tout packagé (Hydra, SSO, Webmail, API, CryptPad) dans un seul binaire en Go qu’on a appelé Orchestra.
  • Les clefs utilisées par les utilisateurs sont automatiquement “discoverable” avec WKD

Le projet est sous licence AGPLv3 et tout le code est dispo sur GitHub : GitHub - AurionMail/docs: It is ProtonMail UX, but really open-source and self-hostable · GitHub et il y a aussi un security_model.md pour les détails sur la sécu et algorithmes utilisés.

C’est pensé pour s’intégrer dans vos stacks existantes : on utilise LDAP pour les utilisateurs et le SSO (Ory Hydra) peut aussi s’utiliser avec d’autres applications pas du tout chiffrées si il faut.

Je sais bien que c’est loin d’être parfait, donc si vous avez 5 minutes pour y jeter un œil, tester, ou juste me faire un retour sur l’architecture, je suis grand preneur de vos avis et suggestions !

1 Like
2

Je suis pas sûr de comprendre si les mails sont chiffrés avec la clé secrète de l’usager et donc non lisibles par le serveur ?

4

Salut, il faut différencier plusieurs cas

  • message reçu : s’il est déjà chiffré avec la clef publique de l’utilisateur, il est illisible par le serveur. Dans le cas contraire, on utilise la fonction “chiffrement au repos” de Stalwart qui va chiffrer automatiquement le mail avec la clef publique de l’utilisateur. Donc tous les messages reçus sont illisibles par le serveur.
  • messages envoyés :
    • si tous les destinataires ont une clef publique, tout va bien, le mail est bien chiffré de bout en bout
    • sinon, on envoie le message non chiffré aux destinataires qui n’ont pas de clef publique, mais on stocke coté serveur toujours la version chiffrée (avec la clef publique de l’utilisateur).

Donc dans tous les cas, au repos, les messages sont illisibles par le serveur. Le serveur ne peut voir le message que si on l’envoie à un destinataire sans clef. Dans ce cas, il le transfère seulement sans le stoker (puisque c’est la version chiffrée qui est persistée).

5

C’est super d’être enthousiaste et d’avoir l’envie de créer de super outils !

Juste, je pense que, comme nous sommes quelques-un.e.s à être assez critiques de l’IAGen (notamment dans le dev), tu pourrais déclarer si tu en as utilisé, et à quel point :smiley:

1 Like
6

Désolé c’est pas beaucoup plus clair pour moi. Est-ce que tu parles ici du chiffrement PGP du contenu du mail ?

Car JMAP ne me semble pas permettre de chiffrer les messages sur le serveur, le protocole a toujours besoin d’accéder aux headers.

Et du coup c’est pas trop similaire à Proton, où le serveur n’a pas accès aux headers.

7

Salut, merci pour ton retour ! En fait, j’ai essayé de nombreuses fois d’utiliser l’IA mais le problème est que je n’ai rien codé ou presque à partir de rien, à chaque fois, il y a beaucoup de contexte différents à prendre en compte, donc cela allait souvent plus vite de coder soi-meme ce que je voulais au lieu de donner tout le contexte des différentes applications qui communiquent. Voici comment je l’ai utilisée dans les différentes briques :

  • SSO : Il y avait un squelette proposé par Ory Hydra, je l’ai donc pris et simplement rajouté les dérivations et le login avec OPAQUE. L’IA a été utilisée pour faire la partie de vérification avec LDAP pour l’initialisation du compte. Le design est avec tailwind dans le style du webmail, j’ai littéralement copié leur fichier de style.

  • Le plugin PGP : L’IA a été utilisée pour la partie de génération des MIME des mails avec PGP. Ella a été aussi utilisée pour l’UI.

  • Core-API: C’est une des seules applications que j’ai écrit de 0. L’IA a été utilisée pour cette application. Cela reste en fait du CRUD basique.

  • Bridges: Ce sont des fichiers appelés en iframe qui permettent aux app de communiquer. Ici, je n’ai pas utilisé l’IA du tout car elle ne comprend rien, et je perds plus de temps à expliquer qu’à écrire ce que je veux.

  • CryptPad : Pour le style, l’IA a été utilisée. Mes souvenirs de CSS sont un peu loin. Elle a notamment été utilisée pour l’UI de la page drive. Pour le reste, ce sont des essais manuels avec les outils de dev du navigateur pour trouver la bonne combinaison de CSS qui marche ^^. Pour la logique d’intégration avec le reste, non.

  • Le site internet : fait avec l’IA, par manque de temps, et parce que ce n’est pas le plus important.

8

Désolé ne pas être assez clair :sweat_smile: ! Je parle bien de chiffrer le contenu du mail (texte + pièces jointes) avec PGP. Mais je croyais que Proton avait accès aux headers ?

How Proton Mail messages are encrypted | Proton :

  • Body content and attachments are stored with end-to-end encryption

  • Subject lines, recipient email addresses, and sender email addresses are encrypted, but not end-to-end encrypted.

9

Comme l’indique la seconde ligne, ils sont chiffrés par le client avec la clé privée de l’usager, comme le reste des mails.

Proton a deux niveaux de chiffrement :

  1. PGP pour la transmission des mails sur le réseau
  2. chiffrement des données stockées sur le serveur, par le client, avec sa clé privée

Proton n’a pas accès aux headers, sauf certains qui sont stockés en clair pour la recherche (sujet, date, expéditeur, destinataire), mais ils auraient pu faire sans (mais c’était plus compliqué).

10

J’avoue que je ne me suis pas penché sur la façon exacte Proton chiffre les données du compte, mais si j’en crois la politique de confidentialité de Proton (https://proton.me/mail/privacy-policy) :

Due to limitations of the SMTP protocol, we have access to the following email metadata: sender and recipient email addresses, the IP address incoming messages originated from, attachment name, message subject, and message sent and received times. We do NOT have access to encrypted message content.

Ce qui correspond exactement aux headers les plus sensibles.

Même si l’on distingue le transit du stockage au repos, le résultat reste le meme : en transit, le serveur a accès aux métadonnées pour le routage. Et au repos, au moins le sujet, la date, l’expéditeur et le destinataire restent accessibles au serveur pour l’indexation et la recherche (ce ne sont pas des données chiffrées de bout en bout).

Cela correspond également au modèle que j’ai utilisé. Dans tous les cas (repos et transmission), les admins ont effectivement accès à ces données. PGP ne permet pas à ma connaissance de chiffrer les headers.

Donc je ne comprends pas où est la différence avec mon setup :

  1. Dans les deux cas, le serveur peut lire les métadonnées.

  2. Dans les deux cas, le contenu du mail est chiffré par PGP avec la clef publique de l’usager et illisible pour le serveur

Je crois qu’il y a un malentendu sur le chiffrement de Proton ou alors j’ai mal compris :sweat_smile: :

  • encrypted : chiffré sur le serveur avec une clef accessible par Proton
  • e2e encrypted : chiffré avec notre clef non accessible par Proton
11

Je t’invite à lire la doc de Tuta ou Proton, mais ce que tu fait n’est pas proche d’eux. C’est pas mal, mais c’est pas équivalent :slight_smile: