EFAIL : des failles de chiffrement des emails dans certains clients créent la panique

EFAIL : des failles de chiffrement des emails dans certains clients créent la panique

Oui ! Non ! Si !

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

16/05/2018 8 minutes
51

EFAIL : des failles de chiffrement des emails dans certains clients créent la panique

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.

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 :

S/MIME PGP failles efail

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.

51

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les éternels problèmes de mails au format HTML

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

Des solutions à plus ou moins court terme

Vague de communications autour des clients et webmails

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (51)


Pour ma part j’ai tout switché sur du texte brut.


Moi, j’envoie plus que des courriers par La Poste.

La confidentialité est mieux garantie


Je ne sais pas tu es ironique, mais c’est sans doute le cas. La protection du courrier peut être plus sécurisée que l’informatique.

(encore mieux, envoyer un courrier chiffré par gpg)


Le problème avec la poste c’est que c’est de l’UDP et y a clairement de la perte de paquets….








barbach a écrit :



Pour ma part j’ai tout switché sur du texte brut.





Perso, j’ai toujours été en texte brut, les emails en html c’est le mal <img data-src=" />



Mais du coup, si le client est configuré pour ne pas aller chercher les images en suivant les URL, c’est safe?



Les mails HTML, ca a toujours été horrible de toutes manières.

Avant c’était pour les yeux, Aujourdhui c’est pour la sécurité :)








Leum a écrit :



Le problème avec la poste c’est que c’est de l’UDP et y a clairement de la perte de paquets….





Tu peux faire du TCP en envoi recommandé avec AR <img data-src=" />



Perso je m’en fous ^^ jamais vu l’utilité de chiffrer mes mails <img data-src=" />


Le ping est pas super :p



SYN








Mihashi a écrit :



Perso, j’ai toujours été en texte brut, les emails en html c’est le mal <img data-src=" />





ouais, enfin, au taff, lorsque tu veux inclure une mise en forme, ou juste une image, un graphique, le texte brut c’est assez limité <img data-src=" />



En fait j’y suis passé depuis un bon moment au taff (pour les yeux et inciter mes collègues a arrêter les backgrounds dégueulasses qui prennent de la place) c’est juste que je n’avais pas pensé à le faire à la maison.

Disons que j’ai pas attendu le FUD d’hier pour y passer :)




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.



Pourtant c’est apparemment bien le cas, mais Werner Koch aurait “oublié” avoir été contacté. ^^

j’ai pas les liens mais c’est ce qui traine sur Twitter dans le maelstrom qui a suivi l’annonce.


enfin tout ça montre encore une fois combien la différence est grande entre un protocole et son implémentation.


Claws Mail FTW !


Pour envoyer une image, tu fais une pièce jointe, pas un mail html (qui est en fait un document HTML dans un mail qui ne contient que ça comme pièce jointe et pas de corps de texte).








alex.d. a écrit :



Pour envoyer une image, tu fais une pièce jointe, pas un mail html (qui est en fait un document HTML dans un mail qui ne contient que ça comme pièce jointe et pas de corps de texte).





Non, mais personnellement, on se sert des mails pour envoyer des choses avec une certaine mise en page, des surlignages, etc…, si toutes les images sont en PJ ça ressemble plus à rien; si on veut juste discuter ou envoyer une photo, on utilise Slack, pas les mails :)

&nbsp;



Des AR qui se perdent, ça existe. Et généralement, la seule explication de la poste est “On sait pas ou est votre lettre”. Très pratique pour un recommandé avec suivi :/


Argg, l’horreur <img data-src=" />



Les emails c’est pas fait pour écrire un rapport…








eglyn a écrit :



Non, mais personnellement, on se sert des mails pour envoyer des choses avec une certaine mise en page, des surlignages, etc…, si toutes les images sont en PJ ça ressemble plus à rien; si on veut juste discuter ou envoyer une photo, on utilise Slack, pas les mails :) &nbsp;





