Own-Mailbox: la boite mail confidentielle qui vous appartient vraiment!

72
18
juin
2015
Matériel

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.

photo du boitier

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:

  1. Le chiffrement de mail est compliqué à configurer surtout dans différents environnements (OS, logiciel de mail, version).
  2. 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)
  3. On ne peut pas envoyer de messages chiffrés aux personnes qui n'utilisent pas encore GPG.
  4. 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.

Le tout petit Own-Mailbox

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.

  • # chouette projet

    Posté par . É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 . É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 . Évalué à 1.

        Je me trompe ou tu ne réponds pas à la question ?
        à moins que

        Tu as tout à fait raison

        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 . É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 . É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 . Évalué à 8. Dernière modification le 18/06/15 à 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 :

        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 !

        Enfin bref, bonne chance :)

        • [^] # Re: chouette projet

          Posté par . Évalué à 4. Dernière modification le 18/06/15 à 16:45.

          Ok, je pensais que les dépêches devaient être écrit avec un style journalistique et impersonnel, mais appartement non! ;)

          Enfin bref, bonne chance :)

          Merci! :)

  • # petit doute sur l'argumentaire

    Posté par . É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 (page perso) . Évalué à 3.

      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 ?

      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 . É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 (page perso) . Évalué à 3.

          Merci pour le retour, ;)

          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 . Évalué à 10. Dernière modification le 18/06/15 à 21:35.

            Oui concernant GPG c'est pareil sauf que tu peux le faire via un webmail accecible de partout, ce qui est nouveau.

            comment on donne le lien finalement ?

            Par mail.

            sans question, le lien n'offre aucune protection s'il est donné sur un canal non sûr (SMS, email en clair, etc.) ;

            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é.

            et le mot de passe/réponse à la question ?

            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.

            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 ;

            Non ce n'est pas moi, c'est les gens sur leur Own-Mailbox.

            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) ;

            Nous aurons forcement un CA.

            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.

            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 . É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 (page perso) . É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 . É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 (page perso) . É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.

      It's a fez. I wear a fez now. Fezes are cool !

      • [^] # Re: Bonne chance !

        Posté par . É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 . Évalué à 4. Dernière modification le 18/06/15 à 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:

    Your message is stored on the Own-Mailbox through HTTPS. The Own-Mailbox sends a HTTPS link to your correspondent, so that he can access the message in encrypted form. He can answer you using HTTPS protection.

    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 . Évalué à 6. Dernière modification le 18/06/15 à 15:52.

      La réponse est dans la FAQ bien évidemment

      ➜Can you explain more in details how Private Link Message (PLM) works?
      Private Link Message (PLM) allows you to send and receive messages from people who don't use GPG.

      In order to send a message you can send an HTTPS link to your correspondent.

      The link is temporary: once clicked by your correspondent it is too late to spy, the link does not work anymore. The link also has an expiration date that you can select. If your correspondent did not access the message before this date, it is too late to read.

      The link is filtered by a question. Depending on the level of surveillance you think you are in, the question can be a simple captcha to avoid bots, a secret question that your correspondent can answer but not the NSA, or a request for a password previously exchanged with your correspondent, or no question at all.

      Your correspondent will have a web interface to answer your message privately. You can also activate a permanent HTTPS interface for anyone to send you a message privately at any time.

      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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 5.

          Certains se plaignent déjà juste quand on leur envoie des messages clear-signed

          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 (page perso) . Évalué à 3.

          • [^] # Re: Pas compris

            Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à -3.

              (« 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)

              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 . Évalué à 2. Dernière modification le 19/06/15 à 09:20.

                (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)

                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 (page perso) . Évalué à 0.

                  et même dans un lecteur gérant PGP, il y a un risque en masquant cette information

                  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).

                  Sinon, si comme tu dis, tu utilises un lecteur masquant cette information, tu ne sauras jamais que tu as reçu un mail signé

                  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.

                  Peut être que c'est justement voulu de montrer explicitement que le message a été signé.

                  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 (page perso) . Évalué à 10.

                    d'une en "mentant" car ce n'est pas une pièce jointe

                    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) :

                    Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of "application/octet-stream" with no parameter sub-arguments. How such data are handled is up to an implementation, but likely options for handling such unrecognized data include offering the user to write it into a file (decoded from its mail transport format) or offering the user to name a program to which the decoded data should be passed as input.

                    • [^] # Re: Pas compris

                      Posté par (page perso) . Évalué à 0. Dernière modification le 19/06/15 à 10:40.

                      un type MIME qu’il ne reconnaît pas

                      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 (page perso) . Évalué à 6. Dernière modification le 19/06/15 à 10:53.

                        cette "forme" de PGP utilise un endroit qu'il ne devrait pas utiliser, car non prévu pour ça.

                        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 :

                        • envoyer des pièces jointes (multipart/mixed) ;
                        • envoyer plusieurs versions d’un même message (multipart/alternative, typiquement, une version texte et une version HTML, ou encore une version française et une version anglaise) ;
                        • envoyer plusieurs messages en un seul (multipart/digest) ;
                        • envoyer un message « forwardé » (multipart/rfc822) ;
                        • envoyer un message signé (multipart/signed) ;
                        • envoyer un message chiffré (multipart/encrypted).

                        Au passage, multipart/signed et multipart/encrypted ne sont pas des inventions de PGP, ça existait avant.

                        • [^] # Re: Pas compris

                          Posté par (page perso) . Évalué à -5. Dernière modification le 19/06/15 à 11:13.

                          Tu sembles considérer que MIME ne sert qu’à transporter des pièces jointes,

                          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)

                          Au passage, multipart/signed et multipart/encrypted ne sont pas des inventions de PGP, ça existait avant.

                          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 (page perso) . Évalué à 10.

                            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.

                            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).

                            Mais j'ai été emmerdé que par des gens utilisant PGP

                            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…

                            un très bonne idée sur le papier, mais aucune gestion de l'ancien

                            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 (page perso) . Évalué à 8.

                    Content-Type: multipart/signed; micalg=pgp-sha1;
                     boundary="Sig_/uJgZNEH_BKzxBiybsydNVyX"; protocol="application/pgp-signature"
                    

                    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 (page perso) . Évalué à 5.

                (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)

                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 (page perso) . Évalué à -1.

                  un MTA indélicat qui touche un peu trop au corps du message

                  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 . Évalué à 5.

                    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é.

                    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 (page perso) . É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 . É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 . Évalué à 1. Dernière modification le 18/06/15 à 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 . Évalué à 6. Dernière modification le 19/06/15 à 13:24.

        Le back-up peer-to-peer est optionnel et permet d'éviter de perdre des mails sur une adresse auto-hebergée

        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).

        Comme mentionné dans la FAQ tes clefs privées se trouvent uniquement chez toi sur ta Own-Mailbox et chez personne d'autre.

        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.

        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?

        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 . É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 ?

  • # Commentaire supprimé

    Posté par . Évalué à -10.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Open-Hardware

    Posté par . É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 . É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 . Évalué à 4. Dernière modification le 19/06/15 à 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 . Évalué à 2. Dernière modification le 19/06/15 à 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 . É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 . É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 . Évalué à 3.

    mais de nombreux autres services ont fleuri récemment (Proton Mail, Tutanota, Mailpile, Lavaboom, Openmailbox).

    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 . É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 (page perso) . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.