Re: [TECH] l'impertinence d' Enigmail

[Nicolas VINOT <nvinot AT april.org>]

Le jeudi 03 juillet 2014, 17:02:31 Association Libres-Ailés a écrit :
> je voudrais savoir 
> comment justifier l'affirmation qu'Enigmail n'est pas la bonne solution 
> car il ne suit pas la norme de GPG.

Ce n'est pas GPG en lui-même qu'il ne respecte pas mais les RFC d'envoi de 
courriel.

Par exemple, un mail en PGP/mime doit respecter le standard défini par la RFC 
3156
        http://tools.ietf.org/html/rfc3156

En particulier
        The multipart/encrypted MIME body MUST consist of exactly two body
   parts, the first with content type "application/pgp-encrypted".
        The second MIME body part MUST contain the actual encrypted data.  It
   MUST be labeled with a content type of "application/octet-stream".

Enigmail émet au contraire des courriels avec du "multipart/mixed" au lieu de 
"application/pgp-encrypted"
Ça a été reporté ici
        http://sourceforge.net/p/enigmail/forum/support/thread/fbac6874/#d2fd

Idem, si tu envoies un contenu HTML en plus du contenu texte (ce qui en soit 
est déjà très mal), Enigmail chiffre le HTML de manière très marrante.
Plutôt que de chiffrer tout le contenu HTML et de le mettre dans un contenu 
MIME "application/pgp-encrypted", il extrait le contenu du body, chiffre ce 
contenu avec GPG, puis remplace tous les \n générés par GPG par des <br/> 
HTML, puis remet le tout dans le body, et surtout laisse le content-type 
"text/html"…

Idem pour les pièces jointes, le content-type n'est pas changé de 
"application/octet-stream" à "application/pgp-encrypted" (et du coup leak le 
nom des pièces jointes).

Et dans les 2 cas précédents (dès qu'il n'y a pas que du texte en fait), la 
RFC indique même que l'intégralité du message devrait être « compressé » dans 
un seul message "multipart/signed" chiffré globalement avec GPG et qui une 
fois 
déchiffré conduit au message MIME standard (avec les parties text/plain, 
text/html et application/octet-stream des pièces jointes).
Ce qui évite au passage de leaker des méta-données, et simplifie énormément 
la 
gestion du déchiffrement (dans tous les cas, on déchiffre globalement le 
message 
et on laisse ensuite le comportement normal du client de courriel fait son 
office, au lieu d'avoir de multiples allers-retours entre client de courriel 
qui 
se tape des blocs GPG à passer pour déchiffrement pour avoir accès aux infos 
en 
clair).

En bref, Enigmail fait un peu ce qu'il veut avec les RFC…

> Peut-être un document, ou votre expérience, car je suis bien incapable 
> d'expliquer à qq'un ce qu'est la norme de GPG, et ce que ça veut dire de 
> la suivre?

Si j'ai un peu de temps, je pourrais tenter de faire un comparatif des 
courriels générés avec Enigmail d'un courriel tel qu'il devrait être selon la 
RFC.

Librement,
-- 
Nicolas

Protégez votre vie privée, chiffrez vos communications
GPG : EFB74277 ECE4E222
OTR : 922C97CA EC0B1AD3
https://café-vie-privée.fr/

Attachment: signature.asc
Description: This is a digitally signed message part.