Si je veux envoyer un document avec mise en page, j’envoie un pdf. Tout le monde autour de moi utilise le mail pour envoyer du texte, en format texte. Sauf la com, qui envoie des trucs en html avec des images partout, un tag latin1 bien que le contenu soit en utf8, une mise en page au pixel près qui pète dès que ton écran n’a pas la bonne résolution, du texte en couleur qui suppose que ton fond est blanc (et est parfaitement illisible si ton fond est noir), etc.

Bref, mail = texte.

&nbsp;



Depuis quand les gens chiffrent les mails ? <img data-src=" />


Ça dépend des gens. J’ai l’impression que ceux qui chiffrent les mails et ceux qui envoient des mails en html sont des ensemble relativement disjoints.


envoyer un courrier en HTML c’est comme envoyer un code source en disant au destinataire “tiens, compile ca et exécute le pour connaitre mon message”.



Et quand on voit la complexité et les possibilités des moteurs de rendu HTML, faut pas s’étonner qu’un émetteur mal intentionné puisse trouver le moyen de faire des choses dangereuses sur l’ordinateur du destinataire.


Avec le facteur aussi…



J’ai lu cette actu dans mon flux RSS hier soir, mais sur la page d’accueil du site, elle est indiquée “publiée il y a 2h”… Serais-je tombé dans une faille spatio-temporelle ? <img data-src=" />


Mais lol quoi.



Quand tu fais des échanges avec plusieurs personnes dans la boucle, pouvoir mettre en forme le texte un minimum c’est juste essentiel.

S’il faut commencer à s’échanger des pdf sous prétexte de faire une liste numéroté maintenant…









CryoGen a écrit :



S’il faut commencer à s’échanger des pdf sous prétexte de faire une liste numéroté maintenant…















  1. Et si en plus le lecteur mail supporte le markdown, il bénéficie de la mise en page automatique



T’es bien conscient qu’une liste numérotée, c’est uniquement du texte ?



Mais sinon, un “échange avec plusieurs personnes dans la boucle”, ce n’est pas possible en PGP. Tu chiffres avec la clef du destinataire (i.e. un seul destinataire).

&nbsp;


Merci de comprendre le second degré XD



Et puis, support du markdown ? Donc d’un système générant… de l’html en général ?

Quitte à utiliser un langage de présentation, autant utiliser html.



Non mais vous êtes sérieux tous ? Second degré ? Évidemment que je ne me limite pas à la numérotation.

Et puis je peux jouer au même jeu que vous : le html ce n’est que du texte huhu <img data-src=" />



Et puis quel rapport avec le PGP maintenant : vos commentaires sont autour du email en HTML en général.

Changez pas le contexte quand cela vous arrange svp.


euh dans ce cas pourquoi ne pas passer par un document partagé ?

Dans mon asso on fait comme ça (framapad).



Bon au labo on en est resté à un doc avec suivi de correction et compilation par le porteur de la publi, mais bon les biologistes et l’informatique ça n’a jamais vraiment collé ;) (le top ça serait un document LaTeX (sauf que les éditeurs veulent du word …) + git tiens ;) )


Ben nous texte = Slack :)

le mail est généralement pour les clients, et c’est vrai qu’il faut respecté une certaine “mailtouzolimignontoutplein” avec des signatures qui ont des images, une mise en page qui fait professionnel, pas un texte brut moche,&nbsp; etc… on refait pas les commerciaux ;)

&nbsp;

Et je ne vois personne autour de moi (clients compris) qui envoient leurs mails en texte brut, c’est con, mais ça fait pas sérieux, c’est comme ça :)



&nbsp;


Ah mais je ne parle pas de la création d’un document dans un email. Mais bien d’une “discussion”.

Pour souligner des morceaux de phrases, ajouter vite fait un visuel, surligner un passage etc.








CryoGen a écrit :



