Journal [GPG pour les nuls] C'est pour quand ?

Posté par . Licence CC by-sa
24
21
mai
2011

Bonjour à tous, voilà, cette question me tarabuste depuis très très longtemps (je devais avoir 12 ans à l'époque… et oui.)

Il s'agit de la sécurité des communications, les communications électroniques en particulier. Et dans les communications électroniques, l'email. Car l'email est très particulier en ce sens que j'imagine que c'est un des des moyens de communication électronique les plus utilisés (voire le plus utilisé).

Concernant la sécurité des communications électroniques, je pense que tout le monde a entendu parler de PGP (Pretty Good Privacy) et de GPG (remplacement GNU pour PGP si je ne m'abuse).

Je pense que je suis absolument convaincu que le droit à la confidentialité de ses communications est un droit humain fondamental. Plus que fondamental. Je dirai même que c'est un besoin vital, tout comme la protection de la vie privée et de sa sécurité.

Ayant souligné l'importance de la confidentialité des communications, j'en viens au nœud du problème : GPG pour les nuls existe-t-il ? Voilà mon problème. Je voudrai bien pouvoir assurer la confidentialité de mes communications électroniques. Mais comme la plupart des tutoriels sur GPG le disent, cela nécessite l'accord de à la fois Alice et Bob pour fonctionner.

Ma première question a donc essentiellement un but rhétorique : qui parmi les lecteurs de ce site a plus de 50% de ses contacts e-mail qui utilisent PGP et/ou GPG ? J'ai l'intuition, corrigez moi si je me trompe, que l'usage de PGP et de GPG reste extrêmement confidentiel, cantonné à quelques développeurs debian et au milieu geek. Pour ma part, j'utilise linux et ses dérivés depuis quelques temps, mais je n'ai jamais, jamais fait usage d'une clé GPG publique pour signer mes messages. C'est également un peu par pression culturelle, puisque la majorité de mes contacts fonctionne de manière identique.

D'où ma seconde question : quand est-ce que GPG sera vraiment à portée du grand public ? Cela m'ammène à formuler une critique au sujet de l'implémentation de GPG dans les distributions linux. Je n'ai jamais vu un client mail fonctionnant out-of-the-box, proposer de générer une clé GPG automatiquement, de manière simple et pérenne, ni même de le faire par défaut. Alors, cher journal, quelle est la marche à suivre ? Comment chiffrer automatiquement et par défaut ses messages ? Le graal dont je parle est-il réellement inaccessible, ou est-ce que je fais une erreur d'appréciation ?

En conclusion, j'aimerai poser ces deux questions simples : avez vous l'idée, ou connaissez vous, un logiciel qui prenne l'utilisateur par la main pour utiliser gpg ? Ma seconde question est de savoir ce que vous pensez de mon texte. Finalement sa rédaction m'aura au moins fait réfléchir au fait que c'est important de signer ses messages, même en dépit de la situation actuelle qui est en gros « tous les emails en clair pour tout le monde » .

Je vous souhaite un bon week-end.

Cordialement.

  • # même réflexion

    Posté par . Évalué à 1.

    j'avais posé ce genre de question il y a quelques temps (près de 2 ans) :

    https://linuxfr.org/users/farvardin/journaux/hadopi-2-ne-passera-pas-comme-une-carte-postale-%C3%A0-la-poste

    Malheureusement c'est resté un voeu pieux, déjà parce que la situation est restée la même du côté de mes correspondants, et surtout parce que j'utilise de moins en moins la messagerie électronique, et les rares fois que je le fais, c'est une fois avec laposte.net, une autre fois avec gmail ou yahoo, alors cela ne serait sans doute pas pratique de gérer 3 trousseaux de clés.

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: même réflexion

      Posté par . Évalué à 7.

      cela ne serait sans doute pas pratique de gérer 3 trousseaux de clés.

      Pourquoi 3 trousseaux de clefs ? Soit vous créez 3 paires de clefs publiques et privées (une pour chaque adresse), soit vous en utilisez une partagée, mais c'est dans le même trousseau et accessible facilement dans GPG. Dans tous les cas, les clefs de vos destinataires ne sont pas en triple exemplaire. http://openpgp.vie-privee.org/pingouin20010917-1.txt

    • [^] # Re: même réflexion

      Posté par (page perso) . Évalué à 6.

      On peut ajouter autant d'adresses mail qu'on le souhaite, sur une paire de clés unique.

  • # courrier web

    Posté par . Évalué à 8.

    De plus en plus de gens utilisent leur courriel par une interface web, ce qui rend l'utilisation de OpenPGP ¹ encore plus difficile, car cela nécessiterait des extensions au navigateurs.

    ¹ le standard partagé par PGP et GPG auquel vous faites inconsciemment référence en écrivant "PGP/GPG"

    • [^] # Re: courrier web

      Posté par (page perso) . Évalué à 4.

      De plus en plus de gens utilisent leur courriel par une interface web, ce qui rend l'utilisation de OpenPGP ¹ encore plus difficile, car cela nécessiterait des extensions au navigateurs

      <orwell>
      Mouh naah encore un grincheux qui n'a pas compris que les applications dans le browser c'est mieux, c'est tellement polyvalent un browser!
      </orwell>

      • [^] # Re: courrier web

        Posté par . Évalué à -1.

        Oué mais c'est pas polyvalent pour les chevaux.

        • [^] # Re: courrier web

          Posté par . Évalué à 2.

          Je te trouve bien cavalier pour écrire ça

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: courrier web

      Posté par . Évalué à 3.

      De plus en plus de gens utilisent leur courriel par une interface web, ce qui rend l'utilisation de OpenPGP ¹ encore plus difficile, car cela nécessiterait des extensions au navigateurs.

      Ceci d'autant plus que la seule extention pour firefox, n'est plus maintenue, et déconne semble il (tous les messages sont marqués comme n'ayant pas pu être identifés).

      Mais, avec un peu de boulot, cela pourrait être facilement améliorer, de même que l'utilisabilité (insertion d'un lien dans les menus du webmail, ou detection par le webmail de l'extention et proposition d'un item de menu en plus)

      • [^] # Re: courrier web

        Posté par . Évalué à -1.

        En cherchant bien, ça devrait être possible de trouver un webmail qui le « fait » d'autant plus que le webmail est bien une chose qui pourrait permettre de démocratiser le chiffrement des messages.

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: courrier web

          Posté par . Évalué à 4.

          Ce n'est pas au webmail de le faire.
          Si le chiffrement est fait par le serveur, alors le contenu en clair est transmis au moins au serveur web. Si le chiffrement est fait purement en Javascript, par un script fourni par le webmail, alors il faut quand même vérifier à chaque fois que le Javascript n'est pas malicieux et chiffre bien avant de transmettre au serveur web (et ne pas tomber dans le "on ne fait qu'analyser votre courrier pour vous proposer des publicités ciblées"). Si au contraire l'implémentation se trouve dans le navigateur, l'utilisateur a plus de contrôle.

          • [^] # Re: courrier web

            Posté par (page perso) . Évalué à 2.

            Si le chiffrement est fait par le serveur, alors le contenu en clair est transmis au moins au serveur web.

            Ce serait toujours mieux que rien du tout : seul ton serveur webmail (qui n'est pas forcément ton serveur SMTP ou IMAP...) a accès, c'est mieux que ton serveur + les serveurs intermédiaires + le serveur du destinataire.

            L’émetteur a alors toujours 100% le contrôle sur sa signature (avec un contrat avec l'hébergeur de son webmail à qui il délègue un pau)

            • [^] # Re: courrier web

              Posté par . Évalué à 1.

              non, ce n'est pas très sérieux.
              Si tu ne chiffres pas sur ton poste (1), comme BFG que tu cites le dit, "alors le contenu en clair est transmis au moins au serveur web", ce qui invite à comprendre que l'empreinte chiffrée du corps du mail (la signature) n'est pas déjà présente, et ça, ça va pas... Si c'est le serveur de webmail qui signe pour toi, il le fait avec sa clé privée, ça ne garanti pas ton identité d'auteur ni l'intégrité du message transmis entre toi et le serveur de webmail (or l'intégrité est garantie par une signature !, cf ici).

              (1)
              par un appel au code GPG que tu as parmi tes applications installées, paquet de dépôt officiel, ou version officielle du logiciel, c'est mieux qu'avec du javascript dans le navigateur, BOF (hein...) !
              De plus, pour mémoire, c'est juste une empreinte du corps du mail qui est chiffrée et produit la signature, l'ensemble peut transiter en clair jusqu'au destinataire, il n'est pas ici question de protéger le contenu des propos échangés par chiffrement (par la clé privée cette fois).

              • [^] # Re: courrier web

                Posté par . Évalué à -1.

                Lol, je me suis vautré, à la fin de mon commentaire, il faut lire :
                "(...) il n'est pas ici question de protéger le contenu des propos échangés par chiffrement (par la clé publique du destinataire)."

                Je me suis vautré alors que je viens d'écrire un commentaire où je critique justement l'usage erroné (dans le journal) de l'expression "clé publique" alors qu'il s'agit de clé privée pour signer un contenu numérique.

              • [^] # Re: courrier web

                Posté par . Évalué à -1.

                Je me reprends : l'intégrité est garantie par la signature... oui si l'algo de génération de l'empreinte est solide. Pas SHA-1...

                Or GPG laisse libre le choix de cet algo. Pour une bonne sécurité, il vaut mieux taper directement dans du SHA-512.

              • [^] # Re: courrier web

                Posté par (page perso) . Évalué à 4.

                "alors le contenu en clair est transmis au moins au serveur web"

                Non si ton webmail est en HTTPS (bon, faut bien gérer tes CA racines genre virer les CA tunisiens ;-) )

                Si c'est le serveur de webmail qui signe pour toi, il le fait avec sa clé privée,

                Non si tu stockes ta clé privée sur le serveur webmail, ce sera signé avec ta clé.

                ça ne garanti pas ton identité d'auteur

                Pas plus que si tu a GPG sur ta machine tu sais... Tu ne fais "que" rajouter une personne de confiance dans la chaîne (que tu peux contrôler), ce c'est qu'une parmi tant d'autres (l'admin de ta machine, ton petit frère qui a accès à ta machine, toi qui te prend un key logger...). GPG garanti un certain niveau de sécurité, mais ça reste dans tous les cas léger (GPG ne fait rien contre la violation d'intégrité de ta machine... Donc tu dois faire confiance à qui peut modifier ta machine, toi compris)

                Quitte à me répéter, j'ai juste dit que ce n'est pas la panacée, mais c'est mieux que de faire confiance aux serveurs que tu ne contrôles pas du tout (intermédiaires FAI etc... serveur destinataire), ton webmail il peut très bien être sur ton serveur à toi (ou à qui tu délègues avec confiance le boulot) que tu contrôles. Après, tu peux dire "les webmails, qu'ils crèvent c'est pas secure", mais les utilisateurs répondront juste "GPG qu'il crève c'est pas utilisable avec les webmails".

                • [^] # Re: courrier web

                  Posté par . Évalué à -1.

                  il y a moyen de faire de l'authentification forte (cumulant au moins deux éléments ou « facteurs » d'authentification), y compris avec GPG. Cela limite déjà le risque de vol de clé.

                  Au passage, merci KISS (le fameux principe "Keep it simple, stupid" qui invite les développeurs à produire des logicielsn sachant prendre en entrée du texte et en produire en sortie, pour enchainer facilement des programmes avec le "pipe" ("|") dans l'écriture d'une ligne de commande dans la console).

                  Même avec une interface graphique, on doit pouvoir faire ça, aujourd'hui, non ?
                  Ce genre de principe, ou approchant est déjà mit en oeuvre, y a des logiciels pour automatiser ça, des tutoriaux existent. J'ai pas les références sous le coude à l'instant, mais une autre moule va nous donner un lien, j'imagine :-)

                  Imagination "fertile" pour mise en oeuvre compréhensible : tu dois écrire une "phrase de passe" (passphrase en anglais) pour lire une partition chiffrée sur une clé USB qui contient ta clé privée GPG comme d'autres clés de tout type que tu utilises à l'occasion.

                  En toute logique, à moins que tu héberges ton propre Webmail à toi (seul), il n'est jamais aucunement question que tu communiques ta clé privée à un quelconque serveur tiers, ni que personne ne le fasse. Tu peux partager une signature avec un collectif d'auteurs, mais mettre ta clé privée à disposition d'un serveur tiers... Enfin chacun fait ce qu'il veut, lol.

                • [^] # Re: courrier web

                  Posté par (page perso) . Évalué à 2.

                  Tu ne fais "que" rajouter une personne de confiance dans la chaîne

                  On est bien d'accord, mais en pratique ça casse un peu toute la sécurité qu'offrirait OpenPGP.

                  Prenons le cas simple de deux utilisateurs ayant chacun un webmail avec OpenPGP: alice@example.com et bob@server.net. Si Alice envoie un message à Bob, on va avoir les communications suivantes:

                  • alice -> webmail.example.com: pas chiffré
                  • webmail.example.com -> mx.server.net: chiffré
                  • webmail.server.net -> bob: pas chiffré

                  En l'occurrence, on a 4 entités dans la communication et tous les 4 ont accès au message non chiffré.

                  Alors, bien sûr, cela protège le message entre example.com et server.net, mais il suffit que la communication SMTP soit chiffrée par SSL pour obtenir le même résultat.

                  • [^] # Re: courrier web

                    Posté par (page perso) . Évalué à 2.

                    On est bien d'accord, mais en pratique ça casse un peu toute la sécurité qu'offrirait OpenPGP.

                    Oui, ça enlève un peu de sécurité, mais pas tant que ça. J'ai déjà dit maintes fois que c'est mieux que rien (et pas que c'est pareil) et j'ai déjà dit qu'au niveau sécurité ça ne changeait que très peu (parce que à ce niveau, je dirai que ne pas chiffrer ta partition et ne pas avoir la garantie - que tu n'as jamais - qu'il n'y a pas de keylogger sur ta machine "casse un peu toute la sécurité qu'offrirait OpenPGP" aussi). Tu chiffres ta partition j'espère pour pouvoir dire qu'OpenPGP t'assure tout la sécurité?

                    mais il suffit que la communication SMTP soit chiffrée par SSL pour obtenir le même résultat.

                    D'une le "il suffit" sur le SSL, tu l'as souvent? Chez moi, non, même que personne ne le fait.
                    De deux, le fait que Bob utilise un webmail n'est pas mon problème
                    De trois, tu oublie dans l'histoire que webmail != serveur SMTP et webmail != serveur IMAP. Tu oublies 2 entités poru faire croire que c'est inutile, mais ces entités existent et ne sont pas forcément propriété de l'hébergeur du webmail.
                    Sans oublier que tu oublie l'hébergeur de ta machine (ta maman qui passe dans ta chambre et te met un keylogger sera moisn rare que ton hébergeur de webmail qui se fait prendre la clé, dans les deux cas tu as une entité hébergeante). Des personnes "de confiance", on en a partout, tu n'as pas encore dit pourquoi tu ferais pas confiance à ton hébergeur de webmail, un hébergeur de webmail n'est pas forcément Google etc... Mais peut aussi être ton serveur Dedibox à 15€/mois dont tu es l'admin et donc tu rajoutes personne dans la chaine de confiance.

                    Si on suit ta logique, on peut dire que comme tu n'as pas la garantie d'avoir un keylogger sur ta machine (à moi que tu sois omniscient...), OpenPGP ne sert à rien du tout. C'est faux. Ca sert, à plus ou moins grande échelle (et personne de confiance) suivant où tu mets ta clé et qui/quoi peut y accéder.

                    Une chose est sûre : vu que de plus en plus de monde utilise les webmails (soit en tant qu'unique solution, soit en tant que solution "en nomadisme"), ne rien proposer pour eux n'aura comme seul que d'avoir personne à part des geeks illuminés qui utiliseront la signature et/ou chiffrement des mails. Dommage...

                  • [^] # Re: courrier web

                    Posté par . Évalué à 2.

                    Je ne comprends pas pourquoi les échanges entre le tiers et le webmail ne pourraient être chiffrés, ne seraient ce que par SSL. C'est sûr qu'il faut avoir confiance dans son fournisseur dans ce cas.

                    Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

        • [^] # Re: courrier web

          Posté par (page perso) . Évalué à 3.

          En cherchant bien, ça devrait être possible de trouver un webmail qui le « fait » d'autant plus que le webmail est bien une chose qui pourrait permettre de démocratiser le chiffrement des messages.

          Tout à fait. Horde / IMP le fait. Par contre, ça nécessite d'héberger soi-même son serveur pour y déposer ses clefs en confiance, ce qui limite la démocratisation.

          • [^] # Re: courrier web

            Posté par . Évalué à 3.

            On pourrait imaginer un webmail qui stocke les clefs dans localStorage (après les avoir fait générer côté client, tant qu'à faire). Non?

  • # Le problème ne vient pas des logiciels

    Posté par (page perso) . Évalué à 9.

    je pense que tout le monde a entendu parler de PGP

    Tu veux dire « tout le monde sur ce site », je suppose ? Parce que sinon, non, je doute fort que ceux ayant entendu parler de PGP soient très nombreux.

    Ma première question a donc essentiellement un but rhétorique : qui parmi les lecteurs de ce site a plus de 50% de ses contacts e-mail qui utilisent PGP et/ou GPG ?

    Pas moi, en tout cas. Ça doit plutôt tourner aux alentours de 0,5 %.

    je n'ai jamais, jamais fait usage d'une clé GPG publique pour signer mes messages

    En revanche moi je les signe systématiquement, depuis plusieurs années.

    Ce que j’aimerais qu’il se passe : quelques-uns au moins de mes interlocuteurs finissent par remarquer la présence systématique d’une signature OpenPGP et commencent à se poser quelques questions — voire même, soyons fous, décident finalement de s’y mettre à leur tour.

    Ce qu’il s’est passé jusqu’à présent : dans 99,999 % des cas, rien du tout. Dans 0,001 % des cas, « j’arrive pas à ouvrir ta pièce jointe signature.asc, tu peux me la renvoyer ? »

    quand est-ce que GPG sera vraiment à portée du grand public ?

    Quand les clients de messagerie grand public (autrement dit, ceux disponibles pour Windows) sauront le gérer, je suppose (par exemple, en marquant explicitement le message comme signé numériquement au lieu d’afficher la signature détachée comme une pièce jointe quelconque).

    Je suppose qu’il faudrait également que les webmails (GMail & Co.) sachent le gérer aussi, vu le nombre de personnes de mon entourage qui n’ont jamais utilisé un client de messagerie « lourd » — et comment gère-t-on un trousseau de clefs et la base de confiance associée depuis un webmail, ça je n’en ai aucune idée…

    Je n'ai jamais vu un client mail fonctionnant out-of-the-box, proposer de générer une clé GPG automatiquement, de manière simple et pérenne, ni même de le faire par défaut.

    Non, mais
    – à part la génération de la clef, beaucoup de clients mails se débrouillent très bien, il suffit généralement d’entrer l’identifiant de sa clef, après quoi les fonctions de signature et de chiffrement sont accessibles d’un clic ;
    – pour la génération de la clef (et toutes les autres manipulations), il y a aujourd’hui des interfaces dédiées qui, je trouve, sont assez bien fichues (du moins pour GNU/Linux, pour Windows, je ne sais pas).

    Je ne pense pas que le frein vienne des logiciels. À mon avis, c’est plutôt que la plupart des utilisateurs s’en fichent et ne consacreront jamais un effort à ça quand bien même on réduirait l’effort à fournir au strict minimum, et pour ça je ne vois pas grand’chose à faire.

    [HS]
    Exactement comme ils se fichent de prendre la peine de sauvegarder leurs données, alors qu’il y a des logiciels qui font ça très bien et très facilement aujourd’hui. J’en ai encore eu confirmation la semaine dernière : ça faisait des mois que je disais à un collègue que ce n’était pas prudent de conserver toutes ses données sur un seul disque dur, il ne m’a jamais écouté ; le disque en question vient de rendre l’âme. Qui faut-il blâmer :
    – les constructeurs, pour faire des disques durs qui osent tomber en panne ?
    – les développeurs du système d’exploitation (Mac OS X en l’occurence), pour ne pas proposer d’outils de sauvegarde assez simples (ben oui, Time Machine, c’est compliqué quand même), ou pour ne pas les mettre assez en avant ?
    – moi, pour ne pas avoir été assez persuasif ?
    – l’utilisateur qui n’a pas voulu faire le moindre effort, alors même qu’il était averti du danger ?

    Ça n’a rien à voir, certes, mais si les utilisateurs n’attachent même pas d’importance à l’intégrité de leurs données (y compris celles dont dépend leur travail), je ne les vois pas attacher de l’importance à la confidentialité de leurs échanges…

    • [^] # Re: Le problème ne vient pas des logiciels

      Posté par (page perso) . Évalué à 2.

      quelques-uns au moins de mes interlocuteurs finissent par remarquer la présence systématique d’une signature OpenPGP et commencent à se poser quelques questions — voire même, soyons fous, décident finalement de s’y mettre à leur tour.

      La seule question qu'ils se posent est "mais bon dieu, il fait chier avec ses mails avec du chinois avant et après le contenu en français, il pourrai pas virer sa merde?".

      Déjà, ce sera un jour peut-être mieux (et je m'y mettrai peut-être) le jour où la signature ne pourrira pas l'écran du destinataire ("-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1" bla bla bla et/ou signature.asc). Il y a des headers pour les mails, non affichés, ce n'est pas fait pour les chiens, en attendant l’utilisateur de PGP est juste vu comme un chieur...

      Si la technologie ne décolle pas du tout, c'est aussi pour ce genre de choses où la technologie pourrit à fond la vue des gens... Pour le moment, je n'utilise pas PGP (alors que ça m’intéresse de le faire) car je sais que je vais pourrir la vue de mes destinataires. Donc : quand une technologie de signature réellement utilisable?

      • [^] # Re: Le problème ne vient pas des logiciels

        Posté par (page perso) . Évalué à 10.

        Déjà, ce sera un jour peut-être mieux (et je m'y mettrai peut-être) le jour où la signature ne pourrira pas l'écran du destinataire ("-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1" bla bla bla et/ou signature.asc)

        Ben justement, la signature détachée, c’est fait pour ça, et les bons clients de messagerie la supportent depuis déjà pas mal de temps en remplacement de la signature dans le corps du texte.

        Concrètement, le message est alors de type multipart/signed, avec une partie contenant le corps du message et une partie contenant la signature.

        Les très bons clients de messagerie reconnaissent ça et n’affichent que le corps du message en le marquant comme signé (en précisant si la signature est valide ou invalide — ou invérifiable si la clef publique de l’émetteur n’est pas disponible dans le trousseau de clefs).

        Les bons et moins bons clients de messagerie reconnaissent la partie contenant la signature comme une pièce jointe, ce qui peut être pénible j’en conviens mais ne crache pas autant à la gueule qu’un ----BEGIN PGP SIGNED MESSAGE-----. Il faudrait vraiment un très mauvais client de messagerie pour qu’une signature détaché « pourrisse l’écran du destinataire ». Je crois que même Outlook Express ne fait pas ça, c’est dire…

    • [^] # Un mot sur l'enjeu

      Posté par (page perso) . Évalué à 2.

      Ça n’a rien à voir, certes, mais si les utilisateurs n’attachent même pas d’importance à l’intégrité de leurs données (y compris celles dont dépend leur travail), je ne les vois pas attacher de l’importance à la confidentialité de leurs échanges…

      Et c'est très dommage, car si dans le cas des backups, le risque ne concerne qu'eux (ils perdront simplement leurs propres données), dans le cas du chiffrement des messages, il peut arriver des choses bien plus graves.

  • # My 2 cents

    Posté par (page perso) . Évalué à 5.

    Il me semble qu'avant de proposer un tel logiciel, il faut observer deux choses :

    • Madame Michu délaisse de plus en plus le client mail pour le webmail, et commence à délaisser le webmail pour le réseau social (ou plutôt LE réseau social : Facebook). Elle ne veut plus s'embêter à lancer une autre application que son browser qui lui permet d'accéder à son clicquodrome (bon sang comment on écrit ça... clicodrome ? clickodrome ?) en ligne sans reconfigurer quoi que ce soit.

    • Jusqu'ici, la seule tentative de faire du chiffrement asymétrique d'une manière suffisamment transparente pour que Madame Michu l'utilise qui a réussi, c'est SSL/TLS. Madame Michu échange de manière chiffrée des données avec le site de sa banque régulièrement, sans s'en rendre compte, certes, mais sans pester contre un truc de geek auquel elle ne comprend rien.

    La seule solution qui me vient alors à l'esprit actuellement, pour obliger Madame Michu à m'envoyer un e-mail chiffré, serait de mettre en place une interface web (similaire aux formulaires de contacts qu'on trouve sur les blogs, par exemple), avec connexion chiffrée HTTPS, dont le message serait automatiquement chiffré avec ma clé publique avant l'envoi.
    Reste à savoir comment je pourrais à mon tour envoyer un mail à Madame Michu de façon sécurisée... peut-être en lui créant un compte webmail sur mon propre site...mais cette conne serait fichue de perdre son mot de passe ou de le laisser traîner... Sans compter qu'elle n'ira jamais consulter ce webmail par elle-même.
    Ou alors il faudrait mettre en place quelque chose d'automatisé, chez elle. Mais là on rejoint l'objectif de la no-box/BeedBox/FreedomBox, si je ne m'abuse.

    Je ne sais pas si de telles propositions ont déjà été mises en application, si quelqu'un a des infos...

  • # GPG, OTR, TLS/SSL, SSH...

    Posté par (page perso) . Évalué à 6.

    • GPG permet de gérer l'authentification, l'intégrité et le chiffrement des courriels et des fichiers. Mais en fait il est peu utilisé, il est compliqué à utiliser (faut avoir compris le principe d'un réseau de confiance, générer sa clé, etc.), peu de clients de courriel lourds utilisés par le grand public le supportent et aucun ou quasi aucun des clients web utilisés par le grand public. Les clés publiques/privées GPG sont propres à GPG... (« approche décentralisée + utilisation plutôt pour experts »)

    • SSL/TLS : très utilisé par les serveurs web notamment (et les navigateurs). Problème : centralisation, autorités de confiance qui ne sont pas de confiance, autorité communautaire comme cacert.org qui ne perce pas vraiment, les navigateurs braillent de plus en plus forts sur les certificats auto-signés, etc. Les certificats ne sont facilement utilisables qu'avec votre apache/nginx en gros.

    • OTR : sympa pour la messagerie instantanée et l'IRC (encore que mon proxy IRC bip me pose problème de ce côté), via la libotr (marche notamment pour pidgin et xchat pour parler de ceux que j'ai testés). Les clés sont créées automatiquement, l'utilisateur n'a même pas à comprendre ce qu'il fait, c'est simple et efficace, au minimum ça chiffre ; après si les utilisateurs ne vérifient rien dans la chaîne de confiance, ça n'augmente pas leur sécurité, juste celles des autres (en augmentant la quantité de trafic chiffré). Les clés publiques/privées OTR sont propres à OTR...

    • SSH : les clés publiques/privées SSH sont propres à SSH

    A priori MonkeySphere essaie de permettre d'utiliser de façon plus indifférenciée les clés SSH et SSL.

    Je pense que le vrai souci est à ce niveau : déjà c'est compliqué d'expliquer le chiffrement, son intérêt, le principe d'une autorité de certif ou d'un réseau de confiance, etc. à des utilisateurs. Si en plus chaque usage, chaque protocole, chaque outil définit son format, ses clés, etc., ça ne perce pas. C'est la fragmentation des outils/usages qui est un vrai frein.

    Vous voyez vos parents utiliser une ou plusieurs paires de clés GPG, une ou plusieurs paires de clés OTR, des clés SSH clientes ou serveurs, des clés SSL, jongler avec, en utilisant plein de logiciels différents, en particulier les logiciels de leur choix (ceux que vous détestez donc :) ? La réponse est clairement non.

    • [^] # Re: GPG, OTR, TLS/SSL, SSH...

      Posté par . Évalué à 1.

      OTR, ce n'est pas tellement automatisé que ça permet au serveur de s'immiscer au milieu, comme mod_otr ?

      • [^] # Re: GPG, OTR, TLS/SSL, SSH...

        Posté par (page perso) . Évalué à 1.

        Ah ben évidemment, sans vérification directe de la clef du correspondant, on est à la merci des hommes au milieu…

        • [^] # Re: GPG, OTR, TLS/SSL, SSH...

          Posté par . Évalué à 2.

          Et pour vérifier la clef du correspondant, on est obligé de le rencontrer en personne avant ou bien l'on peut utiliser des intermédiaires de confiances qui auraient signé sa clef comme avec le "web of trust" pour OpenPGP ?

          • [^] # Re: GPG, OTR, TLS/SSL, SSH...

            Posté par (page perso) . Évalué à 1.

            On est obligé de l'avoir rencontré auparavant et d'avoir un secret partagé. Cela peut être un simple mot, une réponse à une question particulière, mais il en faut un. Il n'y a pas de réseau de confiance avec OTR.

            • [^] # Re: GPG, OTR, TLS/SSL, SSH...

              Posté par . Évalué à -2.

              Il me vient la considération que tu peux t'appuyer sur un réseau de confiance GPG comme suit :

              On a lu que "Les clés publiques/privées OTR sont propres à OTR...".
              on peut signer sa clé publique OTR avec sa clé privée GPG et qu'à l'autre bout d'un réseau de confiance GPG, quelqu'un appartenant à cette chaine soit un "intermédiaire de confiance" pour notre correspondant OTR, validant pour lui l'association de notre clé publique OTR avec notre couple de clés publiques/privées GPG.

              Et réciproquement par un principe identique...

              Hm ?

              • [^] # Re: GPG, OTR, TLS/SSL, SSH...

                Posté par (page perso) . Évalué à 2.

                Pourquoi faire simple quand on peut faire compliqué ?

                À ce compte-là, autant utiliser uniquement PGP, hein.

                • [^] # Re: GPG, OTR, TLS/SSL, SSH...

                  Posté par . Évalué à 0.

                  Ben la différence, c'est que du coup t'as plus besoin de rencontrer en direct au préalable ton correspondant pour utiliser OTR !

                  • [^] # Re: GPG, OTR, TLS/SSL, SSH...

                    Posté par (page perso) . Évalué à 2.

                    Trop cool… On a inventé PGP pour ça, justement…

                    • [^] # Re: GPG, OTR, TLS/SSL, SSH...

                      Posté par . Évalué à -1.

                      Je voulais insister sur le fait que GPG/PGP peut favoriser la mise en relation d'interlocuteurs voulant échanger avec un bon niveau de connaissance à priori des identités (des associations clé - utilisateur) avec tout moyen technique d'échange intégrant de l'authentification (et éventuellement du chiffrement des échanges, que ce soit avec du chiffrement asymétrique, comme symétrique, d'ailleurs).

                      Par GPG, on peut obtenir une certification qui rend aisé la mise en relation par un autre moyen, sans nécessité de protocole de rencontre et autre échange de certificat dans le monde réel.

  • # kmail

    Posté par (page perso) . Évalué à 4.

    Pour la première question, je te conseille Kmail (intégré ou non à Kontact) avec kleopatra (qui peut se lancer automatiquement depuis kmail).

    On peut juste se contenter de cliquer sur des boutons :)

  • # PGP: 0, S/MIME:1

    Posté par . Évalué à 3.

    Expérience personnelle:
    - PGP: aucun de mes contacts, tant personnels que professionnels
    - S/MIME: utilisé avec certains de mes clients pour échanger des données confidentielles.

    J'ai aussi un certificat personnel avec lequel je signe tous mes mails depuis plus d'un an. Pour l'instant, peu de réaction de curiosité de la part de mes correspondants.

    • [^] # Re: PGP: 0, S/MIME:1

      Posté par (page perso) . Évalué à 7.

      • S/MIME: utilisé avec certains de mes clients pour échanger des données confidentielles.

      C'est normal ça, dans le monde de l'entreprise, on adore la centralisation et on n'a pas trop l'habitude trop fouiller pour voir les problèmes que ça pose.

      Personnemment, c'est le contraire : j'ai plein de contacts qui utilisent PGP, dans le monde… du logiciel libre, en particulier de Debian. Quant à S/MIME, par principe il est hors de question que je l'utilise.

      • [^] # Re: PGP: 0, S/MIME:1

        Posté par . Évalué à 4.

        Ce n'est pas seulement un problème de "centralisation", mais aussi que S/MIME est supporté de base dans tous les clients mails ( outlook, lotusnotes, thunderbird, ...) contrairement à PGP.

  • # Un client mail pour les nuls ?

    Posté par . Évalué à 1.

    Finalement, j'en arrive à me demander si ce ne serait pas une bonne idée de coder un client mail qui supporte nativement openPGP en python.

    Je pense que je vais m'y atteler si j'ai du temps.

    Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

    • [^] # Re: Un client mail pour les nuls ?

      Posté par . Évalué à 7.

      Que vient faire Python là-dedans ?

      • [^] # Re: Un client mail pour les nuls ?

        Posté par . Évalué à 10.

        Sûrement pour ralentir, rajouter des bugs ou donner un effet de mode au truc. Ou juste pour utiliser une syntaxe horrible qui brûle les yeux pour quand quelqu'un voudra relire le code.

      • [^] # Re: Un client mail pour les nuls ?

        Posté par . Évalué à 1.

        Python c'est parfait pour coder vite un petit logiciel avec IHM.

        Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

    • [^] # Re: Un client mail pour les nuls ?

      Posté par (page perso) . Évalué à 6.

      Thundebird et l'extension Enigmail ça marche très bien. Ou la Gendarmerie a fait sa propre version de Thunderbird l'intégrant en natif. Le problème est pas de coder un client mail mais que monsieur et madame tout le monde utilisent un webmail et n'ont ien à cacher sinon ils utiliseraient pas Facebook et que le chiffrement c'est comme le libre ou l'informatique : un truc de geek illuminé. Remplace chiffrer des mails par "je veux que mes contacts Msn passe sous Jabber ou encore les faire migrer de windows à Linux". Seuls les personnes avec lesquelles tu auras réussi un des deux seront peut être sensible aux chiffrements des mails...

  • # on signe avec sa clé privée (pas publique !)

    Posté par . Évalué à 3.

    Personne ne l'a encore relevé, pourtant y a une coquille :

    Pour ma part, j'utilise linux et ses dérivés depuis quelques temps, mais je n'ai jamais, jamais fait usage d'une clé GPG publique pour signer mes messages.

    Rhhhooooooo, nan mé lol...

    Rappel, extrait de cette dépêche Linuxfr (18-4-2011) sur GPG (auto-citation assumée) :
    << Un contenu peut être chiffré par une clé privée. Il peut alors être déchiffré par la clé publique associée. Ce déchiffrement peut être réalisé par quiconque : la clé publique a vocation a être accessible à tous. Cela donne l'assurance que c'est bien le détenteur de la clé privée qui a chiffré le contenu. C'est en exploitant ce principe que l'authentification peut être réalisée. Dans la pratique, du fait que l'algorithme de chiffrement asymétrique est plus gourmand en ressource machine qu'un algorithme de chiffrement symétrique, ce n'est généralement pas le contenu à transmettre qui est chiffré par la clé privée mais une "empreinte" de ce contenu >>

    • [^] # Re: on signe avec sa clé privée (pas publique !)

      Posté par (page perso) . Évalué à -1.

      Je crois que c'est la clé publique qui chiffre et la clé privée qui déchiffre.
      Par contre, on signe bien avec l'«empreinte» de la clé privée.

      Mais je suppose qu'on a compris où voulait en venir neCua6nahS (quel pseudo !)…

      Debug the Web together.

      • [^] # Re: on signe avec sa clé privée (pas publique !)

        Posté par . Évalué à -2.

        Avec GPG/PGP, on chiffre avec une clé privée (la sienne propre) ou une clé publique (celle d'autrui), selon ce qu'on veut faire (respectivement signer ou chiffrer un contenu numérique). Lis par exemple le lien que je propose dans le message auquel tu réponds.

        Signer avec GPG, c'est dans le détail chiffrer (avec sa propre clé privée) l'empreinte du contenu numérique que l'on signe.

        • [^] # Re: on signe avec sa clé privée (pas publique !)

          Posté par (page perso) . Évalué à 0.

          Mea culpa : la page `gnupg' sur Ubuntu-fr ne donne que l'exemple du chiffrement=clé publique / déchiffrement=clé privée.
          Pourtant, la doc conseille bien de lire l'article Wikipédia Cryptographie_asymétrique qui dit :

          « Inversement, l'expéditeur peut utiliser sa propre clé privée pour coder un message que le destinataire peut décoder avec la clé publique ; c'est le mécanisme utilisé par la signature numérique pour authentifier l'auteur d'un message. »

          Ahem… Désolé o_o" J'ai pas encore le "man" réflexe !

          Debug the Web together.

  • # Quand ?

    Posté par . Évalué à 3.

    Dès que gmail, yahoo mail ou hotmail implémenteront ça dans leur client webmail.

    Pas avant...

    • [^] # Re: Quand ?

      Posté par . Évalué à 4.

      Non. Si j'utilise le chiffrement, c'est pour que seul le destinataire lise mon message, pas pour que le postier à qui je le confie le lise également.
      Certains pensent que c'est mieux que rien, je pense au contraire que cela maintiendrait dans l'esprit des gens la fausse idée qu'ils peuvent avoir plus confiance en les "gros fournisseurs" (Google, Microsoft, etc.).

      • [^] # Re: Quand ?

        Posté par . Évalué à 2.

        Il faut laisser le choix à l'utilisateur d'où stocker ses clefs. Que ce soit sur sa machine, sur une machine distance, ou dans un cloud ne lui appartenant pas. C'est sa décision.

        • [^] # Re: Quand ?

          Posté par . Évalué à 2.

          Exactement comme aujourd'hui : il a le choix de ne pas utiliser du tout de chiffrement. S'il délègue le chiffrement à un prestataire, alors il n'utilise pas le chiffrement.
          Il est mieux de ne pas utiliser le chiffrement qu'utiliser ROT13 et se croire en sécurité.

          • [^] # Re: Quand ?

            Posté par (page perso) . Évalué à 1.

            S'il délègue le chiffrement à un prestataire, alors il n'utilise pas le chiffrement.

            Ce n'est pas en allant au "plus de sécurité au point d'être non utilisable" que tu arriveras à "vendre" de la sécurité.

            Un utilisateur ne souhaite pas forcément être admin de sa machine. Un utilisateur souhaite parfois laisser sa machine à son petit frère ou ami de passage sans se prendre la tête. Si on suit ta logique, l'utilisateur de PGP doit absolument être admin de sa machine et être le seul et unique utilisateur de cette machine (bon, OK, allez, tout le monde fait un compte "invité" et change de compte pour laisser le pote regarder ses mails), l'utilisateur locke sa machine même pour aller pisser au cas où, l'utilisateur est le dieu de la sécurité qui ne se prendra jamais un troyen, l'utilisateur a sa partition crypté (sinon hop un liveCD et clé PGP récupérée...) car sinon sa clé est pas en "sécurité".

            Ben non, certains souhaitent déléguer certaines responsabilités, ça ne diminue pas tant que ça le niveau de sécurité vu le "reste" (es-tu sûr que déléguer à une personne est moins secure que ton utilisation actuelle de ta machine? Vraiment?), et dans ce cas ben si l'outil ne suit pas, l'outil est simplement jeté (mais bon, actuellement, il n'est même pas jeté vu qu'il n'est même pas déjà utilisé...)

            • [^] # Re: Quand ?

              Posté par . Évalué à 2.

              Ce n'est pas en allant au "plus de sécurité au point d'être non utilisable" que tu arriveras à "vendre" de la sécurité.

              En déléguant le chiffrement, vous ne vendez de toute façon aucune sécurité, mais de la tromperie.

              La clef privée présente sur l'ordinateur est chiffrée par un mot de passe. Même si l'on utilise un live-CD pour copier la clef, elle sera inutilisable sans le mot de passe connu uniquement de la personne à qui appartient la clef.
              Concernant les virus, que ce soit stocké à l'extérieur n'améliore rien du tout.

              • [^] # Re: Quand ?

                Posté par . Évalué à 2.

                Même si l'on utilise un live-CD pour copier la clef, elle sera inutilisable sans le mot de passe connu uniquement de la personne à qui appartient la clef.

                Sauf erreur, pouvoir utiliser un live CD permet de se logger en root sur la machine et donc de pieger le compte de l'utilisateur pour récupérer sa clef.

                Dans tous les cas on en revient au même problème : il faut que l'utilisateur soit le seul administrateur potentiel de sa machine (et donc que personne d'autre n'y ait accès).

                Sauf qu'en pratique l'utilisateur lambda, il a déjà du mal à être administrateur tout court et plein de gens ont accès à sa machine (toute la famille, le technicien qui lui a configuré -c'est probablement lui le véritable administrateur-, sans parler des différents virus et autres rootkits qui peuvent avoir été installés). Bref, de toute façon, dès que l'on parle de Mme Michu, la sécurité est compromise.

                Le but n'est donc pas de protéger l'utilisateur dans l'absolu, mais simplement de le protéger relativement à son environnement (d'autres Mme Michu). A partir de là, où est le problème à avoir quelques options de sécurité supplémentaires (comme du PGP dans le webmail en l'occurrence) ?

                • [^] # Re: Quand ?

                  Posté par . Évalué à 0.

                  Sauf erreur, pouvoir utiliser un live CD permet de se logger en root sur la machine et donc de pieger le compte de l'utilisateur pour récupérer sa clef.

                  Mais quelle est la différence si la clef est stockée de manière externe ? Dans tous les cas, si vous ne pouvez pas avoir confiance en votre matériel, alors on peut récupérer votre clef.
                  La clef stockée chez vous ne demande que de faire confiance à son matériel. Le stockage externe le demande aussi, mais en plus on est déjà sûr qu'un tiers aussi y a accès.

                  • [^] # Re: Quand ?

                    Posté par . Évalué à 1.

                    Par "matériel", j'entendais "le terminal qui sert à s'identifier et envoyer le message", car c'est là que l'utilisateur final tape le mot de passe, que celui-ci soit utilisé localement ou sur le serveur.

                  • [^] # Re: Quand ?

                    Posté par (page perso) . Évalué à 3.

                    La clef stockée chez vous ne demande que de faire confiance à son matériel.

                    Et à toi-même. Tu fais aveuglément confiance à toi-même, en considérant que tu es infaillible. Ben c'est pas le cas, c'est tout.

                    mais en plus on est déjà sûr qu'un tiers aussi y a accès.

                    Ce qui n'ajoute pas tant que ça de risque si on a confiance au prestataire. Ca ne dit toujours pas comment tu peux affirmer présomptueusement "En déléguant le chiffrement, vous ne vendez de toute façon aucune sécurité, mais de la tromperie."

                    Les gens délèguent tous les jours leur sécurité, à commencer par leur sécurité physique (déléguée à l'Etat par exemple). Ca n'en fait pas une sécurité "tromperie". On peut déléguer, tant qu'on sait ce qu'on fait et que le niveau de sécurité correspond à ce qu'on cherche...

                    "tromperie", "il n'utilise pas le chiffrement.", autant d'assertions fausses qui font que la seule chose que tu fais, c'est être un repoussoir aux gens qui seraient curieux par la sécurité et voudraient commencer à avoir une sécurité correcte sans se faire chier pour peut-être ensuite aller vers la sécurité forte plus chiante si il en a besoin. Avec des amis pareil, GPG n'a pas besoin d'ennemis.

                • [^] # Re: Quand ?

                  Posté par . Évalué à 3.

                  Sauf erreur, pouvoir utiliser un live CD permet de se logger en root sur la machine et donc de pieger le compte de l'utilisateur pour récupérer sa clef.

                  Sauf si le disque est chiffré.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # "pour les nuls" ?

    Posté par (page perso) . Évalué à 3.

    Bonjour,
    J'ai appris à utiliser GPG en utilisant ce tutoriel : Chiffrer son courriel avec Enigmail - http://www.framasoft.net/article3321.html

    Cela permet de prendre le premier départ. Il semble qu'il n'y aie pas de client mail préconfiguré avec GPG ? (Qu'est-ce que Kleopatra ? Je n'utilise pas KDE ... )

    L'interface seahorse fournit le mode graphique pour configurer GPG en dehors du couple Thunderbird/Enigmail (par exemple pour utiliser les clés avec Claws-mail, Sylpheed... ) Je ne parlerai pas de "man" et "help", très fournis, avec de nombreuses options aux descriptions, dont certaines sont... cryptiques :D

    • [^] # Re: "pour les nuls" ?

      Posté par . Évalué à 0.

      Merci. L'article date de 2004. On peut lire dans le 2e commentaire (mars 2005) que : << l’auteur de ce tutoriel à édité une nouvelle version qui tient compte des nouvelles versions des programmes : Thunderbird 1.0, Enigmail 0.9 Et du coup, on se passe de WinPT, car la nouvelle version d’enigmail gére encore mieux les clé et le chiffrement. >>
      ...mais le lien donné est mort mais ouvre la piste pour la nouvelle page avec le contenu originel : http://www.fabianrodriguez.com/blog/2005/01/30/guide-pour-chiffrer-son-courriel-avec-enigmail-et-thunderbird (2005 donc). Je n'ai rien trouvé de plus récent à l'adresse du blog de l'auteur originel de ce document.

      • [^] # Re: "pour les nuls" ?

        Posté par . Évalué à -1.

        Confirmation : le PDF sur Framasoft est daté du 28 septembre 2004 alors que la version à jour est du 29 janvier 2005 (j'ai trouvé ces deux dates en 1ère page des documents).
        Je veux bien relayer ce besoin de mise à jour chez Framasoft (les deux fichiers, le lien "Site......:"), à moins que quelqu'un trouve une version plus récente des documents.

    • [^] # Re: "pour les nuls" ?

      Posté par (page perso) . Évalué à 1.

      Kleopatra c'est l'utilitaire graphique de kde pour gérer tout ce qui est cryptographie : http://www.kde.org/applications/utilities/kleopatra/

      C'est très bien fait, mais il faut quand même savoir ce que l'on fait avant de cliquer sur les boutons

    • [^] # Re: "pour les nuls" ?

      Posté par (page perso) . Évalué à 1.

      Il y a aussi GPA, très complet, qui, paraît-il, se veut la référence des interfaces graphiques pour GPG.

  • # Moi non plus...

    Posté par . Évalué à 6.

    jamais fait usage d'une clé GPG publique pour signer mes messages

    Surtout si c'est avec la clé privée qu'on signe un message...

  • # Réseau privée?

    Posté par (page perso) . Évalué à 2.

    Peut être que la solution est d'utiliser un logiciel F2F qui imposent l'utilisant du chiffrement?

    Retroshare & co permettent de gérer une liste d'amis, des messages, des forums, des chats, des partages de fichiers... Ca ressemble vraiment aux réseaux sociaux privateurs, donc ça devrait pouvoir séduire les advanced michus.

    http://devnewton.bci.im

  • # autre utilisation de OpenPGP :

    Posté par (page perso) . Évalué à 1.

    • faire du TLS et donc des site web sécurisé (https) se basant sur la toile de confiance OpenPGP plutôt que sur un tiers de confiance, ce qui résoud pas mal de problème : http://www.bortzmeyer.org/6091.html

    • Payer en uni, la première monnaie d'un système monétaire équitable (100% monnaie et appliquant le dividende universel) :
      http://open-udc.org

    (100% monnaie :
    - http://fr.wikipedia.org/wiki/100%25_monnaie
    dividende universel :
    - http://fr.wikipedia.org/wiki/Cr%C3%A9dit_social
    - http://www.creationmonetaire.info/2010/05/les-4-arguments-du-dividende-universel.html )

    Je moinsse, tu moinsses, il moinsse, nos bots moinssent ...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.