Accéder au contenu.
Menu Sympa

technique - Re: [TECH] l'impertinence d' Enigmail

Objet : Liste pour les discussions techniques (liste à inscription publique)

Archives de la liste

Re: [TECH] l'impertinence d' Enigmail


Chronologique Discussions 
  • From: Nicolas VINOT <nvinot AT april.org>
  • To: technique AT april.org
  • Cc: Association Libres-Ailé(e)s <librezaileez AT librezele.fr.cr>
  • Subject: Re: [TECH] l'impertinence d' Enigmail
  • Date: Thu, 03 Jul 2014 17:44:21 +0200
  • Organization: April

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.




Archives gérées par MHonArc 2.6.18.

Haut de le page