Ah mais je ne parle pas de la création d’un document dans un email. Mais bien d’une “discussion”.

Pour souligner des morceaux de phrases, ajouter vite fait un visuel, surligner un passage etc.





Voilà exactement ce que l’on fait souvent dans des échanges de mail (avec des listes de distributions, donc du monde), ce qui est impossible en texte brut :)



euh dans ce cas y a les commentaires et le suivis de modif dans les documents partagés.

Désolé mais je vois pas quand cet usage de mail serait indispensable.



Soit c’est une discussion synchrone et dans ce cas un tchat est plus simple,



Soit c’est une discussion asynchrone et le mail est un bon outil (en suivant la NETiquette, à savoir répondre sous la ligne qui correspond à la question et non d’un bloc)



Soit c’est un brouillon de document est dans ce cas un document partagé avec suivi de correction + commentaires + proposition est bien plus adapté (en plus tout les clients de mettent pas en forme de la meme manière. A quoi bon travailler la forme par mail et prendre le risque que tout saute si un collaborateur n’a pas le meme client mail ?)


Le rapport est simple : la vulnérabilité ne se produit que pour le cas des mails en HTML avec objets distants et un mailer qui charge automatiquement les objets distants.

On sait bien que, indépendamment de cette vulnérabilité précise, l’activation des objets distants (ou du javascript) dans les mails HTML est d’une manière générale à éviter pour la sécurité.

Mais autour de moi, je constate que ceux qui envoient des mails chiffrés ne font pas de HTML, et ceux qui envoient des mails en HTML ne savent même pas ce que signifie PGP.

&nbsp;


t’envois un mail avec 3 questions à un mec, 4 autres en copie.

le gars répond dans le champ de ton mail en appliquant un style (gras, italique, couleur) à ses réponses pour un confort de lecture.



là dessus une des personnes en copie a quelque chose à dire.

il répond aussi en appliquant son style, toujours dans le mail d’origine (au lieu d’une réponse avec le mail reçu copié plus bas).



d’un bête texte de 3 lignes tu te retrouves vite avec un truc beaucoup plus enrichi.



tu vas me dire: autant faire un document partagé.

oui mais qui fait un doc partagé quand il a 3 questions à poser?



si les gens utilisent le mail pour ça, c’est qu’ils trouvent ça utile.

et si personne n’utilise un document partagé pour discuter, c’est que ça n’est pas adapté à leur besoin.








eglyn a écrit :



le mail est généralement pour les clients, et c’est vrai qu’il faut respecté une certaine “mailtouzolimignontoutplein” avec des signatures qui ont des images, une mise en page qui fait professionnel, pas un texte brut moche,&nbsp; etc… on refait pas les commerciaux ;)





Si un jour je suis ton client, ne m’écris pas en HTML si tu veux être pris au sérieux…



c’est quand même assez marrant les gens qui disent: le HTML dans les mails ça sert à rien et c’est une faille de sécu.



non, le HTML ça sert, sinon personne ne l’utiliserait.

et si la sécu les empêche de bosser, les gens la contournent.

or ici il n’est même pas question de ça: la faille de sécu c’est les extensions qui n’implémentent pas MDC, et un peu aussi GnuPG qui n’a pas mis ça dans son standard et a attendu que tout le monde s’y mette (depuis 99, une éternité).

c’est pas de la faute des users pour qui le mail est un outil de travail.


tu seras 1 sur 10 000.



excuse moi hein, mais le gars qui désactive HTML dans son mail aujourd’hui, c’est un gros nerd barbu. ^^








hellmut a écrit :



excuse moi hein, mais le gars qui désactive HTML dans son mail aujourd’hui, c’est un gros nerd barbu. ^^





Et celui qui chiffre ses mail en GPG, n’est-il pas un gros nerd barbu ?

&nbsp;









alex.d. a écrit :



