Cher Journal,
Je me demandais si il faudrait pas coder, ou si il n'existait pas déjà, un projet de client mail sympas ou l'emploi de GPG était automatisé. Je m'explique, j'essaye en vain de proposer a mes proches amis avec qui nous avons des discussions sur la sécurité internet de créer une clef symétrique et de l'utiliser dans nos échanges. Sauf qu'ils sont tout sauf computer-friendly et que le manque de solution agréable est un défaut dans mon argumentation.
Sauf mac par exemple, mail est insuportable, le plugin gpg est cool; sous Gmail les client gpg s'installent comme ils peuvent, sous Thunderbird, là c'est le client qui pose problème (pour des tas de raisons qui sont propre aux utilisateurs dit).
Et je me disais, pourquoi le client mail lors de l'installation proposerait pas de lui même un création de clé GPG avec envoi direct sur serveur et partage avec contact avec une utilisation pratiquement invisible pour les utilisateurs. Si le client mail était adopté de tous pour ses qualité ergonomique, tous le monde finirait par avoir sa clé symétrique et pourrait chiffrer voir signer ses mails, comme un identité unique à l'installation mais géré par GPG.
Je crois pas de client mail le propose dès initialisation
Merci journal
# Ergonomie
Posté par téthis . Évalué à 6.
Voilà une condition qui va être très difficile à remplir.
Pour être un peu plus constructif, j'ai récemment découvert minilock ainsi que l'utilitaire mlock pour créer et ouvrir les fichiers minilock. Ce côté GPG allégé a l'air sympa pour du ponctuel.
The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein
# Mailpile
Posté par fredzz (site web personnel) . Évalué à 5.
Il y a Mailpile, qui n'est pas encore stable, mais qui présente le gros intérêt de pouvoir faire des recherches dans sa base de mails encryptés.
[^] # Re: Mailpile
Posté par aurel . Évalué à 3.
À noter que les retours des utilisateurs sur version beta n'ont pas été jugés satisfaisants par les développeurs. Concernant la partie crypto, on trouve ce passage sur le dernier billet du blog:
Traduction rapide: "Notre stratégie et notre code autour de GPG ne sont pas prêts. Nous devrions soit faire en sorte que le chiffrement soit totalement transparent, soit améliorer les outils que nous mettons à disposition de l'utilisateur pour qu'il puisse le faire manuellement. L'idéal serait de faire les deux."
C'est pas gagné.
[^] # Faux problème
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
Je pense que tu fais fausse route.
D’abord parce que les gens n'utilisent plus de clients mails. Ensuite car le problème n'est pas tant de signer ou chiffrer des mails, ce qui est relativement facile à implémenter de façon transparente. Mais bien de gérer un trousseau de clé et plus généralement de certificats.
Ce problème est plus générique que simplement celui des mails, il rejoint par exemple celui des autorités de certifications dans les navigateurs ou là ou on devrait gérer des autorités on gère des certificats sans autorité.
La question est donc comment distribuer de façon sécurisé des preuves d'identité cryptographiques.
A cela il existe plusieurs réponses, dont aucune jusqu'à présent n'a été satisfaisante dans son implémentation et son usage.
Toutefois les choses avancent notamment avec DNSSEC et DANE. Les cartes d'identités électroniques comportant une clé de chiffrement comme en Belgique pourraient également jouer paradoxalement un rôle très positif.
Toujours est-il que pour en revenir a un client mail, il faut :
[^] # Re: Faux problème
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il faut aussi gérer les révocations de clef. Devoir être connecté et télécharger un gros fichier, ne passe pas franchement à l'échelle.
"La première sécurité est la liberté"
[^] # Re: Faux problème
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
N’importe quoi, ils font tous cela sur leur téléphone.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Faux problème
Posté par Philippe GRAILLE . Évalué à 2.
!? Ben voyons
Grosse erreur selon moi.
C'est peut être ton cas ou celui de ton entourage mais certainement pas une généralité.
Je n'ai pas plus confiance dans mon hébergeur que dans mon FAI.
Donc avoir une copie locale est indispensable. D'autant que le confort d'utilisation et bien plus grand.
Pour en revenir au sujet, je suis moi aussi "désabusé" du coté contraignant et rébarbatif de la sécurisation des mails.
J'ai essayé quelques fois mais vite abandonné devant le coté usine à gaz !
# protonmail
Posté par fredix . Évalué à -1.
en attendant tu peux utiliser https://protonmail.ch qui chiffre par défaut entre 2 boites proton.
[^] # Re: protonmail
Posté par deuzene (site web personnel) . Évalué à 1.
Sauf que :
En attendant, on fait quoi ;)
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
[^] # Re: protonmail
Posté par Zenitram (site web personnel) . Évalué à 10. Dernière modification le 22 mars 2015 à 09:59.
Ha la blague ProtonMail qui est plus marketing qu'autre chose :
- Sécurité par l'obscurité : pas libre, et à défaut le code source n'est pas diffusé, donc comment croire à sa sécurité autre que "faites-nous confiance"? Vous y croyez encore à la sécurité par l'obscurité?
- Webmail, c'est defective by design : ils changent quand ils veulent le code que tu exécutes, donc récupères quand ils veulent ton mot de passe (tu regardes le code à chaque exécution? Pas la peine de compter sur les autres, vu qu'on peut cibler que ton compte avec le code qui va bien pour récupérer ton pass, c'est personnalisé rien que pour toi). La seule solution est de pouvoir installer le serveur, mais comme ce n'est pas libre…
Mais bon, le marketing marche… Les gens en font la pub "sécurisé, essaye" alors qu'il y a un chainon de sécurité manquant (suffit de faire une porte blindée, les gens achète la maison avec fenètres ouvertes car ils ont vu la pub "porte blindée").
[^] # Re: protonmail
Posté par fredix . Évalué à 2.
Certes mais je pars du principe que ca ne peut pas être moins sécurisé qu'une boite gmail
[^] # Re: protonmail
Posté par Zenitram (site web personnel) . Évalué à 3.
Mais pas plus non plus. Suffit de ne pas être moins sécurisé pour qu'on en parle, vraiment?
Donc : pourquoi le conseiller? C'est à cette question que tu ne réponds pas.
(la bonne réponse est : c'est en Suisse et non pas aux USA, on change juste de gouvernement susceptible de regarder tes mails sur réquisition judiciaire, c'est interessant si tu as plus confiance en la Suisse qu'en les USA, le reste genre c'est plus sécurisé est la juste pour le marketing)
[^] # Re: protonmail
Posté par fredix . Évalué à 0.
Les mails sont chiffrés et il faut saisir un 2ème mot de pass qui est stocké uniquement sur ton navigateur pour les lire, tu peux considérer que c'est du bullshit mais leur business model étant basé là dessus j'ai tendance à croire que ce n'est pas que du marketing. A mes yeux c'est toujours mieux qu'une boite gmail/yahoo meme si l'idéal reste à utiliser sa propre solution libre sur son serveur.
[^] # Re: protonmail
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 22 mars 2015 à 12:12.
Est-ce que tu as lu ce que j'ai écrit? De toutes évidences : non.
Tu répètes comme un perroquet le marketing de l'entreprise, sans essayer de comprendre comment ça fonctionne et voir que c'est du pur marketing qui ne sécuritse rien de rien (si la raison t'interesse : voir le commentaire précédent).
Mais je vois qu'on peut te vendre une maison avec porte blindée et fenêtres ouvertes, même si on te dit qu'il y a les fenêtres ouvertes, tu penses que le méchant n'ira jamais prendre la fenêtre, il va rester devant la porte. La preuve qu'ils ont bien raison de faire ce genre de marketing, ça marche.
[^] # Re: protonmail
Posté par fredix . Évalué à -4.
C'est toi le perroquet, tu répètes à loisir qu'il y a forcément des fenêtres ouvertes vu que le serveur n'est pas installable chez toi, mais bon il suffit pas de le répéter pour que ce soit vrai hein :)
[^] # Re: protonmail
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 22 mars 2015 à 12:51.
Répond alors à cette question : qu'est-ce qui empèche ProtonMail de changer le code rien que pour ton compte (afin qu'il renvoit le mot de passe en clair sur le serveur, comme demandé par la réquisition judiciaire suisse à un moment donné) lorsque tu rentres ton mot de passe? Comment le détecteras-tu? Quelle sécurité t'es apportée par le code JS exécuté chez toi pour garantir que ce code n'enverra jamais le mot de passe au serveur, un jour?
J'explique la faille de sécurité (defective by design, rien à faire, c'est la base de la sécurité : le problème n'est pas entre toi et le serveur, il est sur le serveur, donc ProtonMail ou Gmail, même problème technique), mais bizarrement tu ne contre-argumentes pas dessus pour expliquer où est mon hypothétique erreur de raisonnement. bizarre?
[^] # Re: protonmail
Posté par fredix . Évalué à 2.
Tu expliques ce que je sais déjà et la réponse tu la connais déjà, la législation Suisse est pour l'instant plus respectueuse de la vie privée et elle ne dépend pas des législations US. Quant aux JS je présume que tu pourrais le lire :)
[^] # Re: protonmail
Posté par Zenitram (site web personnel) . Évalué à 4.
finalement, on est d'accord (la partie chiffrement est du marketing qui n'ajoute pas de sécurité en pratique, tu te bases uniquement sur la localisation physique pour préférer une entreprise à une autre).
Pourquoi alors écrire l'inverse?
[^] # Re: protonmail
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 23 mars 2015 à 09:43.
Tu peux lire le JS mais à moins d'avoir un outil qui fait un audit du contenu avant chaque chargement, ça ne te sert pas à grand chose.
D'autant que n'ayant pas accès au code côté serveur, rien ne te prouve que le 2ème mot de passe a un réel intérêt au niveau de la sécu.
[^] # Re: protonmail
Posté par Harry . Évalué à 6.
Je lis souvent cette affirmation, et j'estime au contraire que Gmail est un des hébergeurs mail les plus sécurisé. Penser faire le poids en hébergeant ses mails sur son propre serveur me semble catastrophique, et les solutions libres ne sont pas la question.
Le but de Gmail est d'utiliser les données de ses utilisateurs pour vendre de la publicité, et a tout intérêt à protéger au mieux ces données (qui ne sont d'ailleurs pas revendues à des tiers). Ce n'est pas un hasard si Google a des équipes de sécurité excellentes, et a été une des premières boîtes à proposer des bug bounties sur ses services en ligne. Par ailleurs, on a pu voir la réactivité des équipes de Google pour chiffrer le trafic entre ses data-centers lorsqu'il est devenu public que la NSA avaient accès à ces données.
Là où le bas blesse, ce sont les réquisitions judiciaires. Gmail respectera la loi, et fournira les mails d'un utilisateur pour n'importe quelle demande suffisament justifiée.
Je parle de Gmail en particulier, car la plupart des services de messageries ne sont clairement pas à ce niveau. Tu évoques par exemple Yahoo qui a mis plusieurs jours à patcher la vulnérabilité Heartbleed, entraînant la fuite aléatoire de milliers de login/password d'utilisateurs.
Enfin, héberger ses mails sur un serveur me semble partir d'une bonne intention mais se révèle désastreux du point de vue de la sécurité à long terme. Appliquer les correctifs de sécurité à temps prends du temps, beaucoup de temps ; et sécuriser une machine nécessite des compétentences que tout le monde n'a pas. Il est souvent tentant d'héberger d'autres services sur la même machine, qui augmentent la surface d'attaque. Qu'est-ce qui garantit que l'hébergeur n'est pas compromis ? Que les OS fournis par ce même hébergeur ne sont pas compromis ? Que des administrateurs ont accès au machine par des options d'administration matérielles ?
[^] # Re: protonmail
Posté par Harry . Évalué à 4.
PS (trop tard pour éditer le commentaire) : avant de lire cette réflexion, je préciser que Google est une entreprise qui est détestable sur bien des points, mais que ça n'empêche pas de tenter d'avoir un point de vue impartial sur certains aspects de ses services.
[^] # Re: protonmail
Posté par fredix . Évalué à 5.
c'est bien pour ça que la seule solution sure est d'installer sur un serveur chez soit sa propre solution libre et de devenir de fait informaticien :)
[^] # Re: protonmail
Posté par Jiehong (site web personnel) . Évalué à 8.
Si tu as suivi l'affaire Snowden, si tu n'es pas Américain, et que tu n'es pas aux État-Unis, alors pas besoin de réquisition judiciaire : tu satisfais déjà les conditions pour que tes méls. soient tout sauf secrets.
[^] # Re: protonmail
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
A la différence que Google a le droit de tout chiffrer. Il faut un ordre judiciaire, même si il est secret, pour aller contre. Ce qui permet d'éviter au moins la surveillance de masse.
"La première sécurité est la liberté"
[^] # Re: protonmail
Posté par jolitorax . Évalué à 4.
C'est géré automatiquement par les distributions qui sont très réactives. Sur des distributions orientés serveurs, je n'ai jamais eu de soucis.
[^] # Re: protonmail
Posté par FDF (site web personnel) . Évalué à 4.
Il y a toujours dans ces argumentaires (le flux au-dessus) un point qui n'est que marginalement pris en compte.
Même s'il faut bien sûr prendre en compte la sécurité intrinsèque d'un serveur, il faut aussi prendre en compte le risque d'attaque et d'effort pour y entrer.
C'est sur que quand tu héberges des centaines de millions d'adresses tu es plus tentant que quand tu héberges les emails de ta famille.
Avoir de très nombreux serveurs (un par famille…) rendrait caduque en grand nombre de systèmes d'attaque et cela aussi est à prendre en compte
C'est en fait un peu comme les virus avec Linux/Windows. Il peut bien sûr y avoir des virus sur un poste bureautique Linux, mais le risque est nettement plus faible (indépendamment des aspects structurels) simplement, car il y a moins de virus qui ciblent cette plateforme.
Il y a moins d'attaques qui ciblent le serveur perso que d'attaques ciblant des noms connus.
[^] # Re: protonmail
Posté par 2PetitsVerres . Évalué à 3.
Je me demande bien comment tu es arrivé à cette conclusion.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: protonmail
Posté par Zylabon . Évalué à -1.
Comment va ton genoux ?
Please do not feed the trolls
[^] # Re: protonmail
Posté par Muchacho . Évalué à 2. Dernière modification le 22 mars 2015 à 23:58.
En attendant que protonmail dévoile son code source on peut utiliser tutanota, qui est gratuit (1Go) et/ou open-source, on peut installer notre propre web client.
[^] # Re: protonmail
Posté par Tanouky . Évalué à 1.
Et ça marche bien ? C'est vraiment sûr ?
# dans le même esprit
Posté par palm123 (site web personnel) . Évalué à 6.
je cherche pour mes proches, un client mail qui saurait extraire des headers RFC 822 la vraie adresse IP et le pays associé
par exemple un phising de la caisse d'epargne qui affiche que ce mail vient de abc123xxx.ch, qui se traduit en 210.123.234.111, que utrace.de ou GeoIP montre comme étant en Chine à Canton.
Ce genre de client mail, ça existe ?
ウィズコロナ
[^] # Re: dans le même esprit
Posté par Frank-N-Furter . Évalué à 10.
J’ai pas testé, mais ça le ferait ça: https://addons.mozilla.org/en-us/thunderbird/addon/mailhops/ ?
Depending on the time of day, the French go either way.
[^] # Re: dans le même esprit
Posté par Gilrain . Évalué à 5.
Testé sur une tentative de fishing intitulée « Confirmation de votre compte Gmail » et il affiche bien une origine en Côte d'Ivoire. Je pense que ça correspond au cahier des charges.
# Enigmail
Posté par omc . Évalué à 6.
J'utilise Enigmail. C'est une extension du client mail Thunderbird. C'est assez user-friendly et, à mon avis, peut être utilisable par M. et MM. Michu.
[^] # Re: Enigmail
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 22 mars 2015 à 11:34.
euh… Non.
Ou on n'a pas les mêmes M. et MM. Michu (voyant les autres, je me considère un peu au dessus de M. et MM. Michu en informatique, et déjà je n'y comprend rien de rien, j'ai abandonné).
Faudrait redescendre sur terre, sortir de sa tour d'ivoire, regarder comment font les gens (ils veulent utiliser de manière simple, pas lire un manuel pendant des heures, surtout quand on n'arrive pas à les convaincre de la haute dangerosité, les gens n'ont pas changé leur façon de faire après l'affaire Snowden, ne se sentant pas concernés)
[^] # Re: Enigmail
Posté par Anonyme . Évalué à 4.
je pense qu'il faut vraiment admettre, que pour faire des choses compliqué il faut un logiciel compliqué.
j'ai moulte exemples :) que je vous épargne.
[^] # Re: Enigmail
Posté par SlowBrain (site web personnel) . Évalué à 4.
Donc la sécurité qui est une chose compliquée ne doit être reservée qu'a une élite qui saurra la maitriser parfaitement ?
Si l'on veux un monde avec plus de sécurité pour tous, il faut la rendre plus facile d'accés. C'est trés dur de rendre quelque chose de complexe simple a utiliser, mais ce n'est qu'as cette condition que l'on pourra faire avancer les choses.
Si l'on reste sur le fait que c'est compliqué et qu'on y peu rien, la sécurité ne restera que la chasse gardée de quelques experts. Et pour quelque chose tel que le mail, on passera alors complétement a coté de l'objectif visé.
A quoi cela me sert il d'utiliser une méthode complexe pour sécurisé mes mail si aucun de mes interlocuteurs n'est capable de pouvoir installer la solution de lecture adéquate en face pour pouvoir les lire ?
-
J'ai déjà essayé plusieurs fois le mail sécurisé, et ça n'est finalement pas utilisable. Non pas que je ne sache pas utilisé Enigmail (ce qui est l'étape la plus simple) mais simplement que je n'ai PERSONNE avec qui pouvoir communiquer de cette façon.
Que ce soit famille, belle famille, amis, collégue, grand groupe, associations, … même communiquer avec les membres de mon lug ne passe pas par ce moyen.
A peine une association, juste composé de libristes très engagés, pour les quels la sécurité en deviendrais paranoïaque utilise véritablement des solutions tel que PGP. Et même pour les mails et les mailling list qui en découlent, ça n'est pas utilisé.
La seule VRAIE utilisation de PGP que je verrais serais pour transmettre un bug de sécurité 0 day aux équipes de différents grands projet. Et encore, seulement pour les plus sérieux et adepte de la sécurité.
-
La simplicité est primordiale mais largement sous estimée.
[^] # Re: Enigmail
Posté par Anonyme . Évalué à 3.
Tu fait un raccourci un peu trop rapide, la tentative de simplification n est pas nefaste, elle est inutile. Les mails chiffrés c est compliqué par ce que c estcomme ça ! Personne ni peut rien. La courbe d apprentissage est un peu raide mais pas impossible
A une epoque je chiffrais mes mails avec rot13, nan ne riez pas, et tout mes correspondant savaient l utiliser, sans probleme. Je pense que toi tu vois le probleme;).
Mais c etait suffisant pour que l admin de la pme ne puisse pas lire nos mails.
[^] # Re: Enigmail
Posté par Psychofox (Mastodon) . Évalué à 5. Dernière modification le 23 mars 2015 à 09:55.
C'est un problème hyper complexe.
Comment vouloir assurer le chiffrement de bout en bout, sans devoir faire un exposé sur l'utilisation d'un trousseau et le partage de clés publiques, et en restant compatible avec tout type de logiciel et de hardware en s'assurant que lesdits logiciels puissent être mis à jour quasi automatiquement (implique l'utilisation des "stores" dont tu n'as aucun contrôle) tout en s'assurant que le code exécuté par chacun de tes destinataires n'est pas modifié/compromis ?
Franchement à part en fournissant à chacun de tes correspondants un pc et un smartphone configuré et maintenu par tes soins, sans qu'ils puissent y installer quoique ce soit d'autre dessus, mais qui soit impossible de déchiffrer si volés/perdus, bon courage pour assurer la sécurité de tes communications. Bon courage pour vendre ça à tes destinataires et t'assurer la maintenance de l'infra !
[^] # Re: Enigmail
Posté par omc . Évalué à 3.
Au moins Enigmail à le mérite d'essayer de rendre les choses accessibles et transparentes pour le grand public. Je pense qu'avec un peu d'aide, M. et MM. Michu pourraient s'en servir.
Attention, ils ne faut pas aller dans l’excès inverse, et sous-estimer les capacités de M. et MM. Michu. Par exemple, ils arrivent bien à se servir de MS Word… et ça, c'est pas facile !
[^] # Re: Enigmail
Posté par lolop (site web personnel) . Évalué à 5.
Ils savent saisir un texte sous MS-Word ou sous LO, cliquer pour changer l'alignement, la mise en gras ou italique…. Mais de là à savoir vraiment utiliser ces outils, il y un gap.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
# Ne pas réfléchir seul dans son coin
Posté par gouttegd (site web personnel) . Évalué à 8.
Bon, je ne suis pas particulièrement fan de l’approche qui consiste à tout masquer à l’utilisateur en lui disant « clique sur ce gros bouton et tu seras secure, fais-moi confiance ».
Mais si tu veux te pencher sur la question « comment rendre OpenPGP plus abordable », quelle que soit la méthode je t’invite à ne surtout pas faire ça seul dans ton coin.
Un bon endroit pour en discuter sont les listes de discussion du projet GnuPG. D’une part, c’est probablement l’implémentation la plus répandue d’OpenPGP, et d’autre part, la question y est déjà régulièrement abordée.
Et non, contrairement à ce qu’on peut lire parfois, les développeurs de GnuPG (et des programmes qui tournent autour comme Enigmail) ne sont pas enfermés dans une tour d’ivoire d’où ils ignorent les critiques concernant l’utilisabilité de leurs logiciels. S’ils n’ont pas forcément de solutions miracles (c’est un sujet difficile, surtout quand on veut apporter de vraies réponses et pas de la poudre aux yeux), ils y réfléchissent quand même. (Oui, je sais, il n’y a rien de nouveau sur cette page depuis 2012. Mais il y a toujours du travail de fait sur le code du côté de GnuPG.)
# S/MIME
Posté par Jiehong (site web personnel) . Évalué à 3.
S/MIME qui marche presque partout (mais pas toujours très bien), pourrait aussi être un premier pas. On pourrait imaginer qu'à l'installation un client mél demande si tu as déjà un certificat (et te laisse chercher sur une liste de serveurs publics), ou te demande d'en créer un.
Mais c'est le même souci qu'avec ssl : qui te file un certificat (attaque de l'homme du milieu), et comment.
[^] # Re: S/MIME
Posté par gouttegd (site web personnel) . Évalué à 5.
S/MIME est effectivement pris en charge nativement par davantage de clients qu’OpenPGP (du moins sur le desktop — pas sûr que beaucoup de clients mobiles prennent en charge l’un ou l’autre), mais :
– à l’usage, les interfaces utilisateurs pour S/MIME ne sont pas plus intuitives que celles pour OpenPGP ; leur seul avantage est qu’il n’y a pas de greffon à installer, mais je ne pense pas que ce soit l’installation de Enigmail qui pose le plus de difficultés aux gens ;
– ce n’est pas plus adapté qu’OpenPGP à l’utilisation dans un webmail ;
– surtout, ça ne change rien au problème majeur d’utilisabilité que représente la distribution des clefs.
Mettons qu’Alice vient de générer un certificat (OpenPGP ou X.509, peu importe, le problème est le même ; peu importe aussi qu’elle ait fait ça consciemment ou que son client de messagerie s’en soit chargé sans intervention de sa part). Comment le diffuse-t-elle auprès de ses contacts ? Et quand elle veut écrire à Bob, comment peut-elle obtenir automatiquement le certificat de Bob ?
Les serveurs de clefs sont une réponse possible, mais pas nécessairement la meilleure, surtout si l’on veut que tout soit automatisé : il peut y avoir douze mille clefs au nom de Bob bob@example.com sur les serveurs de clef, une intervention de l’utilisateur sera forcément nécessaire pour savoir laquelle choisir.
S/MIME est surtout utilisé dans un environnement restreint et contrôlé (dans une grande entreprise par exemple), où ces questions peuvent être résolues par une politique appropriée. Par exemple, lorsqu’on crée le compte du nouvel employé Bob, on génére automatiquement un certificat signé par la CA interne à l’entreprise. Le client mail d’Alice a été configuré par les administrateurs (avec interdiction pour Alice d’en utiliser un autre, d’ailleurs elle n’a pas les droits root sur sa machine) pour, d’une part, aller chercher automatiquement le certificat de Bob sur l’annuaire LDAP de la boîte, et d’autre part, faire confiance à la CA interne.
C’est cool, ça marche tout seul (enfin, du point de vue d’Alice et Bob, parce qu’en réalité, ça ne marche que parce qu’il y a un service IT derrière pour faire tout le boulot), mais ce n’est pas transposable au grand public.
[^] # Re: S/MIME
Posté par flan (site web personnel) . Évalué à 5.
Ça dépend des clients. Sur OS X avec Mail, voici comment ça se passe : on te fournit un fichier .pem (contenant ta clef et ton certificat). Tu double-cliques dessus, ça te l'enregistre dans ton trousseau (avec les autres mots de passe, certificats, et autres clefs privées).
Ensuite, quand tu vas écrire un mail, tu auras une icône de signature, active si tu utilises un compte mail pour lequel tu possèdes un certificat.
Si tu as la clef publique de ton destinataire dans ton trousseau (donc si tu as déjà reçu un mail de sa part, ou si tu l'as mise autrement), l'icône de chiffrement sera activée.
# Un guide à défaut de mieux
Posté par nico4nicolas . Évalué à 4.
Sans répondre à la question, la FSF a mis en ligne un petit guide pour chiffrer ses courriels. Traduit par april et framasoft, le guide d'autodéfense est disponible en français. Loin de résoudre le problème, il propose des explications claires sur la mise en place du chiffrement des courriels. Cela ne permettra pas à un grand nombre d'adopter le chiffrement mais peut aider ceux qui se soucient déjà de préserver leurs échanges à mettre en place leur clé GPG.
# Clarté et complexité
Posté par Zorro (site web personnel) . Évalué à 4.
Si tes explications à tes amis sont aussi claires que ton post, alors oui, en effet, il y a problème, mais ça ne vient peut-être pas des implémentations de GPG, contrairement à ce que tu sembles croire.
Déjà, GnuPG/PGP, c'est JUSTEMENT pas de la crypto symétrique, mais asymétrique, c'est le principe même des clés publiques/privées.
Ensuite, ben la sécurité, c'est compliqué, c'est comme ça. Les ignorants ne sont pas libres.
[^] # Re: Clarté et complexité
Posté par nico4nicolas . Évalué à 5.
Nous sommes tous ignorants dans presque tous les domaines, rares sont les domaines dans lesquels un être peut être savant. Je ne suis savant de rien, pire, je suis ignorant de mes ignorances, n'ai je pas le droit d'être libre ? N'est-ce pas l'accès au savoir commun qui est promu par le logiciel libre ? Pour le bien de notre commune humanité, je suis convaincu que les savants doivent éduquer les ignorants ou, à défaut, les aider à l'utiliser les fruits de la connaissance. Je me trompe sans doute puisque je suis ignorant.
[^] # Re: Clarté et complexité
Posté par Ellendhel (site web personnel) . Évalué à 4.
La question d'utiliser du chiffrement n'est pas simplement une question de connaissance ; non seulement il faut savoir comment les choses fonctionnent (et fonctionnent correctement, sans faire d'erreur) mais de plus il faut l'appliquer de manière consistante. Chiffrer ou signer ses messages ne devrait pas être une action ponctuelle, mais devrait être appliqué systématiquement, tout le temps.
Et il ne faut pas se leurrer : quelque chose de compliqué et qui requiert un effort constant n'est pas très vendeur. D'autant plus que pour beaucoup de personnes, un ordinateur est censé effectuer les besognes compliquées et répétitives à leur place ; donc demander de faire des efforts supplémentaires en utilisant un ordinateur est presque contradictoire.
Je reste d'accord : les pratiques autour du chiffrement sont claires et définies, mais les outils ne sont "pas à la hauteur". Je sais que des projets existent pour améliorer cela, mais il reste du chemin à faire…
[^] # Re: Clarté et complexité
Posté par nico4nicolas . Évalué à 1.
Je suis d'accord sauf avec le premier point sur la connaissance, il ne faut pas avoir la connaissance du fonctionnement pour utiliser une chose. Imaginez une seconde qu'il faille savoir comment l'Internet fonctionne pour le parcourir… Je ne sais pas comment fonctionne la mécanique de ma voiture mais j'ai le droit de la conduire (plutôt mal d'ailleurs). Ma vision des choses me pousse à croire qu'apprendre à utiliser un outil est suffisant mais, encore une fois, j'ai peut être tort.
[^] # Re: Clarté et complexité
Posté par gouttegd (site web personnel) . Évalué à 7.
Bien sûr que si. Mais le fait d’avoir ce droit n’implique pas nécessairement que tu n’as pas d’effort à faire pour en jouir.
« Avoir le droit » et « avoir la capacité » sont deux choses complètement indépendantes.
À conditions que les « ignorants » (je ne fais que reprendre ce terme, je ne cautionne pas son usage dans ce contexte — pas plus que l’usage de « savants » d’ailleurs) le veuillent. Or en l’espèce, et à l’exception des quelques personnes que j’ai croisées lors de crypto-parties, la plupart des gens ne veulent pas avoir à apprendre quelque chose. Au maximum, ils veulent bien avoir à installer un logiciel (comme on installe un anti-virus) et c’est tout.
Malheureusement, il ne suffit pas d’installer un programme de crypto (GnuPG ou un autre) pour être magiquement en sécurité. Ce serait cool si c’était aussi simple, mais ça ne l’est pas. Et faire croire le contraire aux gens ne serait pas leur rendre service à mon avis. (Ça n’interdit pas évidemment d’améliorer les outils existants pour les rendre plus abordables, mais on ne pourra jamais les rendre complètement transparents.)
En attendant, je suis complètement disposé à aider quiconque veut se mettre à protéger ses communications.¹ Mais ① il faut le vouloir (je ne vais pas aller chercher ceux qui disent « m’en fous, j’ai rien à cacher ») et ② il faut y mettre du sien (je ne vais pas tenir la main à ceux qui disent « ouh là, c’est trop compliqué ton truc » au bout de trois secondes d’explication).
(Le dernier paragraphe est d’ailleurs applicable à toutes les choses pour lesquelles je suis prêt à aider les gens, pas seulement aux chiffrements des emails.)
¹ J’ai d’ailleurs dans les cartons le projet d’écrire une série de journaux autour de l’utilisation de GnuPG et OpenPGP, dans la foulée de ma dépêche sur la carte OpenPGP. (Voilà, maintenant que c’est annoncé, je ne vais plus pouvoir me défiler.)
[^] # Re: Clarté et complexité
Posté par Zylabon . Évalué à 4.
Tout à fait, et c'est exactement pareil dans le monde physique. Si un utilisateur de coffre fort ne comprend pas son coffre ne lui apporte aucune sécurité s'il laisse la clef dans la serrure, alors on peut soit faire un coffre qui se met à hurler si on laisse la clef dans la serrure, et il se contentera de la poser dessus, ou, il peut apprendre comment ça marche, quel sont les attaques possibles et quelle mesure permet de s'en protéger.
La différence c'est que les gens ont une compréhension intuitive du contexte dans lequel un coffre fort apporte une sécurité (encore que…), et l'utilisent alors raisonnablement.
Si un utilisateur ne comprend pas le principe de la crypto asymétrique, quel que soit le logiciel qui sera mis en place, ça ne marchera pas. Une solution serait peut être de permettre à l'utilisateur d'appliquer sa connaissance du monde physique au chiffrement. Comme un truc graphique avec des coffres qui ont une porte pour mettre des choses dedans et une porte pour les retirer, et les clefs pourraient être des fichier à glisser-déposer ?
Please do not feed the trolls
[^] # Re: Clarté et complexité
Posté par nico4nicolas . Évalué à 2.
En ce qui concerne "l'ignorance", je ne suis pas convaincu par ces arguments. Pour moi, l'apprentissage de l'outil est un effort déjà suffisant de la part de "l'ignorant" (dont je fais partie) pour avoir accès à la jouissance de la connaissance si l'outil est disponible. Pour reprendre l'analogie du coffre fort, la personne l'utilisant n'a pas besoin de connaitre le fonctionnement du mécanisme de sécurité pour l'utiliser, connaitre l'outil permettant la fermeture et l'ouverture du coffre devrait être nécessaire. Pour te rejoindre, si le coffre fort est mis à disposition et que le l'outil de fermeture/ouverture du coffre est expliqué, il appartient à la personne de l'utiliser si cela lui semble nécessaire ou utile.
Par contre, pour l'attitude adoptée vis-à-vis des personnes qui ne montreraient aucune volonté, je respecte et ne remet pas en cause le comportement que tu dis avoir.
[^] # Re: Clarté et complexité
Posté par gouttegd (site web personnel) . Évalué à 5. Dernière modification le 23 mars 2015 à 15:45.
Pas toujours (mais ça dépend probablement beaucoup du domaine, et de ce que fait l’outil).
Un problème à ne connaître que l’outil sans avoir aucune idée des concepts sous-jacents, c’est que lorsque l’outil te demande de faire un choix, tu ne peux pas répondre correctement (tu ne comprends même pas la question !) et tu es obligé de demander à Bibi.¹ Donc tu n’es pas autonome, et tu n’es pas libre.
Quand ça arrive, Bibi préfère expliquer les tenants et aboutissants de la question (brièvement, il ne s’agit pas de faire un cours non plus) et suggérer la bonne réponse, plutôt que de dire sèchement « réponds-lui ça ».
Et j’ai constaté que mes interlocuteurs avaient plutôt tendance à apprécier que je prenne le temps de leur expliquer, au lieu de faire comme si je pensais qu’ils sont trop cons pour comprendre. (Ou alors, ils sont trop polis pour m’avouer que je leur casse les bonbons avec mes explications, c’est possible aussi. :-° )
¹ Parfois, ce problème serait évitable. Les logiciels posent probablement trop de question alors qu’un comportement par défaut (débrayable pour les utilisateurs avancés) conviendrait probablement à la plupart des gens (GnuPG progresse dans ce sens, avec par exemple la nouvelle option
--quick-gen-keyintroduite dans GnuPG 2.1, qui génère une nouvelle paire de clef sans rien demander à l’utilisateur). Mais tu auras toujours des cas où le logiciel aura besoin d’une intervention éclairée de l’utilisateur.[^] # Re: Clarté et complexité
Posté par oinkoink_daotter . Évalué à 3.
Y a un peu des deux en fait. Ce que voit l'utilisateur oui, c'est de l'asymétrique, mais en vrai, une clef de session symétrique est générée pour chiffrer les données et c'est cette clef qui est chiffrée de façon asymétrique pour les utilisateurs.
[^] # Re: Clarté et complexité
Posté par gouttegd (site web personnel) . Évalué à 3.
Alors, je sais que je viens de dire que je préférais expliquer les choses aux utilisateurs, mais là pour le coup, ça me semble relever du détail que Monsieur Michu n’a pas absolument besoin de connaître (même si je me ferais un plaisir de lui expliquer s’il me le demande). L’utilisateur moyen ne manipule jamais les clefs de session (et même parmi les « utilisateurs avancés » il ne doit pas y en avoir beaucoup qui ont déjà utilisé
--show-session-keyet--override-session-key), il peut ignorer jusqu’à leur existence, ce n’est pas ça qui va l’empêcher de se servir correctement de GnuPG.Il y ad’autres notions plus importantes à appréhender avant d’en arriver là à mon avis (au hasard, la distinction entre trust et ownertrust, qui d’expérience pose beaucoup de problèmes de compréhension aux débutants).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.