Sécurité

Un audit dont la moitié du travail a consisté à nous contredire.

Auditer veut dire une chose simple : relire tout le code en cherchant à le casser, comme le ferait quelqu’un qui vous veut du mal. Nous l’avons fait sur l’ensemble du logiciel, en interne, avec une règle. Chaque faille supposée est confiée à une seconde analyse chargée de démontrer qu’elle n’existe pas. Ce qui résiste est corrigé, puis surveillé par un test automatique.

failles recensées

Recensées par les deux campagnes de début août 2026 — un audit offensif le 3, une revue manuelle du code le 4 — après déduplication et retrait de ce qui était déjà corrigé. Chaque faille supposée a d’abord affronté une seconde analyse chargée de la réfuter ; ce qui n’a pas survécu n’est pas compté ici. Les constats restés ouverts de la revue générale de juillet ne sont pas encore fusionnés dans ce registre.

corrigées

Corrigées au 15 septembre 2026. Quand l’attaque peut se rejouer en programme, le correctif vient avec un test automatique qui la rejoue à chaque intégration. 13 autres sont réduites : le correctif applicatif est livré, et le risque qui survit est écrit noir sur blanc dans le registre plutôt que passé sous silence.

encore ouvertes

Les deux sont le même défaut vu de deux côtés : l’étiquette d’opérateur d’un relais est auto-déclarée, l’autorité la signe telle quelle, et toute la diversité de chemin repose sur elle. Ce qui vaut preuve qu’un opérateur en est un n’est pas encore tranché. État arrêté au 15 septembre 2026. Nous préférons publier ce compte que le taire.

La méthode, étape par étape

Étape 1 : attaquer

Nous relisons tout le code en cherchant les failles. Chaque comportement douteux est noté, avec l’attaque qu’il rendrait possible.
Étape 2 : contredire

Chaque problème noté part ensuite à une seconde analyse, dont le travail est de démontrer qu’il est faux. Ce qui n’a pas survécu à cette étape n’est pas compté dans les 71. C’est ce qui nous permet d’affirmer que les chiffres annoncés ici ne sont pas gonflés.
Étape 3 : corriger et rejouer

Sur les 71 failles recensées, 56 sont corrigées et 13 réduites au 15 septembre 2026 ; 2 restent ouvertes. Quand l’attaque peut se rejouer en programme, le correctif vient avec un test qui la rejoue à chaque intégration : si la faille revient un jour, ce test échoue et le dit. Les réduites sont celles où le correctif applicatif est livré mais où une part du risque survit : parfois elle dépend d’un déploiement (un drapeau à poser sur les relais, un certificat HTTPS sur l’autorité), parfois d’une décision de conception qui se conçoit et ne s’improvise pas. Le détail faille par faille n’est pas publié à ce jour, et nous ne prétendons pas le contraire tant qu’il ne l’est pas. Écrivez-nous : nous répondons précisément sur celles qui touchent votre usage.

Ce que la dernière campagne a trouvé

Début août 2026, deux failles du cœur cryptographique ont été démontrées par un programme qui les exécute, et non seulement décrites.

La première est corrigée. Un défaut d’échange de clés permettait à quelqu’un ne possédant aucune clé de faire accepter une conversation. Le contrôle manquant existait déjà ailleurs dans notre code ; il manquait précisément là où passent toutes les conversations. Corrigé le 4 août 2026, avec un test qui rejoue l’attaque à chaque intégration.

La seconde, classée critique, est réduite depuis le 13 septembre 2026. Deux relais complices pouvaient marquer un message au départ et le reconnaître à l’arrivée, ce qui relie l’expéditeur au destinataire. Le corriger changeait le format des messages sur le réseau : c’est fait, avec la version 3 de l’en-tête (application 2.3.0, relais v0.12.0 sur toute la flotte), au prix d’une rupture assumée — un client 2.2.0 et un client 2.3.0 ne peuvent plus ouvrir de conversation. Ce qui reste, et nous l’écrivons : les relais acceptent encore l’ancien en-tête tant que le mode strict (--strict-header-v3) n’est pas posé sur la flotte, et deux relais complices consécutifs gardent un canal de marquage que cette construction ne peut pas fermer. Le réseau actuel n’ayant qu’un seul opérateur, aucun tiers ne peut l’exploiter aujourd’hui — mais le résiduel doit être réglé avant l’arrivée de relais tenus par des tiers.

Nous l’écrivons ici parce qu’un produit de sécurité qui ne publie que ses succès n’apprend rien à personne.

Posture par défaut

[profile.release]
panic = "abort"

Cette ligne de configuration ordonne au logiciel de s’arrêter net dès qu’il rencontre une situation qu’il ne sait pas traiter, plutôt que de continuer dans un état incertain. La conséquence est assumée : tout plantage qu’un tiers peut déclencher compte comme une faille à corriger, jamais comme un incident à ignorer.

Ces chiffres viennent d’un audit interne, mené par l’équipe qui écrit le logiciel et non par un cabinet extérieur indépendant. Ils ne valent donc pas certification. Ils sont vérifiables en partie : le code du réseau — relais, annuaire, autorité — est publié sous licence AGPL-3.0 dans le dépôt public, et n’importe qui peut le lire ou le relancer. L’application, elle, est propriétaire, et une partie des tests qui rejouent les attaques vit dans le dépôt privé : nous ne les disons pas publiés tant qu’ils ne le sont pas. Nous ne revendiquons aucun label que nous ne détenons pas. Le jour où un organisme indépendant nous en délivre un, son nom et la date seront écrits ici.

Signaler une vulnérabilité

Si vous trouvez une faille, écrivez-nous en privé avant d’en parler publiquement. Nous corrigeons d’abord, puis la faille et son correctif sont publiés. C’est ce qu’on appelle la divulgation coordonnée. Vos messages sont lus par les ingénieurs qui écrivent le code, pas par un service client.

Contact sécurité

crypto.app.organisation@proton.me

Politique de divulgation : le fichier SECURITY.md du dépôt · pas de clé PGP publiée à ce jour · une personne vous répond

Historique public des correctifs