La version 1.0.0 date de fin 2017, et je n'en trouve trace sur le site. Que propose ce projet? L’idée, c'est d'ajouter de manière transparente des informations permettant de chiffrer les courriels. Et de basculer automatiquement vers des échanges chiffrés lorsque c'est possible. Un petit exemple:
- Alice écrit à Bob. L’entête du message permet à Bob de récupérer automatiquement la clé de Alice.
- Bob écrit à Alice. Il a la clé de Alice et peut donc chiffrer le message. L’entête du message permet à Alice de récupérer automatiquement la clé de Bob.
- Ils disposent maintenant tous deux des clés et peuvent échanger de manière chiffrée. Les messages continueront de porter un entête pointant vers la clé de l’émetteur. Si Bob change de clé, l’entête de ces messages va changer. Les destinataires de ces messages seront donc au courant du changement dès que bob leur écrira.
Rien de révolutionnaire, mais un petit pas qui aide à démocratiser le chiffrement. C'est disponible dans quelques applications: https://autocrypt.org/dev-status.html
# Enigmail et Autocrypt
Posté par Yggdras . Évalué à 4.
J'ai effectivement remarqué que mes emails envoyés avec Thunderbird et Enigmail avaient une nouvelle entête, Autocrypt. Cette entête a le gros inconvénient d'être des fois plus grosse que le reste de l'email - je suppose que c'est la clé publique complète. Ça grossit le volume total sur les listes de diffusions…
Par contre, je n'ai pas vu de moyen d'éviter que cet entête soit rajouté systématiquement, et du coup, j'ai désactivé Enigmail temporairement :(
[^] # Re: Enigmail et Autocrypt
Posté par Anonyme . Évalué à 6. Dernière modification le 17 avril 2018 à 15:14.
D’après leur FAQ, il faudrait passer sur une clé ECC pour avoir un entête de taille réduite.
EDIT: modification du lien
[^] # Re: Enigmail et Autocrypt
Posté par gouttegd . Évalué à 8.
Tu peux désactiver Autocrypt uniquement sans avoir à désactiver Enigmail dans son ensemble.
Menu Edit > Account Settings, rubrique OpenPGP Security, onglet Autocrypt, décocher Enable Autocrypt.
# MITM
Posté par Liorel . Évalué à 10.
Ça simplifie certes l'usage de la cryptographie (et c'est déjà un gros plus), mais ça ne résout pas la question d'un MITM dès le premier envoi.
Prenons l'exemple d'Alice qui veut envoyer un message à Bob alors qu'Eve est au milieu et souhaite écouter la conversation :
À l'issue de cet échange, lorsqu'Alice croira parler à Bob, elle le fera avec la clé d'Eve qui pourra tout lire. Idem dans l'autre sens. À noter : ceci ne marche que tant qu'Eve est active. Si, pour une raison ou pour une autre, l'attaque MITM se terminait, elle serait immédiatement découverte.
Ajouter une couche de signature ne change rien au problème : Eve n'aura qu'à retirer le bloc de signature, puis signer avec sa propre signature.
Quelles solutions ?
Une première solution est de disposer, pour le premier mail, d'un canal auxiliaire sûr permettant la transmission d'au moins une des clés publiques.
Si Alice et Bob n'ont pas ce type de canal auxiliaire, ils peuvent utiliser un autre type de canal auxiliaire. Ils peuvent par exemple convenir d'une phrase de passe qu'Alice signerait avec sa clé privée, puis qu'elle retirerait du corps du mail. Bob pourrait alors ajouter cette phrase et contrôler la signature d'Alice.
Une pratique courante est d'envoyer un mot de passe par SMS pour déverrouiller un fichier envoyé par mail ; l'hypothèse étant qu'un MITM sur le mail n'aura sans doute pas de MITM sur les SMS.
En fait, le problème plus général du chiffrement, c'est que ça serait vraiment bien qu'il se démocratise, mais que le moindre faux pas dans son exécution le rend inopérant. C'est vraiment pas évident de concevoir des applications foolproof.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: MITM
Posté par gouttegd . Évalué à 10.
Respectons les usages : Eve ne peut pas faire ça, c’est un attaquant passif qui ne peut qu’écouter (Eavesdrop). L’attaquant actif, qui peut émettre et/ou modifier des messages, c’est Mallory.
Plaisanterie à part, je suis d’accord sur le fond, mais il faut quand même voir qu’on passe d’une situation où n’importe qui peut lire les messages de tout le monde sans que ça ne coûte grand’chose et sans quasiment aucun risque d’être découvert, à une situation (dans le cas hypothétique où tout le monde se met à chiffrer, que ce soit grâce à Autocrypt ou à n’importe quelle autre méthode similaire) où l’attaquant doit cibler les personnes dont il veut lire les communications et les attaquer activement, avec un risque non-négligeable de se faire griller.
Ce n’est certes pas parfait et les individus « à haut risque » (genre ancien contractant de la NSA avec des choses à révéler) seraient sans doute bien inspirés de ne pas se fier à ce genre de solutions, mais c’est tout de même un progrès.
[^] # Re: MITM
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
On ne peut pas envoyer sa signature SHA512 de sa clef et la personne la récupère de manière transparente sur un serveur PGP. Du coup, on ne génère pas un en tête énorme et pour ce qui est du MITM, il faut à la fois changer la signature SHA512 mais aussi modifier la clef PGP sur le serveur public, pas si facile que cela à faire si on n'est propriétaire de l'adresse de courriel…
[^] # Re: MITM
Posté par gouttegd . Évalué à 4.
Pourquoi une « signature » (qui n’en est pas une, c’est un condensat mais passons) SHA-512 ? Il y a l’empreinte SHA-1 de la clef pour ça.
Oui, je sais, SHA-1… mais SHA-1 n’est pas cassé pour ce cas d’usage et le calcul de l’empreinte SHA-1 d’une clef OpenPGP est clairement défini par le standard — il n’y a qu’une seule façon de calculer une telle empreinte. Si tu génères un condensat SHA-512 d’une certaine façon et que ton correspondant le calcule d’une autre façon, la comparaison est impossible.
Cela étant, on peut déjà faire ce que tu proposes (et il y a une option dans Enigmail pour le faire), c’est l’en-tête
OpenPGP(non-standard — il y a eu un brouillon à une époque mais ce n’est pas allé plus loin) :Quant à savoir pourquoi Autocrypt n’a pas ré-utilisé cet entête, aucune idée… NIH, peut-être ?
[^] # Re: MITM
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
J'ai dis SHA-512 car c'est ce qui m'est passé par la tête, je ne connais pas bien les entrailles de PGP. D'ailleurs je viens de lire (cf news) que PGP passait sur SHA-256. Sinon, empreinte, signature… À partir du moment ou le hash est unique, c'est bien du pareil au même. L'idée ici est juste d'avoir un moyen (simple) d'être relativement sur que la clef est la bonne et validé par la personne en face.
[^] # Re: MITM
Posté par Anonyme . Évalué à 1.
L'entête utilisé est un peu différent: il semble qu'ils mettent directement la clé:
Autocrypt: addr=a@b.example.org; [prefer-encrypt=mutual;] keydata=BASE64
The value of the keydata attribute is a Base64 representation of the binary OpenPGP “Transferable Public Key”
https://autocrypt.org/level1.html#the-autocrypt-header
[^] # Re: MITM
Posté par fcartegnie . Évalué à 2.
Super : personne stocke en local sa clé épurée.
Donc des headers de 300 à 1Mo pour ceux qui ont participé à une keysigning…
[^] # Re: MITM
Posté par gouttegd . Évalué à 2.
On peut aussi critiquer sans tomber dans la mauvaise foi. Deux paragraphes après la référence au RFC 4880 (qui explique ce qu’est une « Transferable Public Key »), la spec Autocrypt précise que la clef à inclure dans l’en-tête est une version minimale contenant uniquement :
Soit peu ou prou ce qu’on obtient avec l’option
--export-options export-minimalde GnuPG, avec la suppression des User ID supplémentaires en plus.Ça reste trop gros à mon goût pour être inclus dans un en-tête dans chaque e-mail, mais on est loin des 300 ko à 1 Mo, indépendamment du nombre de certifications sur ta clef.
[^] # Re: MITM
Posté par gouttegd . Évalué à 10.
Euh, si, c’est très facile : n’importe qui peut charger une clef à n’importe quel nom sur un serveur de clefs.
Mettre la clef complète dans l’en-tête ou ne mettre que l’empreinte et une indirection vers la clef complète, en terme de protection contre une attaque MITM ça revient peu ou prou au même : dans le premier cas l’attaquant remplace la clef dans l’entête, dans le deuxième cas il remplace l’empreinte et publie la clef correspondante sur un serveur.
Sans oublier que l’attaquant peut dans tous les cas faire un truc encore plus simple, qui rend toute cette discussion complètement théorique : supprimer purement et simplement les en-têtes
Autocryptdans tous les messages. Les logiciels compatibles Autocrypt aux deux extrémités de la conversation en déduiront chacun que le logiciel d’en face ne connaît pas Autocrypt, et continueront à envoyer des messages en clair…[^] # Re: MITM
Posté par Anonyme . Évalué à 4.
Il y a probablement des bonnes idées à récupérer chez Signal et Whatsapp: ils affichent des avertissements lorsque la clé d'un correspondant change. Pour vérifier les clés, il me semble que l'un de ces programmes affiche quelques combinaisons de 4 chiffres, que l'on peut vérifier de vive voix en appelant le correspondant. C'est une empreinte réduite probablement.
Faut garder à l'esprit que le niveau de sécurité doit correspondre à un niveau de menace. Si le problème c'est l'espionnage de masse, alors Autocrypt apporte un peu d'aide, mais il reste toutes les métadonnées de l'email en clair…
[^] # Re: MITM
Posté par steph1978 . Évalué à 6.
Excellent ! Ça a été couché sur le papier
# Totalement broken sans authentification de clé
Posté par fcartegnie . Évalué à 7.
Envoyer
laune clé à utiliser dans la réponse est une mauvaise idée.Si la clé n'est pas fournie pas un moyen de confiance par le destinataire, rien n'empêche l'attaquant de substituer une autre clé et faire un MITM.
C'est comme envoyer des données à un serveur TLS qui n'aurait pas de CA.
Rien ne prouve que c'est bien le certificat du serveur demandé.
La seule "validation" implicite c'est via le réseau de confiance et les signatures de clé, mais là encore, rien ne prouve que la clé récupérée est la bonne et pas une clé révoquée.
En plus:
- ça bloate les headers en grossissant la clé avec toutes les signatures.
- la seule manière de vérifier les révocations c'est de vérifier auprès d'un serveur de clés auquel on fait confiance (en TLS bien sur!)
Ca rend le concept de clé dans le header ou de lien de clé dans le header totalement bancale, voire dangereux.
[^] # Re: Totalement broken sans authentification de clé
Posté par ckyl . Évalué à 6.
C'est pourtant la mode, d'HPKP à HSTS en remontant jusqu'à l'identification d'un serveur SSH.
https://en.wikipedia.org/wiki/Trust_on_first_use
L'intersection entre sécurité et utilisabilité semble assez vide. Vu que les solutions sures qui exposent le problème du tiers de confiance ou de canal d'échange sécurisé pour l’amorçage ne sont pas utilisées, on semble essayer du TOFU un peu partout en se disant que c'est peut être moins pire que la situation actuelle.
[^] # Re: Totalement broken sans authentification de clé
Posté par kna . Évalué à 5.
Sauf que si j'en crois le journal, c'est pas seulement on first use
[^] # Re: Totalement broken sans authentification de clé
Posté par gouttegd . Évalué à 7.
On dirait. Si je comprends bien la section Updating Autocrypt Peer State, l’apparition d’une nouvelle clef dans un entête
Autocrypt(différente de celle déjà vue auparavant pour le même interlocuteur) est silencieuse : le client compatible Autocrypt met à jour sa base de données avec la nouvelle clef comme si de rien n’était.Ce n’est pas du TOFU au sens où on l’entend habituellement, et tel qu’il est pratiqué avec SSH ou avec le modèle
tofude GnuPG — dans ces modèles, l’apparition subite d’une nouvelle clef produit un avertissement.Je trouve ça personnellement regrettable mais c’est un choix cohérent avec les principes énoncés clairement dans le document :
[^] # Re: Totalement broken sans authentification de clé
Posté par kna . Évalué à 3.
Effectivement, c'est cohérent. Ça ne donne pas une solution au top du top mais ça pourrait permettre de démocratiser le chiffrement, en le faisant fonctionner out-the-box.
Sauf que, à moins que je sois passé à côté de quelque chose, il reste 2 soucis :
* si la clé est perdue, on peut repartir avec une nouvelle clé, mais les messages reçus précédemment ne sont plus lisibles
* ça ne fonctionne que si on utilise un seul client de messagerie sur un seul terminal
Ce qui doit être rédhibitoire pour pas mal de monde…
[^] # Re: Totalement broken sans authentification de clé
Posté par gouttegd . Évalué à 4.
C’est vrai, mais c’est indépendant de Autocrypt. Le problème se pose dès lors que tes correspondants et toi chiffrez vos messages, quel que soit l’outil utilisé et qu’il soit compatible Autocrypt ou pas.
Là où il peut y avoir un soucis spécifique à Autocrypt, c’est que le protocole (et les outils qui l’implémentent) se veut transparent, il est envisageable que certains utilisateurs ne réalisent même pas que leurs messages sont chiffrés, et ne soient donc pas conscient qu’ils ont une clef qu’ils ne doivent pas perdre.
(Ça ne peut pas vraiment arriver avec Enigmail, pour la simple raison qu’Enigmail est un plug-in que l’utilisateur doit explicitement installer — et quelqu’un qui installe Enigmail est déjà un minimum averti. Mais on peut imaginer un client de messagerie prenant nativement en charge Autocrypt et générant la paire de clefs de sa propre initiative, sans aucune intervention de l’utilisateur. C’est certainement un objectif du projet, tel que je le comprends : arriver à une situation où les messages sont chiffrés par défaut sans que jamais l’utilisateur n’ait à s’en soucier.)
Apparemment non, il est prévu de faciliter l’utilisation de plusieurs clients (potentiellement sur des appareils différents). Je n’ai pas étudié cette partie de la proposition en détail donc je n’ai pas d’opinion dessus (à part une : quelque soit la méthode mise en place, je rechigne à la seule idée d’avoir une clef privée stockée sur plusieurs appareils — mais encore une fois, c’est un problème inhérent au chiffrement de bout en bout, ce n’est pas propre à Autocrypt).
[^] # Re: Totalement broken sans authentification de clé
Posté par galactikboulay . Évalué à 2.
Juste 2 remarques:
HPKP va être abandonné par Google pour Chrome: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ , à voir si les autres navigateurs vont suivre le même chemin.
HSTS indique juste au navigateur client qu'il doit utiliser la version HTTPS du site, pour une certaine durée, il n'y a pas d'information de clé.
[^] # Re: Totalement broken sans authentification de clé
Posté par gouttegd . Évalué à 6.
Oui, ça s’inscrit dans la stratégie de Google de contrecarrer toute initiative qui pourrait encourager à se passer du cartel des CA, et au contraire à renforcer le caractère incontournable des CA en poussant Certificate Transparency.
Rien de bien nouveau, c’est une stratégie en vigueur depuis déjà pas mal de temps.
[^] # Re: Totalement broken sans authentification de clé
Posté par barmic . Évalué à 2.
C'est bizarrement dis ça… Firefox fait de même et Mozilla est carrément provider de certificat et pousse un client qui cherche à obliger à passer par les CA… Pour faire de l'amalgame ou de la conspiration c'est tout de même plus pratique.
Les CA sont mal foutues on est d'accord, mais c'est le moins pire que l'on ai pour le moment tant que DNS Sec n'est pas répandu (s'il se répand un jour). Les solutions à base de WoT ne sont clairement pas viables, même ici sur linuxfr tout le monde ne comprend pas très bien chaque étape…
[^] # Re: Totalement broken sans authentification de clé
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Pas de notion de clé, mais une attaque MITM peut remplacer la version HTTP par ce qu'il veut. C'est moins grave que pour une clé parce que l'attaque est visible (l'URL reste en
http://, pas de cadenas dans la barre d'URL, …), mais pour un utilisateur peu attentif ou peu compétent, il y a pas mal de dégâts à faire au moment de la première utilisation.Après, c'est pas pire que rien du tout : un serveur qui ne répond pas sur le port 80 pourrait se faire attaquer de la même manière qu'un HSTS.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.