title: Own-Mailbox, charlatanisme ou incompétence ?
url: https://blog.imirhil.fr/own-mailbox-charlatanisme-ou-incompetence.html
hash_url: 55e6efbce1a72bd56f613d042801523e

<p><a href="https://www.own-mailbox.com">Own-Mailbox</a> est une solution se présentant comme « La boîte mail 100% confidentielle ».
Surf sur la vague de la vie privée, quitte à faire du <a href="http://www.zdnet.com/article/charlatans-the-new-wave-of-privacy-profiteers/">bullshit</a>
ou vraie solution de protection, une petite analyse rapide de ce nouveau projet.</p>
<p>Je précise que ce produit n’étant pas encore sorti, je n’ai pas pu tester en réel ce qui va suivre et je ne me base que
 sur les données disponibles sur le site du projet, les commentaires d’une
 <a href="https://linuxfr.org/news/own-mailbox-la-boite-mail-confidentielle-qui-vous-appartient-vraiment">dépêche Linuxfr</a> et d’un
 <a href="http://framablog.org/2015/09/23/mon-courrier-securise-cest-dans-la-boite/">article sur Framablog</a>.
Si quelqu’un du projet me donne accès à une vraie Own-Mailbox, je me ferai une joie de faire des tests et de revoir ma
 position.</p>
<h1>Matériel &amp; logiciel</h1>
<p>Sur ce point, rien à redire, Own-Mailbox semble bien basé sur du logiciel et du matériel libre, qui est le seul type de
 logiciel compatible avec de la sécurité ou de la protection de la vie privée.</p>
<h1>Réseau</h1>
<p>Own-Mailbox se présente comme une solution « plug-and-use » : vous juste branchez la machine, et ça juste tombe en
 marche tout seul. Sauf que le réseau, ce n’est généralement pas aussi simple que ça…</p>
<p>Un équipement derrière une box ADSL n’est pas accessible directement depuis Internet, puisqu’il y a la box devant. On
 doit donc procéder à ce qu’on appelle une « ouverture de port » : on signale à notre box ADSL que si elle voit passer
 du trafic sur son port X, elle doit le transférer à la machine Y.
Problème, cette procédure est 100% dépendante de votre fournisseur d’accès et du modèle de votre box ADSL.
Own-Mailbox annonce vouloir supporter l’ensemble du parc existant, ce qui me semble difficile à envisager et conduira de
 manière quasi-certaine à une période de pré-chauffage du projet, le temps que les auteurs traitent les nouveaux cas qui
 vont se présenter à eux au fur et à mesure de l’arrivée de nouveaux utilisateurs et donc configurations.</p>
<p>Le mail étant aussi une véritable plaie pour le réseau à cause du très gros volume de spam, la plupart des plus gros FAI
 (Orange, Free, Numéricable…) bloque le trafic mail sortant, afin de bloquer tous les spammeurs de leur réseau (en fait
 toutes les machines zombies de leur client…).
Certains FAI (Free) autorisent l’utilisateur à supprimer ce blocage, d’autres non (Numéricable) ou au prix d’un passage
 sur des lignes professionnelles hors de prix (Orange).<br />
Problème pour Own-Mailbox, un utilisateur chez un de ces fournisseurs ne pourra jamais héberger un serveur de mail chez
 lui, puisque tout est bloqué indépendamment de sa volonté.</p>
<p>L’équipe du projet propose alors un tunnel de port : c’est eux qui vont gérer le trafic mail de votre petite boîte, et
 vous le transmettra via un canal non bloqué.
Niveau sécurité et vie privée, cette solution pose sérieusement question…
 Dans ce mode, Own-Mailbox aura en effet accès à l’intégralité de votre trafic mail, qu’il soit chiffré ou non…
Sachant que la majeure partie des utilisateurs de Own-Mailbox risque de se retrouver dans ce cas, les personnes étant
 chez les trop rares FAI ne posant pas problème (OVH, FAI associatifs…) n’ayant généralement pas besoin de Own-Mailbox
 pour se monter un serveur de mail sécurisé à la maison, le côté « 100% confidentiel » prend une sacrée dose de plomb
 dans l’aile…  </p>