Si un jour je suis ton client, ne m’écris pas en HTML si tu veux être pris au sérieux…





Ecoute,&nbsp; ce que je constate, c’est que je ne reçois aucun mail en texte brut de toutes les boites dans le secteur aéronautique avec lesquelles je bosse.



Donc il y a bien une raison pratique à ça, on va pas se passer d’un outil de travail parce qu’ il y a potentiellement une faille de sécurité; des failles, il y en a partout, c’est pas aux utilisateurs finaux d’être pénalisés. C’est au SI de faire en sorte de bloquer les mails potentiellement dangereux en amont.









alex.d. a écrit :



Le rapport est simple : la vulnérabilité ne se produit que pour le cas des mails en HTML avec objets distants et un mailer qui charge automatiquement les objets distants.

On sait bien que, indépendamment de cette vulnérabilité précise, l’activation des objets distants (ou du javascript) dans les mails HTML est d’une manière générale à éviter pour la sécurité.

Mais autour de moi, je constate que ceux qui envoient des mails chiffrés ne font pas de HTML, et ceux qui envoient des mails en HTML ne savent même pas ce que signifie PGP.







Ah là je suis d’accord. Mais mon commentaire auquel tu as répondu ne portait pas sur ce point.

J’ai presque envie de dire qu’un mail chiffré devrait être le plus “brute” possible pour éviter toute fuite, bien d’accord. Celà dit, ici, si on t’envoi un email HTML reforgé à partir d’un email orginal en texte brute, tu l’as dans l’os quand même :/ (sauf si tu as desactiver l’affichage html.







odoc a écrit :



euh dans ce cas y a les commentaires et le suivis de modif dans les documents partagés.

Désolé mais je vois pas quand cet usage de mail serait indispensable.



Soit c’est une discussion synchrone et dans ce cas un tchat est plus simple,



Soit c’est une discussion asynchrone et le mail est un bon outil (en suivant la NETiquette, à savoir répondre sous la ligne qui correspond à la question et non d’un bloc)



Soit c’est un brouillon de document est dans ce cas un document partagé avec suivi de correction + commentaires + proposition est bien plus adapté (en plus tout les clients de mettent pas en forme de la meme manière. A quoi bon travailler la forme par mail et prendre le risque que tout saute si un collaborateur n’a pas le meme client mail ?)







Roh… t’es lourd quand même.

1/ tout le monde n’a pas le même avis sur l’utilisation d’un email que toi. Ca reste un outil.

2/ Je ne cherche pas à faire de la mise en page pour impression dans un email, juste à présenter de l’info correctement, et rendre lisible/digeste le contenu

3/ Même un tableau peut-être utile dans un email : j’ai besoin de faire un doc pour ça ? non.

4/ L’échange rapide d’information ?

5/ Le respect de la mise en page ? Encore une fois ce n’est pas de la mise ne page d’impression, juste de la mise en avant d’information…






j’aime bien le principe du “Ceux qui font pas comme moi sont trous des&nbsp; cons”.

Niveau ouverture de discussion, c’est toujours parfait.


c’est pas la question, là.

tu parles du HTML. ^^


merci. <img data-src=" />








CryoGen a écrit :



Roh… t’es lourd quand même.

1/ tout le monde n’a pas le même avis sur l’utilisation d’un email que toi. Ca reste un outil.

2/ Je ne cherche pas à faire de la mise en page pour impression dans un email, juste à présenter de l’info correctement, et rendre lisible/digeste le contenu

3/ Même un tableau peut-être utile dans un email : j’ai besoin de faire un doc pour ça ? non.

4/ L’échange rapide d’information ?

5/ Le respect de la mise en page ? Encore une fois ce n’est pas de la mise ne page d’impression, juste de la mise en avant d’information…







Quand je disais que je voyais pas, c’était pas pour rien hein, effectivement j’utilise pas le mail de cette facon car ça devient vite ingérable (enfin c’est mon avis point), et généralement quand la discussion devient à ce point compliquée, c’est qu’une réunion est nécessaire pour aller plus vite (IRL ou par visio).



Après libres aux gens de faire autrement évidemment. Mais faudra pas non plus se plaindre si un jour la DSI de la boite empêche d’utiliser les mails en html.





(et pour la mise en page ca change rien que ça reste en discussion : si une personne n’utilise pas un client html, la mise en page de l’info sautera tout autant)









eglyn a écrit :



Ecoute,  ce que je constate, c’est que je ne reçois aucun mail en texte brut de toutes les boites dans le secteur aéronautique avec lesquelles je bosse.



Donc il y a bien une raison pratique à ça, on va pas se passer d’un outil de travail parce qu’ il y a potentiellement une faille de sécurité; des failles, il y en a partout, c’est pas aux utilisateurs finaux d’être pénalisés. C’est au SI de faire en sorte de bloquer les mails potentiellement dangereux en amont.







Faut quand meme se méfier de ce genre de raisonnement, souvent les SI n’y vont pas avec une frappe chirurgical mais direct l’atomisation : ici y a un risque que certaines DSI bloquent le format HTML, du coup ça sera bien à l’utilisateur de s’adapter.



Dans mon labo (CNRS), on peut meme pas utiliser SSH par ex, et la SI refuse de mettre en place des vpn. Les SATT (société de transfert de technologie, en gros celles qui font le lien entre la mise en place d’un brevet, le chercheur et les financements) obligent chez nous l’utilisation de GPG pour toute discussion, il ne semble pas aberrant qu’à terme leur SI empêche l’exploitation de ce type de faille et filtre tout mail html.





Donc à moins d’être son propre patron (ou d’être dans une petite boite), c’est bien souvent aux utilisateurs de s’adapter et non à la SI ou alors vous avez bien de la chance ;)



