Si vous exportez votre clef privée OpenPGP (avec gpg --export-secret-key), même protégée par une phrase de passe, un attaquant qui met la main sur la clef ainsi exportée peut la modifier et la compromettre, vous exposant ainsi à de possibles attaques ultérieures si vous ré-importez la clef modifiée.
Si vous avez stockée votre clef privée (au format OpenPGP standard telle que généré par --export-secret-key) sur un support qui a potentiellement été hors de votre contrôle (a fortiori par exemple si vous l‘avez stockée en ligne), ne la ré-utilisez pas aveuglément : vérifiez son empreinte au moment de la ré-importer.
Il vaut mieux éviter, mais une des promesses du format OpenPGP était que tant que la clef est exportée avec une phrase de passe suffisamment forte, il devait tout de même être possible de le faire sans craindre de s’exposer à une compromission.
Ce que montre cette attaque est que cette promesse en particulier n’est pas tenue. Il est donc désormais formellement déconseillé de stocker une clef privée dans le format d’échange OpenPGP sur un support non-sûr, si on l‘intention de ré-utiliser la clef depuis ce même support, à moins de prendre des précautions supplémentaires.
Les précautions supplémentaires pouvant consister par exemple à rajouter une couche de chiffrement par-dessus le chiffrement déjà intégré au format d’échange, ou au minium une couche de vérification d’intégrité.
Non, tu peux la chiffrer avec une phrase de passe, pas besoin d’une autre clef. Mais il faut la chiffrer comme si c’était un fichier « classique » (avec gpg --encrypt), au lieu de simplement se reposer sur le chiffrement produit par --export-secret-key.
Si par « il » tu veux dire GnuPG, ici GnuPG ne fait que suivre le standard OpenPGP. La faille se trouve dans le standard lui-même, pas dans les implémentations.
Du coup la question devient : Pourquoi le standard OpenPGP utilise-t-il, pour l’échange d’une clef privée, un format spécifique (le Secret-Key Packet Format, RFC 4880 §5.5.3) au lieu de simplement mettre la clef privée dans un Symmetrically Encrypted Integrity Protected Data Packet (le format utilisé entre autres pour l’échange de messages protégés par une phrase de passe, RFC 4880 §5.13), qui offrirait toutes les garanties nécessaires ?
Seuls les auteurs du standard peuvent répondre à cette question, mais si je devais deviner je dirais que c’est lié à l’âge du standard (il date du début des années 1990) et résulte d’un soucis de performance (à l’époque il était pertinent de ne vouloir chiffrer que le strict minimum d’octets, les opérations cryptographiques étant coûteuses) et de manque de considération pour les attaques actives (un problème général de la cryptographie des années 1990 ; SSL en a largement souffert aussi).
Quel est le problème avec le Secret-Key Packet Format ? Ce format contient à la fois les parties publiques et secrètes d’une clef OpenPGP, mais seule la partie secrète est chiffrée avec la phrase de passe. La partie publique est en clair. Après tout, la partie publique, comme son nom l’indique, est, euh, publique, donc pourquoi faudrait-il la chiffrer ? L’attaquant peut l’obtenir directement depuis les serveurs de clefs de toute façon, on ne gagne rien à chiffrer cette partie-là, pas vrai ?
Si on ne considère que les attaques passives, c’est vrai, et le format protège toujours efficacement contre ces attaques. Pas d’inquiétude à avoir si vous avez laissé votre clef au format Secret-Key Packet (tel que généré par gpg --export-secret-key) quelque part où Eve a pu mettre la main dessus : elle n’aura pas plus de chance qu’hier d’obtenir une forme utilisable de votre clef privée (sous réserve d’avoir utilisé une phrase de passe solide évidemment).
Par contre, si votre clef au format Secret-Key Packet tombe entre les mains de l’attaquant actif Mallory, rien ne va plus. Sans avoir besoin de déchiffrer la partie secrète (ce qu’il ne peut pas faire), Mallory peut modifier à sa guise le contenu de la partie publique, qui n’a aucune protection. S’il peut ensuite faire en sorte que vous utilisiez sa version modifiée de votre clef,¹ il vous rend vulnérable à toutes sortes d’attaques la prochaine fois que vous déchiffrerez ou signerez un message.²
La contre-mesure la plus simple et la plus immédiatement accessible pour les utilisateurs de GnuPG est de simplement s’assurer que l’intégralité du Secret-Key Packet est chiffré (d’où la commande donnée dans mon message précédent).
La contre-mesure définitive a déjà été ajouté au brouillon de la prochaine version du standard OpenPGP et consistera, non pas à chiffrer la partie publique de la clef, mais à ajouter un mécanisme de vérification de l’intégrité de celle-ci, de sorte qu’aucune modification ne puisse passer inaperçue.
¹ Comment Mallory pourrait-il vous faire utiliser sa copie modifiée de votre propre clef ? On peut imaginer plusieurs scénarios. Par exemple, vous avez stockée une copie de sauvegarde de votre clef privée quelque part en ligne (sans craindre pour sa sécurité puisque vous avez utilisé une phrase de passe forte), puis vient le jour où vous avez besoin de restaurer votre clef depuis cette sauvegarde, sans vous douter qu’entre-temps Mallory avait eu accès à cet espace de stockage en ligne, et n’attendait que le jour où vous récupéreriez votre sauvegarde (Mallory est notoirement très patient). Plus réalistement, certains services de messagerie chiffrée aujourd‘hui reposent sur le fait que la clef privée est en permanence stockée sur les serveurs du fournisseur plutôt que sur votre propre machine ; c’est le cas par exemple de ProtonMail, qui était précisément vulnérable au type d’attaque présenté ici (ProtonMail a implémenté des contre-mesures après une responsible disclosure des auteurs du papier).
² Les attaques rendues possibles par des modifications astucieuses de la partie publique d’une clef dépendent du type de clef (DSA, RSA, ECDSA…). Dans le pire des cas, elles peuvent aller jusqu’à permettre l’extraction complète de la clef privée à partir de seulement une signature émise par la clef modifiée.
c’est le cas par exemple de ProtonMail, qui était précisément vulnérable au type d’attaque présenté ici
Pas compris : de ce que je comprend de ton commentaire est qu'il faut remplacer du contenu. J'imagine que ProtonMail ne permet pas à n'importe qui de modifier, seulement à l'utilisateur authentifié, du coup où était la vulnérabilité?
Le site parle du patch de la version JS mais j'avoue ne rien comprendre sur le lien entre les 2 (note pour moi-même : ne pas trop toucher à du chiffrement, je n'y comprend pas grand chose :) )
ProtonMail a implémenté des contre-mesures
D'après le site c'est "je MAJ OpenPGP.js", ils n'ont pas l'air de s'être trop foulé, plutôt OpenPGP.js qui a impléménté et eux ont appliqué le patch fourni, non?
J'imagine que ProtonMail ne permet pas à n'importe qui de modifier, seulement à l'utilisateur authentifié, du coup où était la vulnérabilité?
Une des promesses de ProtonMail est que, même s’ils stockent ta clef privée chez eux, sans la phrase de passe (qu’ils ne connaissent pas) ils ne peuvent pas s’en servir pour déchiffrer tes messages passés ou futurs et donc que tu n’as pas à leur faire confiance pour :
ne pas être malveillant : même si les administrateurs de ProtonMail voulaient déchiffrer tes messages, ils ne le pourraient pas¹ ;
céder aux injonctions judiciaires : même si un juge leur ordonnait de révéler le contenu de tes messages, ils ne le pourraient pas¹ (ce n’est rien d’autre qu’un cas particulier du précédent) ;
avoir des serveurs sécurisés : même si un attaquant parvenait à pénétrer leurs serveurs, ledit attaquant n’aurait pas plus accès au texte de tes messages que les administrateurs eux-mêmes.¹
Cette promesse repose sur le fait que certes, ta clef privée est chez eux, mais elle est chiffrée et ProtonMail ne connaît pas la phrase de passe.
L’attaque décrite ici fait tomber cette promesse (qui était déjà bien bancale, certes¹). Même sans la phrase de passe, quiconque a accès en écriture à la clef privée sur les serveurs de ProtonMail peut compromettre la sécurité de tes messages.
D'après le site c'est "je MAJ OpenPGP.js", ils n'ont pas l'air de s'être trop foulé, plutôt OpenPGP.js qui a impléménté et eux ont appliqué le patch fourni, non?
ProtonMail est un des principaux développeurs de OpenPGP.js. ;)
¹ Ça c’est l’argument commercial de ProtonMail, hein. En réalité, vu que le code Javascript qui réalise les opérations cryptographiques dans le navigateur du client vient des serveurs de ProtonMail, il faut tout de même leur faire confiance pour ne pas t’envoyer une version qui exfiltre ta phrase de passe…
Ça c’est l’argument commercial de ProtonMail, hein. En réalité, vu que le code Javascript qui réalise les opérations cryptographiques dans le navigateur du client vient des serveurs de ProtonMail, il faut tout de même leur faire confiance pour ne pas t’envoyer une version qui exfiltre ta phrase de passe…
Sachant que c'est quand même un truc détectable côté client (bon, si ça ne te vise que toi, je doute que tu vérifie le code envoyé à chaque fois, mais ça fait une sacrée attaque pour viser un particulier, du coup, si ça vise plusieurs personnes, ça peut se détecter).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Des gouvernements sont prêts à payer des millions pour accéder à un particulier précis, donc ça ce n'est pas cher et c'est la faille connue de ProntonMail depuis le début.
merci goutted pour l'explication, très clair pour moi maintenant mais ce petit "sauf" me fait penser que c'est assez cosmétique du coup car certes ils (et d'autres) ne peuvent plus modifier le stockage mais peuvent toujours modifier le code envoyé pour faire la même chose, du moins en JS.
Du coup, il y a d'autres solutions moins cher et moins visibles pour les gouvernements. Donc bon, ce n'est pas non. Et il y a des solutions de contournements pour ceux qui sont visé par les gouvernements (utiliser le bridge avec une version contrôlable, vérifier que la version openpgp.js de protonmail soit bien la même que celle en ligne…).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Le fait est que ProtonMail axe une bonne partie de son marketing sur le fait qu’il leur serait impossible (mathématiquement impossible, même !) de lire les messages de leurs utilisateurs, alors que c’est juste faux. Ils seraient complètement, absolument en mesure de le faire s’ils le décidaient.
Je serais beaucoup moins critique à l’égard de ProtonMail s’ils ne mettaient pas tant l’accent sur cette soi-disant impossibilité. Je trouve difficile de faire confiance à quelqu’un qui ment, personnellement…
Je n'ai pas trop suivi leur campagne marketing, mais dans leur threat model, c'est bien décrit que si quelqu'un a accès aux serveurs, il peut modifier le code envoyé (dans unauthorized backdoor (ce qui indique qu'il y en a des autorisées, je suppose) https://protonmail.com/blog/protonmail-threat-model/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
En réalité, vu que le code Javascript qui réalise les opérations cryptographiques dans le navigateur du client vient des serveurs de ProtonMail, il faut tout de même leur faire confiance pour ne pas t’envoyer une version qui exfiltre ta phrase de passe…
C'est un problème que rencontrent toutes les solutions avec du chiffrement de bout en bout qui offrent une appli web (protonmail, matrix, bitwarden, etc.) : si un pirate prend le contrôle d'un serveur qui te sert l'app (ou se place en homme du milieu entre le client et le serveur), il peut servir un JS vérolé et récupéré les secrets.
Sais-tu si des gens commencent à travailler à traiter correctement cette difficulté ?
A priori, il serait assez simple de signer le code JS avec GPG, puis de "pinner" une association clé GPG / site distant pour indiquer aux les navigateurs de n'exécuter du code depuis ce site X que s'il est correctement signé, mais je n'ai pas connaissance de réflexion ou de début de mise en œuvre.
(Se pose bien évidemment la question de la distribution de l'info "tel site requiert telle clé publique", et on retombe soit sur la PKI du web avec tous ses défauts, soit sur du TOFU, soit sur des listes préchargées, soit une autre solution à inventer).
Sais-tu si des gens commencent à travailler à traiter correctement cette difficulté ?
Aucune idée. Le truc le plus récent que je connaisse date du début du siècle, je doute fort que ça fonctionne encore.
Le truc qui s’en rapproche le plus, aujourd’hui et à ma connaissance, c’est le standard W3C Subresource Integrity, qui permet d’indiquer qu’un script Javascript doit avoir un certain condensat pour être autorisé à s’exécuter :
Mais comme le condensat est fourni par le même site qui demande l’exécution du code Javascript, ça ne protège absolument pas contre le cas de figure où c’est ce site qui est malveillant (si c’était une signature et non un condensat, ça protégerait au moins contre le cas où un pirate prend le contrôle du serveur… à condition que la clef de signature ne soit pas sur le même serveur, sinon le pirate en prend le contrôle aussi et peut ré-émettre des signatures à sa guise).
C’est surtout conçu pour les cas où les fichiers Javascript sont hébergés ailleurs que sur le serveur du site, typiquement sur un CDN. Ça protège contre un CDN malveillant ou contre une attaque entre le CDN et le client, mais pas contre un serveur malveillant.
# Bref résumé
Posté par gouttegd . Évalué à 10.
Si vous exportez votre clef privée OpenPGP (avec
gpg --export-secret-key), même protégée par une phrase de passe, un attaquant qui met la main sur la clef ainsi exportée peut la modifier et la compromettre, vous exposant ainsi à de possibles attaques ultérieures si vous ré-importez la clef modifiée.Si vous avez stockée votre clef privée (au format OpenPGP standard telle que généré par
--export-secret-key) sur un support qui a potentiellement été hors de votre contrôle (a fortiori par exemple si vous l‘avez stockée en ligne), ne la ré-utilisez pas aveuglément : vérifiez son empreinte au moment de la ré-importer.[^] # Re: Bref résumé
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6.
Merci.
En fait, de toute façon, il vaut mieux éviter de stocker les clés en ligne non ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Bref résumé
Posté par gouttegd . Évalué à 10.
Il vaut mieux éviter, mais une des promesses du format OpenPGP était que tant que la clef est exportée avec une phrase de passe suffisamment forte, il devait tout de même être possible de le faire sans craindre de s’exposer à une compromission.
Ce que montre cette attaque est que cette promesse en particulier n’est pas tenue. Il est donc désormais formellement déconseillé de stocker une clef privée dans le format d’échange OpenPGP sur un support non-sûr, si on l‘intention de ré-utiliser la clef depuis ce même support, à moins de prendre des précautions supplémentaires.
Les précautions supplémentaires pouvant consister par exemple à rajouter une couche de chiffrement par-dessus le chiffrement déjà intégré au format d’échange, ou au minium une couche de vérification d’intégrité.
[^] # Re: Bref résumé
Posté par Misc (site web personnel) . Évalué à 3.
Donc il faut chiffrer sa clé gpg avec une autre clé gpg comme protection, malin.
[^] # Re: Bref résumé
Posté par gouttegd . Évalué à 8.
Non, tu peux la chiffrer avec une phrase de passe, pas besoin d’une autre clef. Mais il faut la chiffrer comme si c’était un fichier « classique » (avec
gpg --encrypt), au lieu de simplement se reposer sur le chiffrement produit par--export-secret-key.C’est-à-dire, faire par exemple :
au lieu de simplement :
[^] # Re: Bref résumé
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Pourquoi à la base, il ne reutilisait pas leur chiffrement classique ? Pourquoi voir un deuxième mécanisme ?
"La première sécurité est la liberté"
[^] # Re: Bref résumé
Posté par gouttegd . Évalué à 9.
Si par « il » tu veux dire GnuPG, ici GnuPG ne fait que suivre le standard OpenPGP. La faille se trouve dans le standard lui-même, pas dans les implémentations.
Du coup la question devient : Pourquoi le standard OpenPGP utilise-t-il, pour l’échange d’une clef privée, un format spécifique (le Secret-Key Packet Format, RFC 4880 §5.5.3) au lieu de simplement mettre la clef privée dans un Symmetrically Encrypted Integrity Protected Data Packet (le format utilisé entre autres pour l’échange de messages protégés par une phrase de passe, RFC 4880 §5.13), qui offrirait toutes les garanties nécessaires ?
Seuls les auteurs du standard peuvent répondre à cette question, mais si je devais deviner je dirais que c’est lié à l’âge du standard (il date du début des années 1990) et résulte d’un soucis de performance (à l’époque il était pertinent de ne vouloir chiffrer que le strict minimum d’octets, les opérations cryptographiques étant coûteuses) et de manque de considération pour les attaques actives (un problème général de la cryptographie des années 1990 ; SSL en a largement souffert aussi).
Quel est le problème avec le Secret-Key Packet Format ? Ce format contient à la fois les parties publiques et secrètes d’une clef OpenPGP, mais seule la partie secrète est chiffrée avec la phrase de passe. La partie publique est en clair. Après tout, la partie publique, comme son nom l’indique, est, euh, publique, donc pourquoi faudrait-il la chiffrer ? L’attaquant peut l’obtenir directement depuis les serveurs de clefs de toute façon, on ne gagne rien à chiffrer cette partie-là, pas vrai ?
Si on ne considère que les attaques passives, c’est vrai, et le format protège toujours efficacement contre ces attaques. Pas d’inquiétude à avoir si vous avez laissé votre clef au format Secret-Key Packet (tel que généré par
gpg --export-secret-key) quelque part où Eve a pu mettre la main dessus : elle n’aura pas plus de chance qu’hier d’obtenir une forme utilisable de votre clef privée (sous réserve d’avoir utilisé une phrase de passe solide évidemment).Par contre, si votre clef au format Secret-Key Packet tombe entre les mains de l’attaquant actif Mallory, rien ne va plus. Sans avoir besoin de déchiffrer la partie secrète (ce qu’il ne peut pas faire), Mallory peut modifier à sa guise le contenu de la partie publique, qui n’a aucune protection. S’il peut ensuite faire en sorte que vous utilisiez sa version modifiée de votre clef,¹ il vous rend vulnérable à toutes sortes d’attaques la prochaine fois que vous déchiffrerez ou signerez un message.²
La contre-mesure la plus simple et la plus immédiatement accessible pour les utilisateurs de GnuPG est de simplement s’assurer que l’intégralité du Secret-Key Packet est chiffré (d’où la commande donnée dans mon message précédent).
La contre-mesure définitive a déjà été ajouté au brouillon de la prochaine version du standard OpenPGP et consistera, non pas à chiffrer la partie publique de la clef, mais à ajouter un mécanisme de vérification de l’intégrité de celle-ci, de sorte qu’aucune modification ne puisse passer inaperçue.
¹ Comment Mallory pourrait-il vous faire utiliser sa copie modifiée de votre propre clef ? On peut imaginer plusieurs scénarios. Par exemple, vous avez stockée une copie de sauvegarde de votre clef privée quelque part en ligne (sans craindre pour sa sécurité puisque vous avez utilisé une phrase de passe forte), puis vient le jour où vous avez besoin de restaurer votre clef depuis cette sauvegarde, sans vous douter qu’entre-temps Mallory avait eu accès à cet espace de stockage en ligne, et n’attendait que le jour où vous récupéreriez votre sauvegarde (Mallory est notoirement très patient). Plus réalistement, certains services de messagerie chiffrée aujourd‘hui reposent sur le fait que la clef privée est en permanence stockée sur les serveurs du fournisseur plutôt que sur votre propre machine ; c’est le cas par exemple de ProtonMail, qui était précisément vulnérable au type d’attaque présenté ici (ProtonMail a implémenté des contre-mesures après une responsible disclosure des auteurs du papier).
² Les attaques rendues possibles par des modifications astucieuses de la partie publique d’une clef dépendent du type de clef (DSA, RSA, ECDSA…). Dans le pire des cas, elles peuvent aller jusqu’à permettre l’extraction complète de la clef privée à partir de seulement une signature émise par la clef modifiée.
[^] # Re: Bref résumé
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 07 mai 2022 à 18:13.
Pas compris : de ce que je comprend de ton commentaire est qu'il faut remplacer du contenu. J'imagine que ProtonMail ne permet pas à n'importe qui de modifier, seulement à l'utilisateur authentifié, du coup où était la vulnérabilité?
Le site parle du patch de la version JS mais j'avoue ne rien comprendre sur le lien entre les 2 (note pour moi-même : ne pas trop toucher à du chiffrement, je n'y comprend pas grand chose :) )
D'après le site c'est "je MAJ OpenPGP.js", ils n'ont pas l'air de s'être trop foulé, plutôt OpenPGP.js qui a impléménté et eux ont appliqué le patch fourni, non?
[^] # Re: Bref résumé
Posté par gouttegd . Évalué à 5.
Une des promesses de ProtonMail est que, même s’ils stockent ta clef privée chez eux, sans la phrase de passe (qu’ils ne connaissent pas) ils ne peuvent pas s’en servir pour déchiffrer tes messages passés ou futurs et donc que tu n’as pas à leur faire confiance pour :
ne pas être malveillant : même si les administrateurs de ProtonMail voulaient déchiffrer tes messages, ils ne le pourraient pas¹ ;
céder aux injonctions judiciaires : même si un juge leur ordonnait de révéler le contenu de tes messages, ils ne le pourraient pas¹ (ce n’est rien d’autre qu’un cas particulier du précédent) ;
avoir des serveurs sécurisés : même si un attaquant parvenait à pénétrer leurs serveurs, ledit attaquant n’aurait pas plus accès au texte de tes messages que les administrateurs eux-mêmes.¹
Cette promesse repose sur le fait que certes, ta clef privée est chez eux, mais elle est chiffrée et ProtonMail ne connaît pas la phrase de passe.
L’attaque décrite ici fait tomber cette promesse (qui était déjà bien bancale, certes¹). Même sans la phrase de passe, quiconque a accès en écriture à la clef privée sur les serveurs de ProtonMail peut compromettre la sécurité de tes messages.
ProtonMail est un des principaux développeurs de OpenPGP.js. ;)
¹ Ça c’est l’argument commercial de ProtonMail, hein. En réalité, vu que le code Javascript qui réalise les opérations cryptographiques dans le navigateur du client vient des serveurs de ProtonMail, il faut tout de même leur faire confiance pour ne pas t’envoyer une version qui exfiltre ta phrase de passe…
[^] # Re: Bref résumé
Posté par claudex . Évalué à 3.
Sachant que c'est quand même un truc détectable côté client (bon, si ça ne te vise que toi, je doute que tu vérifie le code envoyé à chaque fois, mais ça fait une sacrée attaque pour viser un particulier, du coup, si ça vise plusieurs personnes, ça peut se détecter).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bref résumé
Posté par Zenitram (site web personnel) . Évalué à 2.
Des gouvernements sont prêts à payer des millions pour accéder à un particulier précis, donc ça ce n'est pas cher et c'est la faille connue de ProntonMail depuis le début.
merci goutted pour l'explication, très clair pour moi maintenant mais ce petit "sauf" me fait penser que c'est assez cosmétique du coup car certes ils (et d'autres) ne peuvent plus modifier le stockage mais peuvent toujours modifier le code envoyé pour faire la même chose, du moins en JS.
[^] # Re: Bref résumé
Posté par claudex . Évalué à 3.
Du coup, il y a d'autres solutions moins cher et moins visibles pour les gouvernements. Donc bon, ce n'est pas non. Et il y a des solutions de contournements pour ceux qui sont visé par les gouvernements (utiliser le bridge avec une version contrôlable, vérifier que la version openpgp.js de protonmail soit bien la même que celle en ligne…).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bref résumé
Posté par gouttegd . Évalué à 5.
Le fait est que ProtonMail axe une bonne partie de son marketing sur le fait qu’il leur serait impossible (mathématiquement impossible, même !) de lire les messages de leurs utilisateurs, alors que c’est juste faux. Ils seraient complètement, absolument en mesure de le faire s’ils le décidaient.
Je serais beaucoup moins critique à l’égard de ProtonMail s’ils ne mettaient pas tant l’accent sur cette soi-disant impossibilité. Je trouve difficile de faire confiance à quelqu’un qui ment, personnellement…
[^] # Re: Bref résumé
Posté par Pol' uX (site web personnel) . Évalué à 3.
Surtout s'il dit qu'il ment, il faut se méfier, dès fois que ce ne serait pas vrai ! :)
Adhérer à l'April, ça vous tente ?
[^] # Re: Bref résumé
Posté par claudex . Évalué à 4.
Je n'ai pas trop suivi leur campagne marketing, mais dans leur threat model, c'est bien décrit que si quelqu'un a accès aux serveurs, il peut modifier le code envoyé (dans unauthorized backdoor (ce qui indique qu'il y en a des autorisées, je suppose) https://protonmail.com/blog/protonmail-threat-model/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Bref résumé
Posté par Samuel (site web personnel) . Évalué à 2.
C'est un problème que rencontrent toutes les solutions avec du chiffrement de bout en bout qui offrent une appli web (protonmail, matrix, bitwarden, etc.) : si un pirate prend le contrôle d'un serveur qui te sert l'app (ou se place en homme du milieu entre le client et le serveur), il peut servir un JS vérolé et récupéré les secrets.
Sais-tu si des gens commencent à travailler à traiter correctement cette difficulté ?
A priori, il serait assez simple de signer le code JS avec GPG, puis de "pinner" une association clé GPG / site distant pour indiquer aux les navigateurs de n'exécuter du code depuis ce site X que s'il est correctement signé, mais je n'ai pas connaissance de réflexion ou de début de mise en œuvre.
(Se pose bien évidemment la question de la distribution de l'info "tel site requiert telle clé publique", et on retombe soit sur la PKI du web avec tous ses défauts, soit sur du TOFU, soit sur des listes préchargées, soit une autre solution à inventer).
[^] # Re: Bref résumé
Posté par gouttegd . Évalué à 6.
Aucune idée. Le truc le plus récent que je connaisse date du début du siècle, je doute fort que ça fonctionne encore.
Le truc qui s’en rapproche le plus, aujourd’hui et à ma connaissance, c’est le standard W3C Subresource Integrity, qui permet d’indiquer qu’un script Javascript doit avoir un certain condensat pour être autorisé à s’exécuter :
Mais comme le condensat est fourni par le même site qui demande l’exécution du code Javascript, ça ne protège absolument pas contre le cas de figure où c’est ce site qui est malveillant (si c’était une signature et non un condensat, ça protégerait au moins contre le cas où un pirate prend le contrôle du serveur… à condition que la clef de signature ne soit pas sur le même serveur, sinon le pirate en prend le contrôle aussi et peut ré-émettre des signatures à sa guise).
C’est surtout conçu pour les cas où les fichiers Javascript sont hébergés ailleurs que sur le serveur du site, typiquement sur un CDN. Ça protège contre un CDN malveillant ou contre une attaque entre le CDN et le client, mais pas contre un serveur malveillant.
[^] # Re: Bref résumé
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pourquoi à la base, il ne reutilisait pas leur chiffrement classique ? Pourquoi voir un deuxième mécanisme ?
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.