<p>De plus, j’imagine mal Own-Mailbox dédier une adresse IP par client juste pour y héberger le port 25 (SMTP n’ayant aucun
 moyen de signaler l’usage d’un port alternatif, c’est forcément le port 25 pour chacun), surtout en période de pénurie
 IPv4, la solution technique retenue risque fort d’être un serveur mail unique hébergé chez Own-Mailbox qui relaie
 ensuite le mail chez le bon client en fonction de l’adresse du destinataire.
Niveau centralisation du net, on se pose donc là et Own-Mailbox n’apporte plus un vrai auto-hébergement ni une
 décentralisation du net.</p>
<h1>Nom de domaine</h1>
<p>On retrouve le même genre de soucis avec le nom de domaine.
Own-Mailbox ne propose que d’utiliser un de leur sous-domaine en <em>.obm.me</em>.
C’est donc eux, et uniquement eux qui vont pouvoir contrôler le <a href="https://fr.wikipedia.org/wiki/Enregistrement_Mail_eXchanger">MX</a>
 associé à votre boîte mail, ie. la machine qui va réellement recevoir le courier en premier.
Si Own-Mailbox en a envie, et même en mode vraiment auto-hébergé (cf. problème précédent), ils peuvent donc rerouter
 l’intégralité de votre trafic mail vers où ils le veulent…
Et tout le monde sait qu’en terme de vie privée et de sécurité, les tiers de confiance, ça a <strong>toujours</strong> finit par
 déconner…<br />
Own-Mailbox a annoncé qu’il sera sans doute possible « dans un mode expert » de gérer son propre nom de domaine, mais
 comme pour le tunnel de port, quelqu’un ayant les compétences pour utiliser ce mode le place de facto parmi les
 personnes qui ne sont <em>plus</em> le marché de Own-Mailbox…</p>
<p>La position de Own-Mailbox, en plus de créer 2 <a href="https://fr.wikipedia.org/wiki/Enfermement_propriétaire">vendors-lockin</a>
 assez sévères, est d’autant plus surprenant qu’ils militent pour exactement l’inverse via
 <a href="https://www.own-mailbox.com/index-fr.php#javascript">leur FAQ sur JavaScript</a> :</p>
<div class="codehilite"><pre> Le code JavaScript peut-être changé à tout moment par l&#39;entreprise proposant le service.
 Donc sauf si vous vérifiez le code à chaque fois que vous accédez à vos e-mails (ce qui
 est impossible), vous laissez tout le pouvoir à cette entreprise de casser votre
 chiffrement à tout moment et pour toujours, sans même que vous ne le sachiez, puisque
 vous ne vérifiez pas.
</pre></div>


<h1>GPG</h1>
<p>On arrive sur la partie vraiment croustillante.</p>
<p>Own-Mailbox annonce que la gestion des clefs GPG va être automatique, directement prise en charge par le boîtier.
Or, tout le monde sait que dans la notion de clef privée, il y a <strong>privée</strong>, et donc qu’une telle clef ne doit se
 trouver qu’à un seul et unique endroit : sur la machine de l’utilisateur.
Si le boîtier est volé ou égaré, vos clefs sont dans la nature.
Premier point noir donc.</p>
<p>Couplé aux problèmes précédents, ça peut donner des choses assez drôle.
En effet, pour pouvoir gérer l’ouverture ou le tunnel de port, Own-Mailbox s’autorise à pouvoir se connecter à votre
 boîtier pour le configurer correctement ou agir sur votre modem.
Vos clefs privées étant sur ce même boîtier, Own-Mailbox y a donc potentiellement accès… Gloups…<br />
On peut imaginer encore pire.
J’ai précisé au dessus que Own-Mailbox pouvait rerouter l’ensemble de votre trafic mail, y compris celui chiffré par GPG.
Ils ont maintenant aussi accès à la clef privée permettant de déchiffrer les données…
Confidentialité vous aviez-dit ?  </p>
<p>Own-Mailbox intègre aussi GPG à leur webmail.
Déjà, ceci confirme bien que la clef privée est positionnée sur le boîtier, puisque le traitement ne peut alors être
 fait que côté serveur et pas sur la machine du client.
