Plusieurs chercheurs ont lancé l'alerte : ils auraient découvert des faiblesses dans OpenPGP et S/MIME. Certains clients exploitant ces protocoles de chiffrement pour emails comporteraient des failles de sécurité. Les courriels chiffrés pourraient ainsi être lus, y compris les anciens. Ces conclusions sont cependant remises en question.

Si l’affaire fait grand bruit, c’est aussi parce que l’Electronic Frontier Foundation (EFF) y est allée de ses conseils, pour le moins radicaux : désactiver temporairement les extensions des clients email, comme Enigmail sur Thunderbird, GPGTools pour Apple Mail et Gpg4Win sur Outlook, avec une marche à suivre détaillée pour chacun.

Elle pousse également Signal comme solution de secours, même si une messagerie instantanée ne remplit pas exactement les mêmes fonctions. Entre temps, les chercheurs ont publié les détails avec une journée d'avance sur le calendrier annoncé, poussés par des tombereaux de critiques et les vives réactions des développeurs des outils ciblés.

• Voir le compte-rendu des chercheurs sur les failles EFAIL

Les éternels problèmes de mails au format HTML

Les failles, rassemblées sous l’appellation EFAIL, ne peuvent être exploitées que pour des emails en HTML. Tous ceux n’utilisant que le texte brut sont donc épargnés. Le ou les pirates doivent posséder au moins un email chiffré, un détail qui a toute son importance puisqu'il leur faudra s’introduire sur le serveur ou le terminal pour dérober les données.

Il y a deux formes d'attaques. La principale s’en prend directement aux clients email, tout particulièrement ceux d’Apple dans iOS et macOS, ainsi qu'Outlook et Thunderbird. Le pirate crée un nouveau courrier contenant trois parties :

• Une première partie du corps HTML contenant une balise image, dont la source ne possède pas de guillemets de fermeture
• Le message chiffré par OpenPGP ou S/MIME (récupéré par le pirate)
• Une dernière partie de corps HTML contenant la fermeture de guillemets

Le message chiffré est donc contenu dans la source de l’image. Quand la victime reçoit le courrier, le client interprète le code HTML. Les espaces et autres caractères spéciaux sont automatiquement convertis au passage, et une requête pour l’image est émise. Ladite requête contient le texte en clair, interprété comme l’adresse de l’image.

Selon les chercheurs, ce type d’attaque devrait fonctionner pour l’ensemble des clients mail capables de gérer OpenPGP ou S/MIME. Elle est décrite comme une « exfiltration directe ».

L’autre méthode d’attaque, nommée « CBC/CFB gadget », est plus complexe. Elle se base directement sur les méthodes de chiffrement par enchainement des blocs ou à rétroaction. Elle consiste à insérer une balise image, constituant un bloc unique dans le corps du mail HTML, pouvant alors exfiltrer son propre texte à l’ouverture du mail.

S/MIME pour l'instant plus vulnérable qu'OpenPGP

Les chercheurs précisent cependant que les degrés d’efficacité ne sont pas les mêmes. S/MIME semble ainsi nettement plus vulnérable, une seule tentative étant parvenue à obtenir le contenu en clair de 500 courriers chiffrés.

Avec OpenPGP, le taux de réussite n’était plus que d’environ 33 %, car la méthode utilisée (CFB) est précédée d’une compression des données avant leur chiffrement. Le processus requérant du pirate qu’il connaisse le nombre exact d’octets de texte plein, l’opération est rendue plus délicate. 

Dans le document complet de recherche, un tableau a d'ailleurs été publié pour résumer la situation pour les clients et webmails. On peut y voir très clairement la différence entre S/MIME et PGP. Mail d'Apple apparaît comme vulnérable à toutes les variantes, tandis que les versions récentes d'Outlook ne le sont qu'avec S/MIME.

Côté webmails, on remarque le cas de Gmail, vulnérable sur S/MIME et ne supportant pas PGP :

Ce qui n’empêche pas les découvreurs des failles d’avertir que le vecteur d’attaque n’en est qu’à ses balbutiements. D’autres travaux pourraient conduire à plus une grande efficacité, donc à un meilleur taux de réussite.

Des solutions à plus ou moins court terme

Après leur descriptif, les chercheurs donnent une série de solutions. Elles vont du court au long terme, selon le temps demandé par les pistes proposées.

