http://korben.info/le-mauvais-etat-desprit-de-peerio.html
Je vous ai déjà parlé de Nadim Kobeissi chercheur en sécurité et auteur de Cryptocat, MiniLock et Peerio. Je vous ai d’ailleurs déjà présenté Peerio, un outil de messagerie et de stockage chiffré de bout en bout et open source. C’était du lourd et du sérieux, Nadim Kobeissi y apportant toute sa crédibilité en tant que cofondateur. Mais dans une…
La chose ne semble pas bien claire. Le client “contenait” deux failles, qui ont été corrigé an amont de la publication du rapport.
Une autre chose n’est pas claire : peerio-client-api est l’API mise en oeuvre dans les clients mobiles - seulement distribués a des testeurs choisis.
Les utilisateurs “traditionnels” du plugin chrome ou des applications Linux/Mac/Windows dépendent exclusivement de peerio-client, un autre repository, également open-source, également sujet aux tests de Cure53.
Envoyer son code à un auditeur avant de ne publier l’application n’a rien de choquant. Corriger en amont non plus. Et un peu de transparance ne fait pas de mal.
Pour répondre aux allégations de menaces judiciaires, je peux témoigner qu’au jour d’aujourd’hui, nous n’avons pas sollicité les services de notre avocat. Et continuerons d’ignorer Nadim.
Si Nadim est sémantiquement co-fondateur, il ne fait plus partie de nos équipes aujourd’hui. De fait, la crédibilité que vous lui accordez repose sur sa connaissance d’un produit qu’il a refusé de corriger, à la réception du premier rapport de Cure53. Et que nous avons du ré-écrire, après avoire monté une nouvelle équipe.
A bon entendeur.
“sémantiquement co-fondateur”??? “il ne fait plus partie de nos équipes aujourd’hui” : on n’avait bien compris que lorsqu’il écrit “I left Peerio” c’est plus ou moins ce qu’il voulait dire.
“I left Peerio”, c’est sa version des faits. Je remet en doute globalement tout ce qu’il à pu dire à notre sujet.
Si Nadim, ou quiconque, trouve à redire à notre code, venez troll ici : https://peerio.zendesk.com/hc/en-us/articles/203981385-Bug-Bounty
Cure53 re-valide régulièrement notre code. L’infra est audité. Les processes sont audités. Et de temps à autre, on ouvre un rapport au publique, par soucis de transparence.
Notez que la conclusion du rapport cité, est que toutes les vulnérabilités identifiées ont été adressées : https://cure53.de/pentest-report_peerio.pdf
"Lastly, in December 2015, the fixes of all reported issues were completed by the Peerio development team and afterwards verified by the Cure53 team."
Concluons: les failles trouvés sur la librairie de notre client mobile sont toutes corrigées. Le client mobile va bientôt être ouvert au public.
Le client desktop (https://github.com/PeerioTechnologies/peerio-client) ouvert en béta ne présente aucune faille connue.
Toute contribution sur le sujet peut faire l’objet d’une bounty.
Pour répondre plus généralement
les mecs à la direction de Peerio aient prévu comme business model d’intégrer une backdoor (porte dérobée) dans les versions privées vendues aux entreprises (sur demande de celles-ci évidemment)
Pour avoir travaillé dans un SI, je ne vois pas ce qui est choquant. Il est tout a fait normal que les données sur une messagerie d’entreprise soient la propriété de cette entreprise. Et qu’au départ d’un collaborateur, l’on doive pouvoir conserver un accès à sa messagerie, ses ordinateurs et téléphones d’entreprise, …
S’il s’agit toujours d’une requète que nous serons bien obligé d’implémenter pour des raisons contractuelles et légales, signalons qu’aujourd’hui, la chose n’est pas possible. Ceux qui auront pris le temps de lire nos specs (également publique https://github.com/PeerioTechnologies/peerio-client/blob/master/SPECIFICATION.md & https://github.com/PeerioTechnologies/peerio-client/blob/master/THREATMODEL.md) comprendront qu’il est techniquement impossible, pour nous, de déchifrer une donnée que votre client encode avec votre paire de clés publique et privé.
Rappelons que nous ne sommes toujours pas en mesure de réinitialiser un mot de passe lorsqu’il est perdu - nous ne pouvons que supprimer votre compte (https://peerio.zendesk.com/hc/en-us/articles/202927099-I-lost-my-passphrase-what-can-I-do-/).
Et que les sources de nos paquets sont également publiques (https://linux.peerio.com/sources).
Y a une grosse différence entre laisser un accès administratif et laisser une faille dans un système de chiffrement (backdoor). Ton raisonnement ne tient pas du tout. Quelqu’un d’autre pourrait exploiter une backdoor, pas forcément un accès maîtrisé.
Ensuite si l’idée était de créer un chiffrement de bout en bout, je ne vois pas ce que vient faire ce genre de spécification dans le projet. Même pour des raisons légales … y a un moment où il faut choisir son camp.
Peux-tu éclaircir la partie Minilock ? Parce qu’il était aussi question de ça. Céder ses droits, tout ci tout ça.
Avant de qualifier mon raisonnement, je te prie de lire les docs que je mentionne dans la réponse que tu commentes.
Mon point est : “sémantiquement”, la back-door discuté dans l’article n’est rien d’autre que cet accès administratif dont je parle.
Notre threat model et la doc de l’API envoyés précédement illustre le fonctionnement du client. En les lisant, tu comprendras pourquoi techniquement, toute backdoor devrait se faire côté un client (chiffrer la donnée en rajoutant une clé arbitraire, pour laquelle nous aurions le couple privé/publique).
Protocolairement, mathématiquement, conceptuellement, côté serveur (je suis sysadmin, seul root, à héberger : c’est un fait, je ne sais pas comment faire passer le message plus clairement) on ne peut pas déchiffrer. Pas de backdoor.
Seul discussion : la conformité aux exigences d’une entreprise.
La partie miniLock : lors de son départ, comme souvent, il lui a été rappelé que le code produit durant son exercice restait la propriété de Peerio.
La nouvelle lib dont il est question dans l’audit est un rewrite complet, n’ayant pu fixer l’original.
Il n’a jamais été question de monter une solution propriétaire.
MiniLock est un concept indépendant, https://minilock.io/.
Le business de Peerio tourne autour de la revente et l’exploitation d’un service dans le secteur privé ou service publique. Je ne suis sans doute pas au courrant de tous les détails, je reste sceptique.
Juste pour info s’il y en a que ça intéresse, il sera en conf à L’INRIA de Nancy le 2 février à 13h30, voici le sujet :
“The scientific cryptography community produces a wealth of research
papers each year. But with the rise of terminology and even conferences
focusing on “real world” cryptography, it seems that even terms such as
"practical” cryptographic results have become out-of-touch with what
affects the users and engineers of secure systems.
In this talk, I will discuss my pre-INRIA work on producing secure
encryption systems accessible to a general audience. I then shift to
discussing how our INRIA research group produces cryptographic results
that go beyond theoretical attacks to make the contributions directly
relevant to general practitioners in computer engineering. How can we
help engineers and scientists better verify their protocol
implementations? Secure their web applications from the get-go? Write
code in languages built to protect it from failure? After an overview of
other PROSECCO projects, I will present my own work on ProScript, a
subset of JavaScript specifically tailored for implementing
cryptographic protocols, and that allows regular engineers to
automatically generate human-readable, ProVerif-verifiable applied-pi
calculus models of their implementations.
Ultimately, this is a talk about the need to make cryptography a field
that more often produces results that directly relate to practitioners
of other computer sciences and to engineers.
"
D’accord, je comprends mieux de quoi il s’agit. J’ai rien dit … ça me paraît correcte.
Pour le coup, la signature d’un contrat de confidentialité ne va effectivement pas dans son sens. Je ne connais pas tous les détails (toi non plus apparement), mais je pense qu’on peut oublier le titre de “mauvais état d’esprit de Peerio” … c’est aller un peu vite en besogne.
Backdoor ou pas, un dev détestera toujours les pressions des entreprises. C’est pour cela qu’il y a de plus en plus de dev solo et de plus en plus d’entreprises qui peinent à trouver des dev. C’est comme si on avait demandé à Picasso de faire partie d’une entreprise de peinture et qu’on lui ait dicté comment peindre pour qu’il soit plus rentable ou qu’il soit “administrativement correcte”. Ça ne marche tout simplement pas. Quand on perd un talentueux dev comme Nadim, il faut se demander ce qu’il aurait été nécessaire de faire pour le garder. A moins que le but était de le pousser dehors…
Je ne voudrais pas que l’on me reproche de diffamer ou d’exercer une quelconque pression.
Nadim est libre de s’expliquer sur les raisons de son départ. Je peux confirmer qu’il s’agissait d’une décision unanime du reste l’équipe.
Je peux comprendre son ressentiment, mais rien ne justifie les sottises qu’il peut insinuer sur twitter.
C’est effectivement tragique, pour une start-up, de perdre un développeur fondateur en moins d’un an.
Fort heureusement, l’équipe rassemble d’autres talents.
D’accord, donc après avoir lu les interventions de Syn, je suis un peu plus mitigé sur Nadim qu’après la lecture de l’article. Le problème c’est que Peerio & co étant des outils sur lesquels la confiance est un élément clef, je ne suis plus convaincu. Peut-être que Nadim a pris la mouche et raconte des sottises pour se venger ou peut-être que Peerio cherche à étouffer des révélations. Difficile de savoir qui croire.
Pour trancher ce serais vraiment bien que quelqu’un (Korben, en édit de son article ? 
) apporte des faits qui puissent nous permettent de trancher. Car dans le cas où Peerio est irréroprochable, ce serait bête de perdre un tel service juste à cause d’une rumeur lancée qui détruit la confiance de ses clients.
Je vous encourrage vivement à lire la spec : https://github.com/PeerioTechnologies/peerio-client/blob/master/SPECIFICATION.md
Et si vous doutez toujours, à valider son implémentation (même repository). Tout y est, jusqu’au makefile générant le paquet debian.
De même que pour l’API v2 dont il est question dans le rapport évoqué par cet article, le client desktop a fait l’objet de plusieurs échanges avec Cure53.
Discuter sécurité en 144 caractères, c’est passer à côté du sujet.
J’ai lu avec intérêt les échanges sur cette pseudo-affaire. Quelles que soient les qualités de Nadim Kobeissi en crypto ou en dev, il n’a besoin de personne pour se décrédibiliser, il suffit de lire son compte twitter: ce mec a un égo surdimensionné, chie sur tous ceux qui ne sont pas d’accord avec lui, et est capable de passer de la rigueur scientifique à la plus mauvaise foi d’un tweet à l’autre. Son blog est bien plus intéressant.
Quoiqu’il en soit, qu’il ait pondu deux petits softs, dont un, cryptocat, dont il dit lui même qu’il l’avait mal écrit et qu’il était blindé d’erreur de dev, et Minilock, qui est excellent dans son concept, mais ne fait qu’assembler des bibliothèques JS écrites par d’autres (TweetNaCl, scrypt, zxcvbn) dans un code d’une centaine de lignes, ne suffit pas à faire de lui un dev “génial”. Mais je ne connais pas le reste de ses contributions.
L’image qu’il renvoie est plutôt celle de quelqu’un qui sait, et aime, à faire parler de lui et se mettre en avant.
Du coup, voir le sieur faire son caca sur Twitter et diffamer Peerio, à cause de leurs divergences internes, je trouve ça un peu pathétique (pour info, dans tous mes contrats d’employé, il était mentionné que la propriété de mes développements extérieurs, en rapport avec l’activité de la boite, pouvaient être réclamés par la dite boite).
Pour ton dernier paragraphe, même si ce n’est pas écrit dans le contrat, si tu développes quelque chose en rapport avec ta boite même chez toi, ça peut mener à des conflits si tu ne veux pas donne ton boulot. Et il y a pas mal de chance que la boite gagne, la jurisprudence de ce genre de cas est assez importante.
En revanche là ça parle d’un boulot qu’il a fait AVANT d’être dans cette boite. Dans ce cas la boite n’a aucun droit dessus.
Ai pepito !
Je ne sais plus quoi penser ou croire. Hier on nous présente un outil qui est censé chiffrer des fichiers depuis un navigateur et protéger notre vie privée ( http://www.funinformatique.com/chiffrez-simplement-des-fichiers-depuis-votre-navigateur/), le lendemain on nous informe que cet outil contient un backdoor et notre confidentialité est en danger.
Bref, la vie privée n’existe pas sur internet, pas besoin de fantasmer des services secrets.
Notre produit est backé par plusieurs audits réalisés par des indépendants reconnus du secteur.
Les sceptiques sont libre d’auditer le code du client à leur tour.
Les allégations de Nadim sont diffamatoires. Certaines contredisent les specs.
Aucune jusque là n’a été développée concrètement. Ce n’est pas le genre de rigueur que l’on pourrait attendre d’un docteur.
A nouveau, le code client est sur GitHub, en GPLv3.
Toute personne à même de démontrer que nos équipes et auditeurs ont effectivement raté quelque chose peut prétendre à une bounty.
Peerio est sujet au droit Canadien. A ce titre, nous ne sommes pas tenu de donner suite aux NSL.
Par ailleur, faut-il le rappeler, nous ne disposons d’aucun visuel sur les données que vous choisissez de nous confier.
Mais n’allez pas croire tout ce qu’on raconte : une lecture du code du client vous confirmera la chose.
Ne pouvant plus poster sur ce sujet, en réponse au poste de raj
Mais cela m’a l’air probablement faux cette partie, bien dans l’air du temps mais faux.
Un peut comme si je disais que l’employé appartenais à l’entreprise le temps de sa location.
Tout dépend de ton contrat, je t’invite à te renseigner sur le sujet.
Bien souvent, tout ce que tu produis lors de ton exercice dans l’entreprise en est sa propriété.
A ton départ, les RH peuvent te fait signer un document comme celui-ci : http://www.biztree.com/fr/doc/reconnaissance-des-droits-de-propriete-de-l-entreprise-D1906
A titre de rappel.
Probablement ce à quoi fait référence Nadim, lorsqu’il insinue qu’on veut s’approprier miniLock. Le fait est qu’il l’a implémenté durant son exercice.
Pourquoi conclure de cette manière ? La vie privée existe, tout dépend du support et de la conservation. Des données personnelles qui sont stockées pour un temps indéfini sont plus vulnérables que ceux temporairement échanger entre deux personnes. Le support rentre également en ligne de compte - si tu développes ta propre application de chiffremment pour un usage restreint avec quelqu’un et que tu ne la partages pas, tu as un risque quasi-nul - voir inexistant. Do It Yourself 
Si par contre tu ne sais pas développer d’application, tu fais confiance à un produit, comme tu fais confiance à ta banque … rien n’est absolument sûr, mais je ne pense pas que Peerio s’amuserait à ça vu les circonstances (et vu les réponses de syn).
Mais cela m’a l’air probablement faux cette partie, bien dans l’air du temps mais faux.
Un peut comme si je disais que l’employé appartenais à l’entreprise le temps de sa location.
Mais bon c’est du code du travail la, pas de l’applicatif hein filou parcqu’il sais causé au geek le monsieur .
Quelle bonheur de chômer quand je lit se genre de règlement de compte