L'idée est de trouver quelque chose en mixant GPG, et ssl pour avoir une communication privé (pas forcément anonyme) avec des individus qui ne savent pas utiliser GPG - ou ne connaissent même pas son existence.
Mon idée serait celle-ci (j'essaie de détailler un minumum une idée technique - elle peut être mauvaise au niveau de la réalisation, mais je n'attends que des critiques pour améliorer l'idée, voir semblant de programme - qui sait, sans doute ça existe déjà à quelques trucs près):
. Programme MyHTTPSCommunications : le programme contient une interface accessible par https qui fera office pour chaque compte communiquant avec soi : la création de nouveaux messages, la lecture des messages (listage ou non listage? vu que le mdp peut-être changé je dirai non - à moins que le principe de clé GPG soit repris - mais il faudrait que la clé privé soit chez le contact et non dans le serveur) et modification du mot de passe. L'idée pourrait être finalement la création d'un compte email sur sa machine, cela reviendrait-il au même-je ne sais pas trop? : du moins, comment pourrait-il être au courant des nouveaux emails s'il n'utilise jamais cette adresse (une alerte automatique? un envoie d'email vers l'adresse email qu'on veut lorsqu'on reçoit un nouveau message).
. Création de compte unix pour chaque contact avec qui on veut communiquer avec notre programme.
. Le mieux est de donner un mdp arbitraire en main propre et permettre au contact de pouvoir le modifier ultérieurement.
Pour envoyer un email à un de ses contact:
- On envoie un email à "mhc+@mondomaine".
- On chiffre le message en utilisant la clé publique GPG de mhc.
mhc:
- mhc déchiffre le message et le chiffre par rapport au mot de passe du compte (/etc/shadow) : ici je ne sais pas comment ça peut travailler. Mais je pense qu'il n'est pas nécessaire d'avoir quoi que ce soit en clair et l'empreinte du mot de passe suffit à chiffrer (non? - si non : le hic, comment faire?).
- mhc crée une entrée accessible par l'interface web.
- mhc envoie un email au contact avec seulement le lien pour pouvoir lire le message (et autres explications s'il faut).
Le contact lit le message reçu:
- Le contact doit taper son mot de passe, et c'est le navigateur qui déchiffre le message (l'idée est de rien avoir en clair, même sur le serveur - sauf à la lecture du navigateur bien sûr).
Le contact veut répondre:
- Un formulaire existe, et l'utilise.
- Le hic est que le serveur sait et reçoit ce qui est écrit, il faudrait que le message soit chiffré par rapport à la clé public GPG du destinataire avant que le serveur reçoive. Pour moi ce n'est pas à mhc de chiffrer le message ici. D'un autre côté c'est que mhc sait déjà ce que le destinataire a dit au contact (lors du déchiffrage du message : certes entre les deux l'interception n'est pas possible, mais si le serveur est corrompu ou écouté, on l'évite pas).
- mhc s'occupe d'envoyer l'email chiffré au destinataire.
La différence entre cette idée et la création d'un compte email pour chaque correspondant:
- Le lien reçu par le correspondant permet d'accéder après mot de passe au message directement;
- Le correspondant n'a pas de compte a proprement parler, et on peut facilement gagner en espace en imposant la suppression des messages après x jours;
- Tout les messages sont chiffrés (tant que nous aussi utilisions systématiquement le chiffrage GPG).
- On peut permettre a des anonymes (en tout cas sans compte) de nous contacter.
En imaginant que ce genre de pratiques se généralise, quel serait le mieux finalement?
Finalement, en y repensant, le mieux serait simplement que les deux utilisent une clé publique GPG. Mais comment initier les autres? Au final, je suis moi même pénaliser et entraîner dans le non chiffrement, car pour le moment, je n'ai pas de contact proche utilisant GPG, et je ne l'utilise pas.
Je garde ces idées un peu fourre tout et mal formuler. Même si au final, on retombe sur quelque chose du moindre dégat.
# hou la
Posté par fearan . Évalué à 3.
Ca m'a l'air compliqué, dans ton explication tu mélanges idées/prospection/explication/implémentation/question…
Il vaut mieux avoir un paragraphe qui résume ce que tu veux faire, puis détailler ensuite dans d'autres parties. De ce que j'ai compris tu veux permettre à des personnes d'échanger via un serveur des messages chiffrés, sans que le serveur n'enregistre les messages en clairs; c'est ça ?
Ma première remarque :
/etc/shadow n'est lisible que par root, est tu certains d'avoir besoin d'un processus supplémentaire avec les droits tronçonneuse ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: hou la
Posté par dafp . Évalué à 1.
Je vais rajouter un post qui ne parle que de la mise en processus de l'idée d'un programme qui ferait ce que je pensais - sans rajouter mes commentaires.
Pour /etc/shadow c'était une idée. En effet, dans ce cas c'est mieux que mhc ait son propre fichier mais du même type que /etc/shadow.
# les utilisateurs et la securité
Posté par SlowBrain (site web personnel) . Évalué à 1.
Bonjour.
Tout d'abord ton journal semble très confut et est assez difficile à lire. Alors qu'au moins une des idée me semble intéressante : rendre accessible la sécurité au plus grand nombre.
L'utilisation de PGP en lui même n'est pas très compliqué. L'april as même traduit il y as peu un guide sur le sujet.
Et tant que l'on gère ces mails comme dans les Années 90 (sur un vrai ordinateur à la maison), il n'y as aucun problème.
Mais aujourd'hui l'utilisateur ne fait plus de cette façon.
Ils utilisent le client natif de leur téléphone ou de leur tablettes, ou un webmail (ce qui est fortement incompatible avec PGP)
Sans compter qu'ils se contre fichent de la sécurité qu'ils voient comme des contraintes inutiles (et ils ne vont donc rien faire pour s'en ajouter)
[^] # Re: les utilisateurs et la securité
Posté par dafp . Évalué à 1.
L'idée est au final d'obliger la personne qui veut nous parler ou qui on veut contacter de rentrer dans notre système de communication privé (du moins avec nous).
Beaucoup de mondes n'utilisent pas GPG ou même ne connaissent pas. Le problème c'est que si quelqu'un ne se protège pas, notre communication si elle veut être privé devient difficile. L'idée est donc d'obliger la personne de venir chez nous (auto-hébergement conseillé) pour nous parler, et il aura le droit lui aussi a une petite boite aux lettres si ce dernier s'intéresse un peu soit peu à nos réponses.
Étant donné que tout est sur web à présent, je pensais qu'une interface web serait possible…
# Confusion ... Je reprends depuis le début.
Posté par dafp . Évalué à 1.
Désolé pour la confusion, il est vrai qu'il est parfois pas facile de me relire, et là c'est bien le cas.
Je reprends depuis le début, même si je pense que mon idée est un peu bancale et manque quelques éléments (par rapport à une communication point à point qu'apporte GPG), y me semble important d'y réfléchir et d'essayer de généraliser le chiffrement pour tous, quitte à obliger nos contact (privé) de rentrer et jouer le jeu - qui plus est le plus facilement du monde, et sans douleur.
L'idée est au final d'obliger la personne qui veut nous parler ou qui on veut contacter de rentrer dans notre système de communication privé (du moins avec nous).
Beaucoup de mondes n'utilisent pas GPG ou même ne connaissent pas. Le problème c'est que si quelqu'un ne se protège pas, notre communication si elle veut être privé devient difficile. L'idée est donc d'obliger la personne de venir chez nous (auto-hébergement conseillé) pour nous parler, et il aura le droit lui aussi a une petite boite aux lettres si ce dernier s'intéresse un peu soit peu à nos réponses.
Étant donné que tout est sur web à présent, je pensais qu'une interface web serait possible…
Une chose avant tout, il me semble essentiel que le programme/daemon que je vais parler écrive le moins de chose possible, et le mieux serait qu'aucun message soit en clair dans le disque. De plus, il serait préférable que toutes communications antérieures soient supprimés, n'étant pas à vocation de faire office d'hebergement email, l'idée est de trouver quelque chose temporaire, ou moins pire par rapport à une communication où chacun aurait son espace mail, et son MUA configuré avec PGP (le monde idéal). Sans doute l'outil pourrait être un minimum didactique et inviterait à expliquer les principes de chiffrement, du pourquoi, etc… L'idée est tout de même de rallier l'autre à l'aventure du chiffrement - tant soit-il convaincu de l'intérêt de sa propre vie privé et de sa liberté. Mais rien n'est mieux que chacun chez soi, le problème avec mon idée est que tout se passe chez quelqu'un (qui peux être chez moi). Donc si sous écoute, ou quelqu'un arrive à déchiffrer les emails (car accès sur la machine), ce n'est plus un contact, mais plusieurs contact qui sont victimes. D'où le fait que je pense qu'il faut supprimer au fur et à mesure les messages, et que cette idée/projet ne doit être qu'un tranpoline/lancement/invitation vers l'auto-hébergement, ou du moins au PGP privé chez soi, et au tout chiffrement.
. Création de compte pour chaque contact : comme un alias, et non une adresse; qui pointerait vers une adresse email.
. Le mieux est que la création d'un nouveau compte soit accompagné d'un mot de passe aléatoire et soit donné en main propre. Sinon un mot de passe par défaut, puis une modification dès la première visite/connexion par le contact (1).
- le stockage du mot de passe peut se faire comme pour "/etc/shadow" par exemple, avec une simple empreinte.
Je veux écrire un email à un contact qui ne se protège pas:
. J'envoie un email à "daemon+contact@domaine.auto-heber.ge"
. Et je chiffre l'email avec la clé publique de daemon. (2)
-daemon:
. Création d'une page web accessible par https pour le contact.
. Envoie de l'email à contact avec seulement le lien pour lire l'email.
Je suis le contact qui ne se protège pas et je veux lire l'email que j'ai reçu:
. J'accède à la page web.
. Je tapes le mot de passe que je suis censé connaître.
. daemon déchiffre l'email (clé privé présente sur serveur) | chiffre à partir mot de passe du contact | envoie ça au contact
. Le contact reçoit un contenu chiffré et qui doit être déchiffré par le navigateur avec le mot de passe.
Je suis le contact qui ne se protège pas et je veux répondre à l'email en jouant le jeu:
. J'accède au formulaire de réponse.
. J'écris mon message. (3)
. daemon envoie l'email chiffré avec la clé public du destinataire de départ.
L'interface web n'aura pas de listage de messages, et permettra de modifier le mot de passe (et donc feront que les messages ultérieur ne seront pas lisible sauf avec l'ancien mot de passse) mais aussi d'écrire un message.
L'idée est que l'interface soit vraiment propre à une personne, et que même des anonyme (ou pas) puisse nous contacter, tout en faisant que la communication reste la plus secret possible.
Au lieu de moi@chez-moi.fr on aurait :
https://daemon-contact.chez-moi.fr
https://daemon-contact.chez-toi.de
https://martin.renard.fr
etc…
(1) Le problème est qui se cache derrière ce contact, dans ce cas, si un attaquant lit (sans doute en clair) l'email et accède au changement du mot de passe avant le dit contact.
(2) Le principe est que mon serveur mail va recevoir l'email et le stocker. Donc il faut impérativement le chiffrer. Il faudra auparavant générer une clé GPG pour daemon.
(3) SSL suffira? Ne serait-ce pas mieux que le navigateur chiffre le message avant l'envoie avec la clé public de mon email? Du Javascript qui s'occuperait de faire ça, ça reste correct? Pour moi ce n'est pas à daemon de le faire, mais tant qu'il ne le stocke pas au final, c'est un moindre mal, mais le mieux c'est que jamais il n'est connaissance du message, c'est un peu aussi le problème lors de l'envoie de mon email vers le contact : mais bon comment faire quand au final le chiffrage ne se fait pas sur la machine client…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.