Dans l’immédiat, deux recommandations peuvent être « facilement » mises en place. La première, largement mise en avant par l’EFF, est de désactiver tous les composants intégrés aux clients email pour leur faire gérer des emails chiffrés en S/MIME ou OpenPGP. Ce qui ne veut pas dire que les utilisateurs doivent se passer de ces méthodes.

Les chercheurs précisent en effet qu’il faudrait, idéalement, que les messages chiffrés soient gérés par une solution séparée. L’idée est de ne plus laisser le client email s’en occuper, puisque c’est dans les interactions de ce dernier avec le composant intégré que résident les problèmes.

L’autre solution, pouvant remplacer la précédente, est de désactiver complètement les emails en HTML pour basculer sur du texte brut uniquement. La consigne doit alors être passée à l’ensemble des personnes concernées à toutes celles avec qui elles communiquent. La méthode est plus simple pour l’utilisation au quotidien, mais au prix d’une communication potentiellement lourde.

À plus longue échéance, les chercheurs préviennent que les clients email devront être mis à jour. Les brèches qu’ils comportent sont, selon eux, présentes depuis dix ans. Enfin, et ce sera le plus long, les standards S/MIME et OpenPGP devraient eux-mêmes être travaillés de manière que ces failles ne puissent plus être utilisées. 

Vague de communications autour des clients et webmails

Les explications des chercheurs n'ont pas convaincu tout le monde. Autour de cette communication s'est presque organisée une « contre-vague », portée par les éditeurs de certaines solutions logiciels ou de webmails.

C'est particulièrement le cas de GnuPG, qui expliquait dans un tweet hier que les chercheurs s'étaient concentrés sur « les clients mail qui ne vérifient pas les erreurs de déchiffrement et suivent les liens dans les courriers en HTML ». L'équipe insiste : « la vulnérabilité réside dans les clients mail et non dans les protocoles ». Avant d'ajouter : « En fait, OpenPGP est immunisé s'il est utilisé correctement, alors que S/MIME n'a déployé aucune atténuation ».

Le responsable de GnuPG, Werner Koch, a même livré les détails en avance suite aux billets de blog de l'EFF. Il a également pointé que le problème était connu dès 1999 et qu'une solution avait été mise en place.

Il suffit qu'OpenPGP soit implémenté de la bonne manière, en vérifiant les erreurs, pour que la solution l'utilisant ne soit pas vulnérable. Les communications de Mailpile et ProtonMail vont dans ce sens. Le premier explique justement que les messages d'erreurs de GnuPG sont pris en compte. Mieux, le contenu HTML n'est pas affiché par défaut.

Même son de cloche pour ProtonMail, qui précise en outre que tout utilisateur de sa bibliothèque OpenPGPjs est tranquille « tant que les réglages par défaut n'ont pas été modifiés ». Une analyse approfondie du document des chercheurs a confirmé cet avis. Chez Enigmail, on pointe simplement que la dernière version n'est pas concernée par le souci.

Le vrai problème soulevé par les chercheurs est la sécurité générale entourant les emails. Ces derniers n'ont, de toute façon, jamais été pensés comme une solution sécurisée de communication. Les outils permettant de protéger ces échanges sont donc en première ligne. Une thématique exprimée notamment par le chercheur Matt Blaze sur Twitter.

Les avis divergent largement sur l'interprétation à donner aux travaux sur EFAIL. Les développeurs et éditeurs concernés insistent largement sur l'aspect « pas si grave » du problème dès lors que l'implémentation d'OpenPGP a été faite correctement (S/MIME est encore une fois beaucoup plus concerné). D'autres, comme le cryptologue Philippo Valsorda, confirment que les chercheurs ont bien déterré un lièvre, et que les protocoles pourraient être améliorés, sans pour autant parler de failles.

La méthode de l'équipe reste pourtant critiquée. Elle n'aurait pas contacté les concepteurs des outils visés avant de s'épancher auprès de l'EFF, à l'encontre des règles de « divulgation responsable », qui consistent à chercher une solution en privé avant toute publication.

La rétention des détails pendant une journée, après le choc du message de l'EFF, a aussi été perçue comme une tentative de « faire le buzz » aux dépens d'outils connus.