Dans la course pour proposer une boite mail chiffrée, facile à utiliser, Own-Mailbox se distingue de tout ce que l'on a vu ces derniers mois, en proposant un boîtier plug and play à brancher chez soi. La solution est Open-Hardware et constituée à 100% de logiciel libre.
Own-Mailbox, en plus de la simplicité d'utilisation, apporte la possibilité de consulter ses mails chiffrés de n'importe ou dans le monde, sur n'importe quel ordinateur, sans compromettre la sécurité du chiffrement. Own-Mailbox profite également du coté auto-hébergé afin de mettre en place une technique pour envoyer et recevoir des messages confidentiels de correspondants qui n'utilisent pas GPG, en passant par HTTPS.
Own-Mailbox s'inscrit dans un contexte où, les autres acteurs du marché utilisent principalement des solutions de mail sur le cloud, avec un chiffrement en Javascript coté client. WhiteOut a été évoqué sur LinuxFr.org la semaine dernière, mais de nombreux autres services ont fleuri récemment (Proton Mail, Tutanota, Mailpile, Lavaboom, Openmailbox). Le projet Own-Mailbox (NdM: l'auteur de la dépêche en est membre) explique dans sa FAQ pourquoi, selon lui il ne faut pas accorder sa confiance à ce genre de services. Parmi les cinq arguments avancés celui que le chiffrement, pour être de confiance, doit être réalisé sur une machine 100% logiciel libre, et que ces systèmes basés sur JavaScript poussent les utilisateurs à faire réaliser le chiffrement par les moteurs JavaScript des navigateurs propriétaires de Google, Microsoft, et Apple qu'ils utilisent dans 80% des cas, sans leur expliquer la nécessité d'utiliser du logiciel libre. Et même si vous utilisez du libre rien ne dit que votre correspondant le fait, et ne compromet pas votre sécurité.
On se rappellera au passage, la virulence des opposants du chiffrement qui tentent tout pour le rendre inopérant et font même pression pour ajouter des backdoors dans le noyau Linux (http://www.numerama.com/magazine/27033-linus-torvalds-avoue-des-pressions-pour-mettre-un-backdoor-dans-linux-maj.html).
Own-Mailbox résoud donc quatre problèmes liés au chiffrement de mails:
- Le chiffrement de mail est compliqué à configurer surtout dans différents environnements (OS, logiciel de mail, version).
- Le chiffrement de mail empêche de lire ses mails de partout dans le monde (Bibliothèque, travail, ordinateur d'un ami, ordinateur de l’hôtel)
- On ne peut pas envoyer de messages chiffrés aux personnes qui n'utilisent pas encore GPG.
- Pour être digne de confiance le chiffrement doit être fait sur une machine 100% logiciel libre qui vous appartient et la plupart des gens n'ont pas cela.
C'est de mémoire le plus petit serveur All-in-the-box que l'on ait vu jusqu'à maintenant, et le projet est réalisé par une équipe d'ingénieurs français !
L'équipe prévoit en lancement du produit en juin 2016. Une campagne kickstarter doit être lancée ce mois-ci pour soutenir le projet.
Aller plus loin
- Site officiel (3976 clics)
- Suivre sur twitter (525 clics)
# chouette projet
Posté par insert_coincoin . Évalué à 1.
par la même équipe que librecalc ? Tu en fais partie ? Ça serait bien de le préciser : sans ça, ton journal fait un peu pub…
[^] # Re: chouette projet
Posté par arcanes . Évalué à 3.
Tu as tout à fait raison, je ferai attention.
Heureusement l'équipe de modération est là pour éditer mes propositions.
[^] # Re: chouette projet
Posté par Anonyme . Évalué à 1.
Je me trompe ou tu ne réponds pas à la question ?
à moins que
fasse référence au fait que tu fais partie du projet et non au fait que cela puisse ressembler à de la pub
[^] # Re: chouette projet
Posté par arcanes . Évalué à 5.
Cela réponds au deux, dans le sens oui je fais partie du projet, et oui j'ai proposé un article pour faire parler du projet sachant que la modération peut modérer ce qui ne lui parait pas neutre.
Bonne après-midi! ;)
[^] # Re: chouette projet
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Précision ajoutée dans la dépêche, merci.
[^] # Re: chouette projet
Posté par Anonyme . Évalué à 10.
Vu le fond du projet et la manière dont c'est présenté, je ne vois pas de problème à ce que ce projet fasse sa pub sur linuxfr.
[^] # Re: chouette projet
Posté par insert_coincoin . Évalué à 8. Dernière modification le 18 juin 2015 à 16:32.
Je trouve juste qu'en général, on a tout à gagner à se présenter comme développeur du projet quand c'est le cas, surtout quand on porte un projet intéressant comme celui-ci, et encore plus sur ce site… plutôt que de balancer un texte dépersonnalisé et laudatif :
Enfin bref, bonne chance :)
[^] # Re: chouette projet
Posté par arcanes . Évalué à 4. Dernière modification le 18 juin 2015 à 16:45.
Ok, je pensais que les dépêches devaient être écrit avec un style journalistique et impersonnel, mais appartement non! ;)
Merci! :)
# petit doute sur l'argumentaire
Posté par Dreammm . Évalué à 3.
Le projet est sympathique, par contre l'argumentaire me semble un peu fallacieux sur la partie qui concerne la critique des chiffrements javascripts.
Plus exactement, ok sur la critique : laisser le code de chiffrement/déchiffrement se dérouler dans une boite noire que l'on ne maitrise pas de bout en bout laisse la possibilité qu'un tiers ait introduit un code malicieux qui intercepte le message en clair : donc chiffrer/déchiffrer dans la VM javascript d'un navigateur proprio, c'est dangereux.
Mais du coup, si l'interface du produit est disponible par https, qu'est-ce qui empêche le même navigateur non opensource avec un code légèrement différent de balancer les messages en clair ?
Et du coup point de salut :-(
Me trompe-je dans mon argumentaire ?
[^] # Re: petit doute sur l'argumentaire
Posté par Jiehong (site web personnel) . Évalué à 3.
C'est vrai que c'est bizarre ce truc (et il semble possible d'envoyer un lien https sans question spéciale, contenant le contenu du message en clair).
En outre, ils n'ont pas encore de CA valide pour TLS/SSL…
Bref, c'est une solution d'hébergement personnelle sympathique, mais pour ce qui est de la protection des données, ça me semble bancale : non sûr tant que ça n'a pas été bien vérifié.
[^] # Re: petit doute sur l'argumentaire
Posté par arcanes . Évalué à 2.
Merci pour le retour, ;)
Pour le CA, comprends qu'il faille que l'on lève des fonds avant de pouvoir faire ce genre de négociation. (A noter tout de même qu'un CA n'est ni nécessaire, ni la garantie pour une transaction HTTPS sécurisée).
Pour le reste je ne suis pas sur de te suivre. Il y a beaucoup d'explication dans la FAQ, qui répondent à peu près à toutes les questions de sécurité, mais je pense que je vais améliorer la section sur PLM pour la clarifier.
[^] # Re: petit doute sur l'argumentaire
Posté par Jiehong (site web personnel) . Évalué à 3.
De rien. Je vais prendre le temps de donner mon avis plus en détails.
Les points vraiment bons :
- logiciels libres ;
- matériel libre (et là, chapeau bas, car c'est tellement rare) ;
- petit, et semble vraiment sympa.
Quelques points où je me pose des questions :
Cas où les gens utilisent déjà GPG
Je suppose que ça ne va pas changer grand chose. Own-mail va-t-il chercher les clés des correspondants sur un serveur de clés spécifique (par défaut) ou … ?
Cas où les gens n'utilisent pas GPG
Si j'ai bien compris, le courriel envoyé reste dans notre propre boîte mél., et on file un lien https à notre correspondant pour qu'il le lise. Le lien est à usage unique, et peut être protégé par une question.
Plusieurs soucis ici :
- comment on donne le lien finalement ? et le mot de passe/réponse à la question ?
- sans question, le lien n'offre aucune protection s'il est donné sur un canal non sûr (SMS, email en clair, etc.) ;
- si le CA de la connexion SSL n'est pas valide ou inexistant, le navigateur va informer l'utilisateur, qui va sûrement accepter le risque, et la c'est une MiTM sans souci (j'ai bien lu l'entrée sur les MiTM de la FAQ) ;
- c'est vous qui allez héberger les liens il me semble, dans ce cas, et si vous êtes le CA, il faut s'assurer de la sécurité de cette solution ;
Enfin, le message de retour est écrit dans le navigateur via le lien pour lire le message original. Celui-ci est transmit en https, et chiffrée via notre clé publique ?
Il n'y a pas vraiment de moyen d'authentifier celui qui nous réponds, mais bon, pourquoi pas.
Le réceptionnaire n'aura pas de copies du messages d'ailleurs (sauf à la copier-coller).
Bref
Je trouve que c'est un super solution pour s'auto-héberger, sur du matériel libre, et pour ça, c'est vraiment une super idée de projet.
Une fois le code revu, ça serait même formidable de pouvoir utiliser GPG aussi.
Par contre, la solution pour ceux qui n'utilisent pas GPG me semble compliquée, et et uniquement utilisable (si sûre) qu'avec 1 voire 2 personnes, mais pas vraiment plus.
[^] # Re: petit doute sur l'argumentaire
Posté par arcanes . Évalué à 10. Dernière modification le 18 juin 2015 à 21:35.
Oui concernant GPG c'est pareil sauf que tu peux le faire via un webmail accecible de partout, ce qui est nouveau.
Par mail.
Oui et non. Avec un simple Capcha tu échappes avec certitude à la surveillance de masse, ce qui n'est pas rien. On peut seulement espionner si tu es sur écoute, et donc s'il y a des humains derrière. Sans compter le fait que tout espion est obligé de révéler son adresse IP, et le fait qu'il a espionné, ce qui n'est pas sans conséquences.
En pratique j'ai déja utilisé de nombreuse fois cette technique, sans question. Aucune fois le lien n'a été espionné.
Si c'est une question pas forcement besoin de le transmettre, ça peut être quelque chose que tu sais que la personne sait déjà. Si c'est un mot de passe, par un autre moyen que le mail.
Non ce n'est pas moi, c'est les gens sur leur Own-Mailbox.
Nous aurons forcement un CA.
Hum c'est sur que ce n'est pas une solution pour envoyer 10 mails confidentiels par jour à une personne. Pour cela il faut que l'autre passse à GPG, mais en pratique je t'assure que quand tu dois envoyer une info confidentielle à quelqu'un qui n'a pas GPG c'est super pratique. Perso je l'ai déja utilisé plusieurs fois dans des cas réel d'utilisation, et c'est limite magique de simplicité.
[^] # Re: petit doute sur l'argumentaire
Posté par Jiehong (site web personnel) . Évalué à 5.
En tous cas, merci beaucoup du temps que tu passes à répondre à mes questions :)
[^] # Re: petit doute sur l'argumentaire
Posté par arcanes . Évalué à 3.
De rien,
D'ailleurs concernant le CA, on vient de nous informer de cette initiative qui risque de grandement nous faciliter la tache:
https://letsencrypt.org/
[^] # Re: petit doute sur l'argumentaire
Posté par arcanes . Évalué à 1.
Ce que tu dis a du sens, mais il y a une différence significative entre avoir accès à un mail à un temps t et casser un système de cryptographie de mail. La seconde option est bien plus dangereuse.
A noter aussi que l’argumentaire est constitué de cinq argument, pas simplement de celui-ci.
# Très bonne idée
Posté par Ecran Plat (site web personnel) . Évalué à 1.
Très bonne idée actuellement pour les emails chiffré je peut que depuis mon pc et mon laptop avec thunderbird.
Avec ça on pourrait l'utiliser depuis n'importe que pc ;-)
Question on peut le faire tourner dans une vm ou un container ? J'ai un petit serveur domotique + mutlimedia + fichier à la maison (un proliant microcube) et comme il fout rien de toute la journée je pourrais l'héberger sans problème au lieu de rajouter un boitier qui va bouffer du jus.
# Bonne chance !
Posté par rdhlnn . Évalué à 5.
L'idée est vraiment intéressante ! Cela me fait penser à la FreedomBox.
Je pense que la clef dans ce projet (sa réussite ?) par rapport à la FreedomBox pourrait être de vendre un support matériel où tout est installé, et modifiable facilement. La FreedomBox me semble plombée par trop de technicité pour le grand public, des lenteurs de développement, malgré le financement du projet sur kickstarter, et des intentions vraiment louables (une version 0.3 du projet est sortie cette année).
A titre perso, je me verrai bien acquérir un tel objet (et surtout l'offrir à mes proches), s'il me revient moins cher qu'un kit BeagleBone par ex. (environ 100 euros avec tous les éléments), et s'il est aussi plus facilement et rapidement utilisable. Il me semble que c'est vraiment ce qui cloche dans beaucoup de projets, l'oubli que le grand public n'est pas un ensemble de geeks ; la plupart des gens veulent simplement un truc qui fonctionne rapidement et efficacement, qui est ergonomique (l'importance de l'UX), et accessoirement qui respecte certaines valeurs (sinon depuis les scandales révélés par Snowden, tout le monde aurait déjà fait les efforts pour changer de façon d'utiliser la technologie).
Enfin, dans tous les cas, l'idée est géniale. Une question que je me pose, y aura-t-il d'autres services que l'email dès le lancement du projet (je n'ai pas vraiment trouvé la réponse sur le site, même s'il est évoqué les services framasoft), par ex. un service comme etherpad ou un owncloud ?
[^] # Re: Bonne chance !
Posté par Framasky (site web personnel) . Évalué à 5.
Si tu veux un truc avec d'autres services que l'email, tu peux aller jeter un œil du côté de la brique internet. Par contre, je ne crois pas que le chiffrement des mails soit inclus.
Peut-être les gens d'Own-Mailbox pourraient-ils se rapprocher de Yunohost (le logiciel dans la brique) pour y inclure le chiffrement ?
Pour etherpad, ça me paraît compliqué : les gars de cozycloud avaient dit (je ne sais plus où) que cozycloud ne pourrait pas tourner sur le matériel de la brique parce que node.js nécessite un matériel un peu plus velu que la brique. Et etherpad est écrit en node.js.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Bonne chance !
Posté par arcanes . Évalué à 6.
On va les contacter dès que l'on a le temps. Notre Mod de RoundCube sera publié en licence libre, et facilement intégrable dans Yuno-Host, je pense.
Je précise aussi que je donnerai un "Lightning Talk" Au jardin entropique à Rennes dans 2 week-end, pour toute personne qui souhaite me rencontrer.
# Pas compris
Posté par Anonyme . Évalué à 4. Dernière modification le 18 juin 2015 à 15:39.
+1 pour la tentative (j'attends de voir comment cela se concrétise) de mise en place d'un boitier visant à faciliter la protection des contenus échangés par email en rendant transparent l'usage de GPG.
Mais dans le cas le plus répandu où les correspondants n'utilisent pas GPG:
Si le lien est envoyé au correspondant dans sa boite mail, toute personne ayant accès à cette boite, en premier lieu l'hébergeur, aura aussi accès au message, lien HTTPS ou pas.
De plus, «access the message in encrypted form» est trompeur: la transmission du message vers le navigateur client est chiffrée, mais le message est disponible en clair pour quiconque a accès au lien.
Du coup, quel est la plus-value apportée, si ce n'est ajouter de la complexité à l'échange ?
Ou bien ai-je loupé une subtilité ?
[^] # Re: Pas compris
Posté par Anonyme . Évalué à 6. Dernière modification le 18 juin 2015 à 15:52.
La réponse est dans la FAQ bien évidemment
Donc on peut protéger l'accès au message par différents moyens et le supprimer automatiquement après un certain temps ou une fois lu par le premier qui réussi à y accéder
[^] # Re: Pas compris
Posté par arcanes . Évalué à 3.
Je précise également (et il faut que je l'ajoute à la FAQ) que le lien est secret du type:
test.own-mailbox.com/n3FVgtFwR2326kxV8D69cJ457vHcp839nX6dkQGzGjF38bJ3P58WVbA5VwiX86uXY8kAD25wLJaDbjfz4.php
On ne peut pas tomber dessus par hazard.
[^] # Re: Pas compris
Posté par gouttegd . Évalué à 3.
Euh, le but c’est de pourrir encore un peu plus l’image du chiffrement, que ce soit le plus rebutant possible pour les utilisateurs, c’est ça ?
Non parce que là, pour moi la seule réaction que je peux imaginer venant d’un utilisateur moyen (« utilisateur moyen » dans ce contexte = toute personne qui n’utilise pas déjà OpenPGP ou une autre technologie de chiffrement), c’est « purée qu’il me saoûle l’autre, à m’envoyer ce genre de messages ! ».
Certains se plaignent déjà juste quand on leur envoie des messages clear-signed — ceux commençant par
-----BEGIN PGP SIGNED MESSAGE-----—, alors même que le message reste directement lisible. Alors les obliger à passer par un lien à usage unique et à validité limité juste pour lire un message… on voudrait braquer encore un peu plus les réfractaires au chiffrement qu’on ne s’y prendrait pas autrement.[^] # Re: Pas compris
Posté par arcanes . Évalué à 10.
Il y a une différence entre envoyer une info confidentielle de temps en temps via un lien, et envoyer 10 mails par jours via un lien. Si doit envoyer une info confidentielle, la personne qui n'aime pas le chiffrement sera contente que tu lui envoi via un lien, plutôt que tu essais de lui faire installer GPG, ça n'a rien à voir en terme de simplicité.
Ca peut être précieux également pour faire un premier contact sécurisé entre un journaliste et un WistleBlower, par exemple, si l'un des deux n'a pas de clef GPG.
[^] # Re: Pas compris
Posté par claudex . Évalué à 5.
Et à raison : https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas compris
Posté par Jiehong (site web personnel) . Évalué à 3.
et pour les questions : http://www.phildev.net/pgp/pgp_clear_vs_mime.html
[^] # Re: Pas compris
Posté par gouttegd . Évalué à 2.
Je ne parlais pas de ceux qui critiquent le format PGP inline sur des bases techniques, mais de ceux que le simple fait de voir une série de caractères inintelligibles dans un mail à leur intention insupporte (« 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? » — et je n’invente rien, quelqu’un a réellement écrit ça en parlant d’une signature PGP)…
[^] # Re: Pas compris
Posté par Jiehong (site web personnel) . Évalué à 2.
ah oui, mais là… Je suppose que ça ne les intéresse pas du tout, et qu'ils ne veulent pas savoir…
[^] # Re: Pas compris
Posté par Zenitram (site web personnel) . Évalué à -3.
c'est si compliqué de comprendre que l'utilisateur souhaite utiliser et non pas décoder un mail?
J'espère que les auteurs du projet n'ont pas la même idée de ce que doit supporter un utilisateur, sinon le projet ira comme les autres projets de développeur dans sa tour d'ivoire, c'est-à-dire à la poubelle faute d'utilisateurs.
Et dire qu'on est encore à ce genre de commentaire "c'est la faute de l'utilisateur, pas de ma technique" en 2015…
[^] # Re: Pas compris
Posté par Zenitram (site web personnel) . Évalué à -3.
Euh… Oui, plein (dont moi), normal : c'est bien le cas, c'est insupportable en plus de n'avoir rien à faire la.
Je n'en vois plus de nos jours, ouf, il reste maintenant parfois des pièces jointes de signature pas beaucoup moins chiantes (super pratique pour savoir si la personne a réellement une pièce jointe ou pas) sur le Mailing-List (sans doute car certains peuvent trouver ça utile, c'est global) ou rien (les gens ont abandonné l'idée de faire chier les autres avec leurs techno pas agréable pour ceux non compatibles et on des outils qui filtrent par personne avec pas de signature par défaut?), la technologie n'est pas bien réro-compatible…
(et je ne dois pas tour comprendre à cette superbe techno car je ne vois pas pourquoi il ne suffirait pas d'ajouter un champs d'en-tête PGP avec la signature, qui sera ignoré par les lecteurs ne supportant pas la chose vu que c'est prévu comme ça, à la place d'une pièce jointe)
[^] # Re: Pas compris
Posté par Ytterbium . Évalué à 2. Dernière modification le 19 juin 2015 à 09:20.
Peut être que c'est justement voulu de montrer explicitement que le message a été signé. Sinon, si comme tu dis, tu utilises un lecteur masquant cette information, tu ne sauras jamais que tu as reçu un mail signé, et même dans un lecteur gérant PGP, il y a un risque en masquant cette information de ne pas se rendre compte que le message n'a pas été signé.
Et puis franchement, une signature PGP peut paraître cabalistique, mais ce n'est pas non plus vraiment gênant dans la lecture d'un mail.
[^] # Re: Pas compris
Posté par Zenitram (site web personnel) . Évalué à 0.
un lecteur supportant PGP n'est pas le problème : il affiche que c'est signé (et pas en pièce joint, code couleur etc).
Vu que l'utilisateur a un lecteur ne supportant pas la vérification, c'est le but que d'être masqué!
imagine qu'on mette une balise HTML non reconnue en plein dans l'affichage de l'utilisateur pour lui dire "non supporté"… non, justement, on a l'idée inverse.
Et c'est mal (d'une en "mentant" car ce n'est pas une pièce jointe, et deux en affichant un truc incompréhensible qui ne montre rien du tout explicitement).
[^] # Re: Pas compris
Posté par gouttegd . Évalué à 10.
D’après toi, que serait supposé faire un client mail en recevant un type MIME qu’il ne reconnaît pas ? Le masquer complètement à l’utilisateur ? Et si c’était une pièce jointe dans un format que le client ne connaît pas mais dont l’utilisateur, lui, sait quoi faire ?
Le traiter comme une pièce jointe opaque est le comportement attendu d’un client conforme à MIME (RFC 2049) :
[^] # Re: Pas compris
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 19 juin 2015 à 10:40.
L'afficher et permettre sauvegarder (ce qui est fait)
La critique est que ça ne devrait pas être à cet endroit, prévu pour les pièces jointes, pas pour les signatures. cette "forme" de PGP utilise un endroit qu'il ne devrait pas utiliser, car non prévu pour ça.
Car tout bêtement, on attend d'une signature qu'elle soit invisible pour qui ne supporte pas la signature (ce n'est pas un contenu à destination de l'utilisateur).
Bref, le problème est pris à l'envers (un problème technique? On emmerde celui qui n'a rien demandé à la place de celui qui demande), pas étonnant que ça fasse râler (vraiment, voir une pièce jointe dans mon client mail alors que c'est juste une signature qui ne m'est pas destinée, c'est très gonflant).
[^] # Re: Pas compris
Posté par gouttegd . Évalué à 6. Dernière modification le 19 juin 2015 à 10:53.
OK, je crois comprendre. Tu sembles considérer que MIME ne sert qu’à transporter des pièces jointes, et donc que PGP/MIME (et S/MIME aussi du coup) devrait aller mettre ses signatures ailleurs (vu que ça n’a rien à voir avec une pièce jointe).
Sauf que non, MIME n’a jamais été limité au seul transport des « pièces jointes ».
MIME est prévu, entre autres choses (le premier « M » de MIME veut dire multi-purpose…), pour :
multipart/mixed) ;multipart/alternative, typiquement, une version texte et une version HTML, ou encore une version française et une version anglaise) ;multipart/digest) ;multipart/rfc822) ;multipart/signed) ;multipart/encrypted).Au passage,
multipart/signedetmultipart/encryptedne sont pas des inventions de PGP, ça existait avant.[^] # Re: Pas compris
Posté par Zenitram (site web personnel) . Évalué à -5. Dernière modification le 19 juin 2015 à 11:13.
Je ne considère pas grand chose techniquement.
Tu te places côté technique.
Je me place côté utilisateur.
Si il est impossible de faire la différence entre un MIME utile pour l'utilisateur (un document qu'il doit ouvrir ou sauvegarder) et un MIME "metadonnées" (une signature qu'on peut ignorer si on ne supporte pas la signature), il y a une problème technique.
MIME ou tartampion, je m'en balance complet, je regarde le résultat dans les lecteurs les plus "commun" (de mon côté, j'utilise Thunderbird, je ne sais pas comment fonction l'interface gmail hyper utilisée mais c'est aussi à regarder)
Mais j'ai été emmerdé que par des gens utilisant PGP (enfin, il me semble), comme pour les autres type MIME qui me semble sont correctement gérés par les lecteurs "communs" (enfin, il me semble que les messages forwardés ça m'emmerdait passablement aussi à une époque, je ne sais pas comment ça a été réglé, soir par abandon du type MIME soit par gestion du type MIME pour Thunderbird, mais en tant qu'utilisateur, encore une fois, je m'en fou : je veux que ça soit utilisable, c'est tout).
Bref, c'est l' "expérience utilisateur" qui compte, la technique étant à son service et non l'inverse, la partie technique est pour vous développeur ou personne expliquant comment ça marche, pas pour l'utilisateur. On n'est plus en 1995 avec des utilisateurs "technique", les contraintes sont différentes de nos jours (l'utilisateur veut utiliser, pas s'emmerder avec la technique).
PGP, ça ressembe à CACert : un très bonne idée sur le papier, mais aucune gestion de l'ancien du coup les gens ne peuvent pas l'utiliser même quand ils veulent à cause des "autres" qu'ils emmerdent avec. C'est dommage (car à la base, c'est une idée super).
[^] # Re: Pas compris
Posté par gouttegd . Évalué à 10.
Mais bien sûr qu’il est possible de faire la différence, il suffit de regarder le type MIME, c’est là pour ça.
Ton problème vient des clients qui ne savent pas gérer le type MIME
multipart/signed, qui du coup ne peuvent pas savoir à quoi il sert (est-ce une pièce jointe ou une métadonnée ?) et donc se rabattent (à raison) sur le comportement recommandé (traiter ça comme un blob opaque).Peut-être parce que personne ne t’a jamais envoyé de messages signés par S/MIME, parce que le fonctionnement est exactement le même…
Vois pas le rapport avec « la gestion de l’ancien ». PGP/MIME a expressément repris le format MIME qui existait déjà, justement pour ne pas inventer son propre truc de son côté.
[^] # Re: Pas compris
Posté par jyes . Évalué à 8.
Ce n’ est pas un pièce jointe. Du moins, c’est une pièce jointe définie comme signature et non comme un fichier attaché. Si ton client de courrier électronique ne sais pas gérer ça, il pourrait (devrait ?) très bien ne pas l’afficher. Dong GPG fonctionne comme tu voudrais, mais tu n’aimes pas le comportement de ton lecteur de courriel, donc GPG est mauvais… ben, tu ne m’as pas convaincu sur ce coup.
[^] # Re: Pas compris
Posté par gouttegd . Évalué à 5.
Je ne sais pas ce qui a motivé les choix derrière PGP/MIME. Ils ont repris le format déjà créé pour S/MIME, donc la décision remonte en fait au RFC 1847, en… 1995.
A priori, je dirais qu’au moins une raison était d’avoir un seul format à la fois pour les messages signés et pour les messages chiffrés. Un en-tête de signature, à la manière de ce qui se fait pour DKIM, n’aurait évidemment pas été adapté.
Une autre raison est que mettre la signature dans l’en-tête ne dispense de toute façon pas du besoin de délimiter la partie du message qui est signée, ce qui implique d’empaqueter la partie signée dans un conteneur MIME (ce que font S/MIME ou PGP/MIME, et on retombe sur le problème de messages contenant des parts MIME dont le client mail et/ou l’utilisateur ne comprend pas la signification).
L’alternative serait d’indiquer dans l’en-tête ce qui est signé exactement — c’est ce que fait DKIM, et c’est pourquoi les signatures DKIM sont régulièrement cassées dès qu’un message passe à travers un MTA indélicat qui touche un peu trop au corps du message.
[^] # Re: Pas compris
Posté par Zenitram (site web personnel) . Évalué à -1.
non mais qui se permet de toucher au corps… il y a des MTA à flinguer!
A noter que ça concerne 8% des mails "seulement".
La où je voulais en venir, c'est qu'il est préférable que les emmerdes soient sur ceux qui demandent la fonctionnalité que sur ceux qui n'ont rien demandé.
Pour le moment, PGP emmerde ceux qui n'ont rien demandé.
[^] # Re: Pas compris
Posté par rpnpif . Évalué à 5.
Si je suis ton raisonnement, l'HTML me gêne dans les mails, de même que les pièces jointes aux formats non libres, donc, interdisons-les.
On est loin de l'internet neutre, là.
[^] # Re: Pas compris
Posté par Jiehong (site web personnel) . Évalué à 2.
Je suis tout à fait d'accord avec toi Zenitram : c'est mal foutu pour ceux qui s'en fichent.
D'ailleurs, je ne pense pas que les courriels chiffrés/signés décollent avec la technologie actuelle. Il faut une nouvelle technologie pensée pour ça, et qui est bien plus transparente pour tout un chacun.
Le problème d'une nouvelle technologie, c'est qu'elle mettra au moins une décennie à être intégrée aux clients mél.
# maintenance
Posté par kna . Évalué à 3.
Comment sont assurés les mises à jour une fois la machine branchée chez Mme Michu ?
La FAQ parle de « peer-to-peer » backup mais le présente simplement comme des MX secondaires (« when your own-mailbox is unplugged »). Les BAL sont aussi sauvegardées sur d'autres boitiers quand le boitier est en ligne ?
Les clés GPG sont-elles sauvegardées ? Où ?
[^] # Re: maintenance
Posté par arcanes . Évalué à 1. Dernière modification le 18 juin 2015 à 16:36.
Salut, merci pour les questions, qui montrent ou il reste à clarifier notre présentation.
Le back-up peer-to-peer est optionnel et permet d'éviter de perdre des mails sur une adresse auto-hebergée, mais ne te permet pas de lire des mails decrypté depuis la Own-Mailbox d'un autre. Comme mentionné dans la FAQ tes clefs privées se trouvent uniquement chez toi sur ta Own-Mailbox et chez personne d'autre.
Concernant la mise à jour nous n'avons pas réalisé cette partie encore, mais elle ne semble pas à premier abord poser de problème technique particulier, à moins que vous en voyez un?
[^] # Re: maintenance
Posté par kna . Évalué à 6. Dernière modification le 19 juin 2015 à 13:24.
Ce qui n'est pas clair c'est perdre des mails parce que le serveur est hors ligne (pas encore reçu) ou perdre des mails parce que le serveur a crashé (déjà reçus). Autrement dit backup MX ou backup de fichiers (ou les deux ?) ?
Je pense que le backup des boites-aux-lettres est plus important. Le backup MX est intéressant pour les cas où le serveur serait hors ligne longtemps (plus que le délai pendant lequel l'expéditeur le garde en mailqueue).
Une idée en l'air : livrer la machine avec une clé USB, puis lors de la génération des clés, forcer (ou fortement inciter) l'utilisateur à insérer la clé et backuper les clés GPG dessus.
L'idée est que si le boitier rend l'âme dans x années, on puisse le réparer/remplacer et simplement lancer le recovery pour récupérer dans l'état avant le crash.
Si tout ce qui est installé est empacqueté dans la distrib, un simple cron qui ferait l'upgrade peut faire l'affaire. Vous pouvez le sécuriser en le préconfigurant sur un dépôt, faire des tests sur un boitier et pousser sur le dépôt si c'est OK.
# Mail entrant
Posté par cedric . Évalué à 3.
Il y a un truc que je n'ai pas compris. Si on envoie un mail non chiffre sur une adresse d'un serveur gere par Own-Mailbox, est-ce que ca marche ? Et est-ce que de maniere automatique le systeme detecte que le mail n'est pas chiffre et le chiffre avec la clef publique du/des destinataire locaux pour eviter toute compromission du mail si quelqu'un avait un acces future a la machine (A la gpgit) ? Est-ce que le systeme de backup permettrait d'avoir cette fonctionnalite aussi sur les backup ?
De la meme maniere, quels sont les defenses mise en place pour limiter la compromission de la machine herbergeant Own-Mail ?
[^] # Re: Mail entrant
Posté par Zylabon . Évalué à 3.
Les accents :'(
Please do not feed the trolls
# Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tiens encore une connerie inutile...
Posté par Nairwolf . Évalué à 3.
Et ils utilisent quoi alors ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tiens encore une connerie inutile...
Posté par arcanes . Évalué à 1.
Le courrier papier n'est pas plus sécurisé que le mail correctement chiffré. Un courrier papier peut être ouvert.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Tiens encore une connerie inutile...
Posté par 16aR . Évalué à 1.
à la rigueur je veux bien que les vérifications complètes de clé/fingerprint se fasse sur un autre canal, mais dire que l'échange de clé ne se fait pas sur le même canal, c'est oublier l'existance de Diffie-Hellman…
# Open-Hardware
Posté par hurdman . Évalué à 1.
Salut, super projet !
Question sur l'électronique, avez-vous fait votre carte avec Kicad ?
Le projet est-il disponible quelque part pour jeter un oeil ?
[^] # Re: Open-Hardware
Posté par arcanes . Évalué à 1.
Merci,
Oui Kicad,
et oui le design est dispo sur le site, même s'il faut bien prendre en compte que ce n'est pas le design définitif.
[^] # Re: Open-Hardware
Posté par hurdman . Évalué à 4. Dernière modification le 19 juin 2015 à 17:41.
Ah oui, je n'avais pas vu le lien dans la faq !
http://www.own-mailbox.com/libre.html
Après avoir regardé le shémas vite fait, si j'ai bien tout vu, c'est un iMX233 avec 256Mb de ram et le contrôleur ethernet un ENC28J60 en 10 Base-T.
Vous ne trouvez pas ça un peu light pour un serveur de mail hébergeant un webmail ?
Pourquoi ne pas avoir routé avec des composants plus récent ou un chip avec l'ethernet déjà intégré ?
Ce n'est pas une critique mais quand je vois le nombre de design existants à base de compo X fois plus puissant (iMX6 genre cubox, AllWinner A13 dans le C.H.I.P à 9$, raspberry-pi etc .. ), je me pose la question de l'intérêt d'utiliser un 'vieux' arm926E-J.
[^] # Re: Open-Hardware
Posté par arcanes . Évalué à 2. Dernière modification le 19 juin 2015 à 20:10.
Bonjour,
Merci pour les retours, Nous avons publié ces design afin de montrer que nous sommes réellement ouverts. Mais il ne faut en aucun cas se baser dessus pour emmètre des critiques techniques, puisque comme précisé sur le site ce n'est pas définitif, sachant de plus que nous soudons et testons actuellement deux autres boards, que nous avons désigné et que nous venons de recevoir, exactement au même format, avec des contrôleur Ethernet différent et un processeur différent pour une des deux, afin de déterminer quel est le meilleur choix technique.
Quoi qu'il en soit le processeur est et sera largement assez puissant pour faire du mail. Il est évident que nous y veillerons particulièrement.
Il faut également prendre en comptes que l'on essait de réduire au maximum la consommation d’énergie afin qu'elle soit négligeable, puisqu'il s'agit d'un appareil qui doit être branché 24/24 7/7. Les IMX6, A13 et consort, sont plus gourmands.
Il s'agit aussi de réduire les coûts afin de proposer un produit le moins chère possible, à noter que contrairement à Rasbery pi, nous devons fournir un boitier, carte SD, transphormateur, cable ethernet, nom de domaine, certificat SSL. Pour proposer une version d'entrée de gamme à des tarifs compétitif, nous utilisons le minimum nécessaire pour réaliser bien notre fonctionnalité. Si par la suite il y a une forte demande pour du matériel plus puissant, on pourra envisager de faire une autre version spécifique.
Concernant C.H.I.P je vous invite à lire ce lien:
http://hackaday.com/2015/06/11/does-the-worlds-first-9-computer-cost-9/
Bonne Soirée, :)
Pierre.
[^] # Re: Open-Hardware
Posté par arcanes . Évalué à 1.
(Ps: D'ailleurs petite précision, il n'y a pas 256Mb de ram sur notre premier circuit, mais 512Mb.)
[^] # Re: Open-Hardware
Posté par arcanes . Évalué à 2.
Nous avons finalement fait un nouveau circuit à base de processeur A13.
N'hésitez pas à consulter la page de notre campagne Kickstarter:
https://www.kickstarter.com/projects/1547898916/own-mailbox-the-first-100-confidential-mailbox
# Mailpile
Posté par Moonz . Évalué à 3.
Mailpile n’est pas du tout un service, c’est un programme ayant pour vocation à être auto-hébergé.
# pgp bof bof gpg
Posté par paul . Évalué à 0.
je suis un utilisateur final.
j'utilise clawsmail.
j'ai essayé d'avoir une clef pgp et gpg, je dois avoir les 2 mais je ne sais pas ou elles sont. ni comment l'utiliser.
c'est chiant de ne pas savoir laquelle des 2 il faut prendre.
tout ce que j'ai bien compris c'est que pour ma clef elle se trouve bien au "MITchose"
j'ai voulu utiliser cette clef mais pas moyen, clawsmail fini par me faire desactiver le chiffrage.j'ai beau tourner ce chiffrage dans tous les sens rien ne part chiffré.
je voudrais chiffrer absolument tout ce que j'ecris, personne n'a à lire quoi que ce soit que je n'ai pas autorisé. Alors je restreins mes mails au strict minimum. je suis persuadé que ce chiffrement arrivera et se développera quand des mecs comme moi y arriverons enfin, et ce n'est pas faute d'avoir essayé.
parce que tous ceux qui ont posté ont plus que des connaissances de base au vu de ce qui est écrit au dessus.
finalement j'ai pris une adresse chez autistici.
alors un projet comme celui-la, je trouve que c'est sympa.
[^] # Re: pgp bof bof gpg
Posté par jyes . Évalué à 6.
J’ai l’impression qu’il reste des confusions dans ta manière d’aborder PGP, pas tant sur son installation et son fonctionnement que sur son utilité. PGP ne peut pas servir à chiffrer tous les messages que tu envoies, car cela garantirait que tu serais le seul à pouvoir les lire, ce qui perd beaucoup d’intérêt pour un message envoyé. PGP ne permet de chiffrer qu’à destination de quelqu’un (ou plusieurs) mais tu dois donc connaître la clef des personnes à qui sont destinés tes messages pour pouvoir les envoyer chiffrés. Tu as peut-être une installation de Claws-Mail et GPG complètement fonctionnelle, mais c’est normal que tes messages soient expédiés en clair si tu ne connais pas la clef de chiffrement (publique) de tes destinataires.
# Début de la campagne Kickstarter
Posté par arcanes . Évalué à 1.
Si vous souhaitez nous aider voici le lien de notre campagne Kickstarter:
https://www.kickstarter.com/projects/1547898916/own-mailbox-the-first-100-confidential-mailbox
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.