Re: [TECH] l'impertinence d' Enigmail

["Association Libres-Ailé(e)s" <librezaileez AT librezele.fr.cr>]

Merci Nicolas, c'est vraiment intéressant et utile. Je vais aussi aller 
lire les documents que tu indiques en liens.
libre fan
On 07/03/2014 05:44 PM, Nicolas VINOT wrote:
> 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,


--
Libres-Ailé(e)s, pour GNU/Linux et le monde du Libre: http://librezele.fr.cr
http://bibliolibre.eu.org/ - en lien avec Libre-Fan http://librefan.eu.org/
Libérez vos courriels: http://autistici.org/ ou http://riseup.net/