Ensuite, les webmails ne supportent qu’un seul des modes de fonctionnement de GPG, PGP/inline (l’autre étant PGP/MIME).
Or PGP/inline est le mode de fonctionnement qui protège le moins un message.
Il ne chiffre rien d’autre que le corps « texte » du message. Vous avez des pièces-jointes ? Pas chiffré. Un corps
 « HTML » ? Pas mieux.</p>
<p>L’utilisation du mode PGP/inline est confirmé par le fait que vous pourrez lire vos couriers sur smartphone. PGP/MIME
 n’est actuellement géré par aucun client mail Androïd (par exemple
 <a href="https://code.google.com/p/k9mail/issues/detail?id=5864">K9-mail</a> ou iOS et seul PGP/inline y est supporté.
PGP/inline pose aussi d’autres problèmes, comme de polluer tous les lecteurs mails qui ne supportent pas du tout GPG.
Pire, PGP/inline souffre de beaucoup de <a href="https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/">défaut de conception</a>
 qui le rendent en réalité très dangereux pour une utilisation réellement critique (on peut usurper une signature, etc).<br />
Si un utilisateur souhaite utiliser PGP/MIME, il devra utiliser un vrai client mail (Thunderbird+Enigmail ou Kontact par
 exemple), et réussir à extraire la clef privée du boîtier pour pouvoir s’en servir avec son client lourd.</p>
<p>Un autre problème, qui a été soulevé par plus ou moins tous ceux qui gravitent autour de la sécurité et de la vie privée
 en ce moment : le mail est un protocole non fiable, qui ne <strong>peut</strong> pas être confidentiel.
En effet, même avec GPG, un mail qui circule sur le réseau contient énormément de méta-données. Émetteur, destinataire,
 sujet du mail, pièces-jointes si on utilise PGP/inline, ces morceaux-là ne sont pas chiffrés par GPG et circulent donc
 en clair.
Ce sont ces données dont raffole aujourd’hui la NSA et toutes les agences gouvernementales, y compris les fameuses boîtes
 noires françaises.
Avec ou sans GPG, on finit donc à poil sur le réseau, le contenu réel d’un mail n’intéressant pas du tout les espions.
Ce n’est pas pour rien que le mail et GPG ont été rayés de la carte des ateliers café-vie-privée, vous avez beaucoup
 trop de manières de mal l’utiliser et de vous retrouver à poil sur Internet sans le savoir.</p>
<p>Bref, la gestion de GPG par Own-Mailbox semble juste catastrophique et ne peut de toute façon pas apporter la
 confidentialité annoncée, d’autant plus avec le mode inline de GPG…</p>
<h1>Technologie « PLM »</h1>
<p>Dans le cas où notre correspondant ne supporte pas GPG, Own-Mailbox a défini un mode de secours : le PLM ou « Private
 Link Message ».
Plutôt que d’envoyer un message avec le contenu en clair, Own-Mailbox va envoyer un mail avec un lien qui permettra
 d’accéder au contenu réel qui lui restera bien à l’abri sur votre boîtier.</p>
<p>Vu les remarques du point précédent, ce mode n’apporte <strong>strictement</strong> aucune sécurité ni confidentialité supplémentaire.
En effet, le mail d’alerte circulera « en clair » dans le réseau et les agences de renseignement n’auront aucun mal à
 récolter le fameux lien « privé » du mail pour accéder au contenu réel.</p>
<p>Même en supposant que le mail circule via le protocole <a href="https://fr.wikipedia.org/wiki/StartTLS">STARTTLS</a> qui chiffre le
 transport d’un mail, ce protocole est très facilement contournable par une agence NSA-like puisque son signalement dans
 le réseau est non authentifié et qu’il suffit simplement de supprimer les paquets réseaux contenant « STARTTLS » pour
 que le boîtier pense que son correspondant ne supporte pas STARTTLS et balance son mail en clair complet.</p>
<h1>TLS</h1>
<p>Own-Mailbox envisage d’utiliser <a href="https://letsencrypt.org/">Let’s Encrypt</a> pour la génération des certificats pour HTTPS
 et SMTP/STARTTLS.
C’est une très bonne idée, Let’s Encrypt allant être une des trop rares autorités de certification non commerciales ou
 étatique (la seconde étant <a href="https://www.cacert.org/">CAcert</a>) et la seule intégrée par défaut aux navigateurs.</p>
<p>TLS n’est cependant pas la panacée, et d’autant plus dans un contexte d’auto-hébergement.
En effet, TLS laisse aussi passer des méta-données via <a href="https://fr.wikipedia.org/wiki/Server_Name_Indication">SNI</a>
 qui permettent par simple observation du réseau de savoir ce que vous visitez.
Il n’y a même à nouveau rien à observer dans le cas de l’auto-hébergement, les IP source ou destination portant déjà par
 elles-mêmes l’identité des personnes derrière.</p>
<p>Dans le cas de SMTP, TLS est aussi une protection très faible pour des raisons techniques, STARTTLS étant très facilement
 annulable par quelqu’un qui serait situé entre les deux extrémités du réseau (une sonde NSA par exemple) et dont on ne
 peut pas durcir la sécurité sous peine de problèmes avec certains serveurs mails encore (trop) présents dans le réseau.</p>
<p>TLS ne permet donc que de protéger sa sécurité, et en aucun cas sa confidentialité.</p>
<h1>Gestion courante d’une machine</h1>
<p>Un des gros soucis de l’auto-hébergement actuel reste la gestion courante de la machine.
Appliquer les patchs de sécurité, vérifier qu’on n’est pas devenu un zombi du réseau participant à l’envoi de spam ou au
 bruteforce de serveur, ça demande du temps et des compétences techniques, que beaucoup du cœur de marché visé par
 Own-Mailbox ne possédera pas.</p>
<p>Cette administration n’est pas facilement automatisable, puisqu’elle dépend bien souvent de votre configuration de réseau,
 par exemple pour n’autoriser que vos machines locales à se connecter au service SSH ou pour bien régler fail2ban pour
 éviter qu’il ne blackliste par erreur votre machine.
Et les différents paramètres échappent totalement à quelqu’un qui souhaite du « plug-and-use » parce qu’il n’a justement
 pas les compétences pour faire par lui-même…
On risque donc fort d’avoir affaire à la vente de boîtier qui créeront dans un avenir proche un botnet géant au service
 du mal parce qu’ils auront échappé au contrôle de leur propriétaire…</p>
<p>Dans les discussions que j’ai pu avoir avec les auteurs du projet, il semble qu’ils souhaitent s’orienter vers faire
 cette gestion par eux-même, en mode automatique.
Même si cette gestion était réellement automatisable et en supposant que l’utilisateur soit en mesure de renseigner les
 paramètres de configuration nécessaires, cela signifie une fois de plus que le véritable maître du boîtier est plus
 Own-Mailbox que vous même, avec tout ce que cela implique…</p>
<h1>Incompétences des développeurs Own-Mailbox</h1>
<p>Au cours des différents échanges que j’ai pu avoir avec les auteurs de Own-Mailbox, une chose qui frappe assez rapidement
 quelqu’un du domaine est leur apparente incompétence technique.
Un florilège de ce que j’ai pu relever.</p>
<p><strong>« Tout d’abord en France la majorité des FAI ne bloque pas le port 25, encore moins le port entrant (Free, Numéricable: aucun problème) »</strong><br />
C’est totalement faux, Free étant même le parfait contre-exemple puisque
 <a href="http://www.freenews.fr/freenews-edition-nationale-299/assistance-13/lutte-contre-le-spam-blocage-du-smtp-sortant-des-jeudi-4317">tout est bloqué en sortie par défaut</a>, même si effectivement ce blocage est débrayable.
  C’est aussi le cas <a href="http://communaute.orange.fr/t5/mon-mail-Orange/Utilisation-du-port-25-pour-acceder-à-un-autre-serveur-smtp-avec/td-p/148447">chez Orange</a>
  qui lui ne permet pas le déblocage, tout comme <a href="http://assistance.sfr.fr/runtime/internet-et-box/securite/filtrage-port-smtp-25.html">SFR</a>.
Les seuls FAI ne bloquant pas SMTP en France sont à ma connaissance OVH et tous les FAI associatifs de la galaxie FDN.
C’est encore pire pour nos amis belge, <a href="http://www.behostings.be/client/knowledgebase/6/Configuration-Serveur-mail-sortant-SMTP.html">quasiment aucun FAI ne laisse passer SMTP</a>.</p>
<p><strong>« La plage d’adresses du LAN n’ont strictement aucun impact sur la conf de la Own-Mailbox »</strong><br />
Ceci est tout simplement impossible si on veut faire les choses correctement avec une machine directement accessible
 sur Internet.
La configuration du serveur SSH ou de fail2ban doit nécessairement contenir des données propres au réseau sous peine
 d’avoir des trous dans la raquette.</p>
<p><strong>« En ce qui concerne les méta-données, l’auto-hebergement est une prérogative pour pouvoir commencer à penser à protéger les méta-données »</strong><br />
C’est même totalement le contraire.
Si tout le monde est chez le même prestataire pour faire du mail, le trafic mail entre chaque utilisateur passe par le
 réseau local du prestataire, donc sous les radars des sondes NSA &amp; cie déployées elles sur le réseau Internet public.
Au contraire, plus on fait d’auto-hébergement, plus on simplifie la tache des espions, puisqu’il suffit d’intercepter
 un seul mail pour y associer une adresse IP d’émission et de réception et ensuite ne plus avoir besoin de s’attaquer au
 contenu du trafic mail pour savoir qui intervient (l’IP suffit alors).</p>
<p><strong>« Faire tourner un serveur mail sur un serveur Tor et/ou envoyer les mail en SMTPS over TOR peut résoudre complétement le problème des méta-données »</strong><br />
C’est aussi totalement faux.
Tor ne permet que (et uniquement que) de masquer l’adresse IP de son émetteur, et l’adresse IP du destinataire dans le
 cas d’un <a href="https://www.torproject.org/docs/hidden-services.html">service caché</a>.
Si on fait passer du trafic SMTP dans Tor, le nœud de sortie relaiera quand même le mail sur l’Internet public, donc aux
 sondes NSA &amp; cie avec les métadonnées accessibles voire le contenu si pas de GPG.
Et on ne peut actuellement pas faire un service caché mail dans Tor, puisque Tor interdit l’usage du DNS alors que SMTP
 repose massivement dessus (au moins pour la détermination du MX, mais aussi pour la gestion du spam comme avec
 <a href="https://fr.wikipedia.org/wiki/DNS_Black_Listing">DNSBL</a>, <a href="https://fr.wikipedia.org/wiki/DomainKeys_Identified_Mail">DKIM</a>
 ou <a href="https://fr.wikipedia.org/wiki/Sender_Policy_Framework">SPF</a>).</p>
<p><strong>« Avec un simple Capcha (sic) tu échappes avec certitude à la surveillance de masse »</strong><br />
Si c’est vraiment le cas, je pense que ce n’est pas Own-Mailbox que vous devriez kickstarter…
Voire même vous devriez immédiatement contacter le Ministère de l’Intérieur, je crois qu’ils ont du travail pour vous…</p>
<p><strong>« Si tous le monde utilisait son serveur smtpS (chiffré en TLS) chez soit et envoyait ses mail via tor il n’y aurait pas de fuite de meta-données »</strong><br />
Sur le principe, je suis d’accord. Mais ça demande de revoir <strong>tous</strong> les protocoles mail existants.
SMTPS a été <a href="https://en.wikipedia.org/wiki/SMTPS">déprécié</a> au profit de STARTTLS (ce qui est possiblement une erreur
 vis-à-vis de la sécurité et de la vie privée, mais c’est un fait) et comme mentionné ci-dessus, SMTP n’est actuellement
 pas compatible avec Tor à cause du DNS inexistant.
Tous les cryptologues et chercheurs en sécurité du moment sont unanimes sur un seul point : SMTP est mort et enterré si
 on se place d’un point de vue sécurite &amp; vie privée, mais il n’existe actuellement aucun protocole pour remplacer
 réellement le mail et encore moins de manière compatible.
Il existe bien des solutions émergentes, type <a href="https://tox.im/">Tox</a> ou <a href="https://bitmessage.org/">Bitmessage</a>, mais ni
 utilisés ni utilisables à grande échelle, ou encore <a href="https://caliopen.org/">Caliopen</a>, mais ces projets sont de très
 grosses envergures et mettront encore des années avant d’être accessible au grand public.<br />
En prime, en prenant la déclaration de Own-Mailbox au pied de la lettre, on ne peut que leur donner raison : leur projet
 est mort-né, ni sécurisé ni confidentiel et il faut commencer à monter quelque chose de neuf qui ne soit pas du mail. </p>
<p><strong>« Oui les méta données permettent à la NSA de savoir qui sont tes amis, mais le contenu leur permet de savoir ce que tu penses et ce que tu fais, ce qui est bien plus grave »</strong><br />
C’est faux aussi.
Les méta-données sont
<a href="https://www.eff.org/fr/deeplinks/2013/06/why-metadata-matters">aussi voire plus révélatrices que le contenu lui-même</a>.
La surveillance de masse dénoncée par Edward Snowden ou le tracking publicitaire sur Internet se contre-fiche réellement
 de votre contenu tant que vous ne devenez pas une de leur cible prioritaire.
Et si vous l’êtes réellement, GPG et TLS ne vous seront d’<a href="https://en.wikipedia.org/wiki/Tailored_Access_Operations">aucune utilité</a>.</p>
<p><strong>« Though it should be said that man in the middle attack cannot be used for mass surveillance. Because Man in the middle attacks are highly detectable »</strong><br />
(Commentaire caché dans le source de leur site web).
La NSA appréciera donc que <a href="https://nsa.imirhil.fr/documents/media-35658/pages/5.png?size=big">ses attaques</a> soient
 inutilisables, en particulier leur système
 <a href="https://nsa.imirhil.fr/documents/media-35686/pages/21.png?size=big">BYZANTINE HADES</a>
 ou encore <a href="https://nsa.imirhil.fr/documents/media-35689/pages/14.png?size=big">QUANTUM</a>…</p>
<h1>Conclusion</h1>
<p>Charlatanisme avéré ou manque de bagage technique évident ?
Je me pose encore la question…</p>
<p>L’équipe semble de bonne volontée et on est à des lieux des véritables arnaques comme
 <a href="https://www.indiegogo.com/projects/anonabox-access-deep-web-tor-privacy-router">Anonabox</a>,
 <a href="https://www.kickstarter.com/projects/1052775620/wemagin-smart-usb-drive">Wemagin</a>, ou
 <a href="https://www.kickstarter.com/projects/916285694/webcloak-advanced-web-security-and-online-privacy">Webcloak</a>, puisqu’au
 pire, Own-Mailbox sera, elle, une bonne solution d’auto-hébergement.
Mais elle se retrouve alors en compétition directe avec <a href="http://labriqueinter.net/">La brique Internet</a> ou
 <a href="https://yunohost.org/">YunoHost</a> et n’est du coup plus du tout compétitive, puisqu’elle se concentre uniquement sur
 le mail quand les autres proposent n’importe quel service (XMPP, blog, partage de fichiers…) et de manière beaucoup
 plus propre (VPN et IP dédiée).</p>
<p>Les auteurs cherchent-ils à profiter de la vague Snowden pour glisser un peu de bullshit bingo et attirer la ménagère
 de moins de 50 ans dans leurs filets ?
En tout cas sur la partie sécurité et confidentialité, pourtant mise en avant partout et reprise massivement pas la
 presse, ils sont autant à poil qu’un mail sur le réseau.</p>
<p>En espérant qu’ils tiendront compte de l’énorme historique qu’on a déjà sur la (non-)sécurisation du mail et reverront
 leur campagne de communication, avant de fonder au mieux un énorme botnet et au pire un
 <a href="https://about.okhin.fr/posts/Crypto_parties/">futur cimetière</a> de
 <a href="extremiste-oui-et-meme-fier-de-letre.html#GreatPower">lanceurs d’alerte</a>…</p>
<p>En bref, Own-Mailbox auto-hébergement peut-être, Own-Mailbox sécurité &amp; vie privée, définitivement non.</p>
<p><em><a href="own-mailbox-la-reponse-a-la-reponse.html">La réponse à la réponse de Own-Mailbox</a></em> |
<em><a href="own-mailbox-suite-et-fin.html">La conclusion</a></em></p>