D’ailleurs comment la SI pourrait faire le tri ? quand on voit à quel point c’est compliqué de lutter contre un simple spam ou du pishing par ex <img data-src=" />



Pour les réponses de plusieurs personnes, tu réponds généralement sous le propos de la personne que tu cites. Et pour montrer que c’est une citation, chaque ligne de son message est précédée du caractère de citation (&gt;). Et TOUS les clients mail gèrent ce caractère, soit en mettant une indentation devant (client tels que Thunderbird ou Outlook, ce qui donne un rendu proche d’une citation sur NextINpact), soit en colorant le fond (claws mail, mutt), par exemple.



&nbsp;Il suffit de rejoindre des listes de diffusion telles que la FRnOG ou la FRsAG pour se rendre compte que le texte brut ça marche bien ^^



Je parlais de NextINpact au-dessus… il faut remarquer que tout le fil de commentaires est composé majoritairement de texte brut et de citations, j’ai pas vu de mise en page. Marrant, ça pourrait être un fil de mail :p



Et en pratique, une emphase (encadrée d’astérisques *, si le formatage les enlèves), ça passe souvent très bien, en texte brut. Parfois c’est même mis en forme. Et ça reste lisible quand ce n’est pas mis en forme. C’est vrai que le support du Markdown dans les clients serait génial. Un Markdown non mis en forme reste lisible, contrairement au HTML.








ytterbium a écrit :



Je ne sais pas tu es ironique, mais c’est sans doute le cas. La protection du courrier peut être plus sécurisée que l’informatique.

(encore mieux, envoyer un courrier chiffré par gpg)







Je déconne quand je dis que je n’utilise plus que La Poste mais pas du tout quand je dis que la confidentialité est mieux assurée…

Si on avait le 1/10e des lois sécuritaires qui s’appliquent sur les flux internet qui s’appliquaient aussi sur le courrier physique, on aurait une révolution dans le pays. D’ailleurs, je comprends pas pourquoi les terroristes s’emmerdent avec la communication internet…