Récemment, il y a eu une résurgence d’une vieille idée de sécurité selon laquelle « le courriel en texte brut est le seul courriel sûr ». La campagne du ruban ASCII de 1998 portait précisément sur cela. Il a fermé ses portes en 2013 alors qu’il tombait dans l’oreille d’un sourd.
Est-il temps de ramener cette idée et peut-être même d’en faire un adage respecté? Est-ce même possible compte tenu de la richesse du contenu des courriels de nos jours?
Bien qu’il y ait plusieurs avantages à le faire, et oui, cela renforcera considérablement la sécurité, cela ne résoudra pas tous les problèmes de sécurité des courriels. Le courriel HTML a, peut-être à juste titre, été comparé à un champ de mines. Mais il faut toujours garder à l’esprit que le problème fondamental du courriel est celui de l’authentification. L’expéditeur du message est-il celui que vous pensez? Les courriels en texte brut ont toujours ce problème. On peut toujours rédiger des messages d’hameçonnage en texte brut (notre explication DMARC montre plusieurs exemples où cela est fait). Répondre à un expéditeur n’implique pas de cliquer sur des liens suspects, mais répondez-vous vraiment à qui vous pensez être? De même, le téléchargement et l’exécution de pièces jointes dans un message peuvent être effectués avec des courriels en texte brut, car les pièces jointes sont simplement une partie MIME. Les courriels en texte brut prennent en charge les pièces jointes.
Le problème de l’authentification est résolu par des idées comme SPF, DKIM et DMARC, mais tant qu’elles ne seront pas correctement mises en œuvre par les expéditeurs et appliquées par les destinataires, le problème persistera. De plus, même elles ne traitent pas de tous les vecteurs d’attaque relatifs à l’authentification de l’expéditeur. Les agents de transfert de courrier les combinent souvent avec des listes noires en temps réel qui bloquent les courriels en fonction de l’adresse IP de l’expéditeur. La réputation et l’authenticité de l’expéditeur sont à l’origine du problème.
Les courriels riches en HTML fournissent plusieurs vecteurs d’attaque à exploiter et la suppression de HTML les éliminerait certainement. Tout, du masquage intelligent du texte légitime au contournement des filtres anti-pourriel à l’aide d’astuces de formatage, aux messages sophistiqués compatibles CSS qui changent d’URL après avoir été livrés dans votre boîte de réception , serait éliminé. Les courriels formatés pour donner l’impression d’être ceux de votre institution bancaire demandant un changement de mot de passe seraient éliminés. Mes techniques de programmation de vie pour attraper des exploits seraient facilitées. Mais comme nous l’avons vu avec la campagne du ruban ASCII, personne n’a écouté. Apparemment, nous aimons nos courriels riches en HTML, mais en avons-nous vraiment besoin?
Imaginez un monde où une politique de courriel en texte brut est appliquée. D’un point de vue fonctionnel, est-ce que vous ou votre organisation en souffririez vraiment? La grande majorité des courriels sollicités ne sont généralement que des conversations entre un groupe de personnes. Dans les environnements de bureau où des réunions doivent être planifiées, Outlook n’est pas la seule option. Les réunions peuvent être organisées à l’aide d’outils indépendants du courriel. Les calendriers peuvent exister et existent indépendamment du courriel. Les services de marketing souffriraient sans doute le plus, car ils bénéficient le plus des courriels riches en HTML qui contiennent des analyses fournissant une rétroaction utile sur la lecture des messages. De même, les bulletins auraient l’air plus simples et nécessiteraient de copier-coller des liens. Mais pour être honnête, sont-ils si différents des pourriels? J’ai programmé des filtres anti-pourriel pour détecter les infolettres et les messages de marketing.
Je crois que nous pourrions vivre dans un tel monde, mais cela nécessiterait l’utilisation de plusieurs outils, et nous savons que la plupart des gens ne veulent généralement pas cela. Les gens adorent cet outil universel qui fait tout. Plusieurs tentatives ont été faites pour remplacer le courriel par de tels outils. Vous vous souvenez de Google Wave? La réalité est que nous avons transformé le courriel en quelque chose pour lequel il n’a jamais été conçu et que nous continuerons à l’utiliser. Bien que j’aime cette résurgence des courriels en texte brut et que je crois que, combinée à des mécanismes d’authentification modernes, elle augmenterait considérablement la sécurité, je ne crois pas que ce soit un objectif atteignable. Se concentrer sur une protection plus forte des courriels continuera probablement d’être la seule vraie solution ici, avec une solide défense contre les URL malveillantes et les pièces jointes, la détection et le filtrage des pourriels, la protection contre les tactiques d’hameçonnage et fournir un moyen plus viable de protéger les courriels et leurs utilisateurs, que ce soit en txt ou en html.
