Oula effectivement, ma mémoire a quelque peu exagérer sur les dates… :)
Effectivement 2008 pour la version stable et septembre 2011 pour l'abandon du troc d'espace disque (et donc de la décentralisation). (petit historique sur Wikipedia-EN
Wuala avait un potentiel énorme pour faire évoluer le web vers une large décentralisation. D'autres qu'eux auraient pu le faire si les sources avaient été disponibles…
La déduplication est effectivement un point critique. Celle des données de l'utilisateur peut être facilement implémentée et sans risque. Par contre la déduplication globale comporte les risques que cite l'article de Wikipédia : on peut déterminer qu'un fichier est déjà sur le réseau (et connaître son identifiant et donc potentiellement savoir qui l'a dans ses fichiers) et cela fragilise beaucoup le chiffrement d'un fichier dont le contenu serait connu sauf une partie.
Nous travaillons sur une solution qui résoudrait ces problèmes et permettrait la déduplication globale.
Tout d'abord une petite question sur quelque chose que je ne m'explique pas : pourquoi une telle agressivité ?
On se connait ? J'ai été agressif envers vous ?
qui viendra du serveur.
A partir de la, c'est mort.
Sauf à avoir l'idée de génie, mais comme vous êtes en phase de réflexion… Vous voulez qu'on vous payer pour réfléchir, mais pourquoi vous et pas d'autres?
Pour vous c'est réflexion ou action ? Il n'est pas envisageable de paralléliser ? De mon côté je ne fonctionne pas comme ça. Oui nous commençons la réalisation alors que tout n'est pas figé.
Petite parenthèse sur le récurrent "vous payer pour réfléchir" : tous les logiciels que vous utilisez ont eu une phase de conception, pendant cette phase des gens ont été payé à réfléchir. Et dans le cas d'un logiciel libre cela ne me choquerait pas que le financement couvre la phase de conception vu qu'il n'est pas vendu à la fin (ce qui permettrait de récupérer les fonds qui auront payé la conception). Dans notre cas, on peut dire qu'il reste entre 5 et 10% de conception à finaliser.
un attaquant qui aurait réussi à accéder au serveur
La, on est mort de rire. En fait, vous n'avez rien compris à la problématique de sécurité.
Le problème n'est pas de se protéger d'un attaquant qui aurait réussi à accéder au serveur.
Le probème est de e protéger de l'admin du serveur.
"LA problématique de sécurité" ? Je doute qu'il n'y en ait qu'une seule. Et je me suis attaché à les séparer clairement dans mes précédents messages là où vous les mélanger : il y a la situation de l'admin qui modifierait le code pour obtenir des mots de passe et il y a le hacker qui s'introduirait sur le serveur et ferait de même.
Si, au lieu d'être agressivement "mort de rire" vous vouliez bien répondre à mes arguments un par un, l'on pourrait avoir une discussion constructive. J'ai déjà apporté pas mal d'éléments de réponse sur ce sujet mais vous les avez totalement ignorés.
De notre côté, nous allons travailler à réduire un maximum ce risque. Mais même en attendant, personnellement, je préfère la 2e situation à la 1ère.
Oui, un peu de dorure "on est plus secure" qui dans les faits n'existe pas (vous dites vous-même que vous êtes à l'état de réflexion, ce qui veut dire : rien comme idée de faisabilité), c'est un marketing classique.
Désolé, sur LinuxFr il y a des gens qui s'interessent à la technique…
J'ai l'impression que votre lecture déforme complètement ce que j'ai écrit. Je n'ai pas dit "on est plus secure". J'ai dit : d'un côté il y a un problème, de l'autre il y a un risque de problème ; de mon côté je préfère le risque. Mais chacun est libre de faire son choix. Et si vous préférez Dropbox, cela ne me pose aucun problème. Par contre si vous dites qu'il vaut mieux utiliser Dropbox, là je ne suis pas d'accord.
Il me semble avoir expliqué dans un précédent commentaire que la chiffrement du HTTPS n'apporterait que bien peu de sécurité à des données qui sont déjà chiffrées en AES256.
Vous êtes sérieux?
HTTPS permet aussi à ce qu'on ne voit pas l'URL.
HTTPS évite qu'on injecte un Javascript different (on parlait de sécurité du JS, non?)
HTTPS évite d'accéder à un serveur différent (ce n'est pas suffisament important pour vous, vraiment?)
Vous faites exprès de ne pas citer la phrase qui est juste après ? "Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre."
Mais il s'agit d'un prototype, pas d'un service en production.
Oui, mais vous voulez du fric pour un truc axé sécurité alors que vous ne prennez même pas la peine de mettre HTTPS sur le serveur qui est un des trucs les plus simples à faire.
Ca fait rigolo, du moins pour moi.
Si vous voulez nous condamner seulement sur ce point, libre à vous.
Désolé, je n'ai toujours pas compris ce qui vous différencie des concurrents en pratique.
Et il me semble ne pas être un utilisateur de base (je m'interesse à la sécurité de mes données), alors pour quelqu'un qui est un simple utilisateur…
Pourquoi ne pas poser des questions précises sur les arguments que j'avance comme faisant la différence ?
Ce que je retiens de vos propos (en excluant toute l'agressivité), c'est que pour vous le chiffrement de bout en bout n'apporte rien parce qu'il est possible qu'un administrateur mal intentionné puisse modifier le code et récupérer les données des utilisateurs (en récupérant d'abord les identifiants). Je vous ai répondu :
1. les logiciels qui sont mis à jour automatiquement (donc même sans JS) ont le même problème
2. nous travaillons à améliorer ce point et nous sommes prêt à aller très loin pour arriver à une solution qui soit plus sécurisée que les clients lourds.
Et du coup vous sortez de vos gonds parce que l'on voudrait "être payer à réfléchir", ce qui, comme déjà dit plus haut, n'est pas vraiment le cas.
Après, comme dit, le 4% (qui est un sacré échec) me fait dire que je ne suis pas le seul à voir aucun interêt particulier de ce projet. Soit l'interêt est inexistant, soit il est très mal expliqué (avec option que le créateur du projet ne sait pas de quoi il parle au niveua sécurité, plus on creuse plus on rigole sur les énormités)
De nouveau de l'agressivité en appuyant sur ce "sacré échec" pour la deuxième fois (votre précédent message se terminait de la même manière). Ca vous apporte quelque chose d'essayer de nous rabaisser ?
Oui c'est un échec et il est (comme souvent) très instructif. Et je suis d'accord sur un point : il montre que nous n'avons pas réussi à trouver notre public.
Pourquoi ne pas mettre en avant que ce que vous visez à terme c'est un modèle décentralisé ? C'est quand même la grosse différence avec le reste (et l'une des choses les plus difficiles)
Le précédent texte de la campagne était très orienté moyen/long terme. De par les retours que j'ai eu, j'ai compris qu'il fallait surtout parler de ce que sera Lupo à court terme.
Pourquoi cacher les avantages des autres solutions par rapport à la vôtre ? Je sais bien que vous êtes plus ou moins dans une « démarche marketing » mais rien n'empêche de souligner ce qui n'est pas encore au point et sera pris en compte ? Cela aura le mérite d'avoir une feuille de route assez claire.
Je n'ai pas l'impression de cacher quoi que ce soit. J'ai précisé (dans le texte de campagne et dans le billet ci-dessus) ce que serait ce service et (dans le texte de campagne, dans le billet et dans les commentaires) ce qu'il apporte par rapport à ce qui existe. De mon point de vue les fonctionnalités qui "manqueront" dans la première version sont à la fois nombreuses et bien moins importantes que le chiffrement de bout en bout, le fait que le logiciel soit libre, etc. Exemple : il n'y aura peut-être pas de streaming pour les vidéos dans la première version.
Clairement cette dernière s'adresse à des personnes qui comprennent les enjeux du respect de la vie privée. Et les versions suivantes apporteront ces fonctionnalités qui rendent l'outil plus agréable à utiliser.
Owncould + EncFS mais pas de Dropbox + EncFS ?
Euh, ça n'est pas évident ?
C'est pareil, sauf que Dropbox n'est pas libre.
Si je puis me permettre, les principaux points d'achoppement techniques du partage de fichiers en ligne sont :
1. synchronisation
2. déduplication avant upload
3. chiffrement côté client
4. performances acceptables (bon ok c'est subjectif)
5. décentralisation
Jusqu'ici je ne connais aucun logiciel (libre ou pas) qui possède toutes ces propriétés.
Intéressant. Le Wuala d'il y a un peu moins de 10 ans correspondait assez bien à tout ça (pour la déduplication, je ne suis pas certain ; et en non libre), avant d'être racheté.
Et ce Wuala d'il y a un peu moins de 10 ans, c'est précisément notre objectif à moyen terme.
Est-ce que vous parlez de déduplication globale ou pour l'utilisateur seulement ?
Il y a donc un de vous deux qui se trompe sur ce que veut vraiment dire « cloud ».
Cela ne me surprends pas, même en français on a du mal à s'entendre sur ce terme : voir la définition dans Wikipédia qui renvoie au Cloud computing ce qui ne correspond pas du tout au sens que j'y mettais dans ma phrase (qui est plutôt le sens commun du mot : Dropbox & co).
Dropbox est avec chiffrement (entre moi et eux en HTTPS, puis chez Amazon aussi en AES256), le savez vous? soritr que c'est sans chiffrement fait juste rigoler vôtre interlocuteur, car vous ne dites pas de quel chiffrement plus mieux bien vous imaginez. Désolé je n'ai pas compris comment vôtre solution est plus chiffrée que chez Dropbox : du moment où il y a une interface web et que je rentre mon pass dans du Javascript récupéré sur un serveur, j'ai autant de sécurité qu'avec Dropbox.
Je vais essayer d'être plus clair.
Dropbox chiffre le transfert entre l'utilisateur et ses serveurs web (HTTPS) puis chiffre avant d'envoyer sur les serveurs de stockage (AES). Entre ces deux chiffrement Dropbox a accès à tous les fichiers de ses utilisateurs (et au mot de passe).
Personnellement cela me pose problème et donc je n'utilise pas Dropbox (ni ses concurrents qui procèdent de la même manière).
Ce que nous proposons c'est de chiffrer depuis l'ordinateur de l'utilisateur, et plus précisément, dans la version web, dans son navigateur. Donc oui, le chiffrement sera fait par du javascript qui viendra du serveur. Donc il y a un risque que le fichier javascript soit corrompu par un attaquant qui aurait réussi à accéder au serveur (qui n'est pas un moulin non plus) et à gagner des droits suffisants pour pouvoir modifier le bon fichier javascript. Comme je l'ai précisé dans un précédent message, il y a ce même risque avec les autres clients web (par ex, sauf erreur, SeaFile) et pour les clients lourds qui se mettent à jour automatiquement (rien empêche un attaquant de pousser une mise à jour qui lui permettrait de récupérer tous les identifiants et mot de passe.
Pour résumer nous avons une situation problématique (une entreprise à accès à toutes mes données) et une situation à risque (en cas d'attaque active contre le serveur, un attaquant peut accéder à mes données).
De notre côté, nous allons travailler à réduire un maximum ce risque. Mais même en attendant, personnellement, je préfère la 2e situation à la 1ère.
Et comme on vous l'a déjà fait remarquer, montrer vôtre incapacité à mettre vôtre démo en HTTPS
Pourquoi "incapacité" ?
Il me semble avoir expliqué dans un précédent commentaire que la chiffrement du HTTPS n'apporterait que bien peu de sécurité à des données qui sont déjà chiffrées en AES256.
Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre. Mais il s'agit d'un prototype, pas d'un service en production.
J'ai tenu compte de votre premier message, en ajoutant à la FAQ du précédente texte de campagne le détail des différences entre Lupo Libero et ce qui existe déjà. Voici la version actuelle (qui est dans le nouveau texte de la campagne de financement, bien plus en évidence) :
Différences avec ce qui existe déjà
1. la partie logicielle est open source (et libre) : elle peut être analysée et réutilisée
2. chiffrement de bout en bout : vos données sont protégées avant de quitter votre ordinateur pour aller sur les serveurs ; votre mot de passe n'est jamais envoyé sur internet
3. le chiffrement n'est pas optionnel
4. le chiffrement est totalement transparent : aucun mot de passe additionnel à gérer par l'utilisateur pour chaque partage de fichier ou de collection de fichiers
5. le chiffrement est compatible avec le partage sélectif : tous vos fichiers sont chiffrés et vous pouvez tout de même partager un seul fichier avec une personne sans compromettre la sécurité du reste de vos données
Visiblement ça n'est pas assez parlant.
Voici quelques logiciels concurrents et le numéro des items qui font la différence.
Dropbox : 1, 2, 3, 4, 5
SeaFile : 2 (pour le cloud hébergé par eux), 3 (il faut choisir de chiffrer une bibliothèque), 4 (il faut un mot de passe supplémentaire pour chaque bibliothèque chiffrée), 5 (on ne peut pas partager un seul fichier d'une bibliothèque chiffrée)
Owncloud : 2, 3, 4, 5 (pas de chiffrement)
Owncloud + encFS (ou autre solution de chiffrement côté client) : 4 (mot de passe pour déverrouiller encFS), 5 (on ne peut pas partager un seul fichier)
Tahoe-LAFS est vraiment un système différent : c'est un système de fichiers et non pas un "cloud" (stockage en ligne orienté partage). Ses performances - qui ne sont pas forcément gênantes pour une entreprise qui cherche un système de stockage pour son archivage - ne sont pas acceptables pour un produit grand public. Malgré toutes les différences affichés avec Dropbox et autres, avoir des performances similaires n'est pas optionnel. Et Tahoe-LAFS a clairement été construit avec d'autres priorités.
Personnellement j'aurais bien aimé travaillé sur ce logiciel car j'aime beaucoup le python, mais ses concepteurs en ont fait quelque chose d'extrêmement complexe (pour qu'il puisse s'adapter à toutes les situations, ce qui impacte probablement les performances) et donc de difficile à modifier. Avec Lupo nous partons sur des bases plus simples, plus claires et aussi plus orienté : nous ne souhaitons pas faire quelque chose d'aussi généraliste qu'un système de fichiers.
A noter que Tahoe-LAFS est depuis environ un an assez faiblement maintenu (https://github.com/tahoe-lafs/tahoe-lafs/graphs/contributors).
"pas de réflexion aboutie"
"Ca manque (…) (de maturité)"
"la réflexion en est à "reste à valider""
Ca m'apprendra à vouloir partager mes réflexions en toute transparence…
Pour votre information, Lupo Libero n'est pas encore développé et oui, il reste des choix à faire dans se conception.
"Ca manque d'argument (de maturité) pour dire que ce sera mieux que les autres"
"Autant prendre […] Dropbox"
J'en reste sans voix… Vous avez lu le texte de la campagne (les autres liens) ?
Il vaudrait mieux choisir Dropbox (non libre et sans chiffrement) plutôt qu'une solution libre chiffrant de bout en bout seulement parce que notre prototype n'a pas de mécanisme d'authentification du code ?
Je ne pense pas. Il est même très probable que Mega ait plus de fonctionnalités que n'en comptera Lupo dans sa première version :)
Par contre dans les versions suivantes, cela devrait changer. Deux exemples : ajout de fonctionnalités de réseaux sociaux (profils, messagerie, messagerie instantanée, etc.) et de travail collaboratif.
Et bien sûr il y a les deux différences majeures que vous citez :)
Un client "installé une bonne fois pour toute", ça n'existe pas (ou plus) car il est forcément mis à jour et le plus souvent automatiquement pour les petites mises à jour. Et il est tout à fait faisable de glisser la faille à laquelle vous faites référence (récupération des identifiants des utilisateurs) par ce moyen.
Avec le javascript, la mise en place volontaire de ce type de faille est juste un peu plus facile.
Nous étudions plusieurs pistes pour améliorer cela :
- stocker le code de l'application dans le navigateur et ne le modifier qu'en cas de réception d'une mise à jour dûment signée par la clé du gestionnaire du dépôt ; solution la plus intéressante puisque sans installation et donc utilisée par tout le monde, mais la faisabilité technique reste à valider ;
- proposer une extension de navigateur qui vérifierait que le code est correctement signé avant de l'exécuter, en utilisant le certificat HTTPS ; intéressant aussi parce que ça apporte une plus grande sécurité, mais la proportion de gens qui installeront cette extension risque d'être faible ;
- faire servir l'application par le daemon de synchronisation, ainsi elle n'est plus téléchargée à chaque fois ; comme la solution 1 sauf que ne fonctionne que sur les ordinateurs qui ont installé le daemon de synchronisation.
1.
Mais tout ceci vise surtout à résoudre le problème d'un attaquant qui diffuserait du code à notre place en piratant le serveur.
Se protéger de l'éditeur du logiciel est bien plus complexe… Mais ce type de problématique m'intéresse beaucoup. J'aimerais pousser loin la transparence (technique ici) pour arriver à réduire un maximum ce que j'appelle la "nécessité de confiance à un inconnu" : le fait d'avoir besoin de faire confiance à un inconnu ou groupe d'inconnus (l'éditeur) avant de pouvoir faire quelque chose (ici, accéder au service).
J'ai déjà pas mal réfléchi à tout cela mais votre message a indirectement attiré mon attention sur la confiance en un logiciel libre mais fréquemment mise à jour : s'il faut relire le code tous les jours pour savoir si on peut faire confiance au code ça n'est pas gérable.
Le HTTPS vous semble plus nécessaire pour un site qui fait du chiffrement de bout en bout que pour un site sans chiffrement ? J'avoue ne pas trop comprendre. Toutes les données sont chiffrées dans le navigateur donc ce qui voyage sur le réseau est chiffré (ainsi que ce qui est stocké sur le serveur).
Nous envisageons de permettre le partage avec les utilisateurs non inscrits. Je ne sais pas encore si cette fonctionnalité sera ajouté au prototype car si elle l'est, de part l'implémentation actuelle du système de chiffrement des fichiers, il y aura une grosse faille de sécurité (qui peut être acceptable pour un prototype) : la clé de l'utilisateur sera transmise dans une url. Bien entendu ce problème n'existera pas dans la première version de Lupo. La clé contenue dans l'url sera seulement celle du fichier partagé.
Je ne reviens pas sur les raisons qui nous ont poussé à ne pas utiliser SeaFile ou une autre solution existante car je viens d'y répondre longuement dans un autre commentaire (avant que vous ne postiez le vôtre).
Effectivement il y a une erreur pour "Différences avec les autres services", en réalité il s'agit de "Différences entre le prototype et la première version". Si un modérateur passe par ici, je le/la remercierais grandement de bien vouloir corriger cette petite erreur :) (ou de me signaler comment le faire, si cela est possible).
En ce qui concerne le fait de se baser sur un logiciel existant et de lui ajouter des fonctionnalités, c'est une question qui revient très souvent et je le comprends tout à fait : c'est une des richesses du libre que de pouvoir mutualiser. Mais il y a au moins un cas où cette stratégie n'est pas aussi intéressante qu'il y parait : lorsque l'on veut faire quelque chose de très différent de ce qui existe. Bien sûr la première version de Lupo, même si elle apporte des améliorations au stockage en ligne, pourrait très bien être bâtie en utilisant des briques existantes (SeaFile par exemple) mais pour nous cette première version n'est en réalité qu'une étape dont l'objectif est de créer un socle de stockage/synchronisation de données (quel que soit leur type, fichier ou autre) qui puisse facilement évoluer dans deux directions :
- ajout d'autre types de données (gestion de mots de passes, marques-pages, contacts, messagerie, etc.) ;
- décentralisation
Et c'est surtout ce deuxième point qui nous a fait choisir de ne pas réutiliser SeaFile ou un autre : il n'est absolument pas trivial de décentraliser un logiciel. Pour ne donner qu'un exemple (que je donne également sur le wiki ou dans le prototype) : l'authentification, sur SeaFile ou tout autre service centralisé, consiste à envoyer au serveur un identifiant et un mot de passe et celui-ci vérifie qu'ils correspondent bien à ce qu'il a stocké dans sa base de données. Dans un système décentralisé ce n'est pas possible : chaque noeud est un serveur donc qui peut vérifier et affirmer que je suis bien qui je prétends être ? La solution que nous avons choisi est celle de la cryptographie : le navigateur génère une clé de façon déterministe (et donc répétable) à partir de l'identifiant et du mot de passe. Cette clé servira à chiffrer les éléments importants de l'espace de stockage de l'utilisateur (d'autres clés de chiffrement, l'identifiant du répertoire racine, etc.). Et cette forme d'authentification ne nécessite pas de serveur.
De manière plus générale cette stratégie de préparation à la décentralisation consiste à transférer autant que possible les opérations du serveur vers le client (pour l'instant : le navigateur seulement). Dans notre cas le serveur n'est qu'une base de données, mais pas n'importe laquelle, une qui a de très grandes capacités de synchronisation : CouchDB. Je la cite car c'est là que nous utilisons vraiment de l'existant parce qu'il est tout à fait compatible avec les futures version de Lupo Libero et cela va grandement nous faciliter la synchronisation qui n'est pas une tâche aisée.
Et nous allons également utiliser autant que possible les technologies développées par d'autres logiciels libres, comme par exemple, zfec.
Tout à fait d'accord. Mais dans notre cas, nous souhaitons pousser la transparence plus loin. Comme nous utiliserons CouchDb, qui permet par défaut une très grande transparence, il sera possible de voir une partie du code serveur (en allant voir le "design document" de la base de données, pour ceux qui connaissent un petit peu) en ayant une certaine assurance qu'il s'agit bien du code exécuté. Et nous allons chercher un moyen pour qu'il soit possible de vérifier que le serveur exécute bien le code qu'il prétend exécuter.
Personnellement je tiens beaucoup . Un de mes rêves fous de transparence totale serait de développer un module du noyau Linux pour qui permettrait de donner une très grande visibilité de tout ce qui se passe sur les serveurs, sans mettre en péril la sécurité de ceux-ci. Peut-être que cela peut se faire avec les modules d'audit existant. Mais il reste la question de savoir comment prouver qu'il n'y a pas eu de modifications qui permettraient de cacher des informations.
Si un développeur qui passerait dans le coin s'intéresse à cette question, qu'il n'hésite pas à me contacter (une fois que Lupo sera un succès !) :)
La documentation du protocole est effectivement un élément important pour l'interopérabilité et pour laisser la liberté aux développeur de créer autre chose avec.
Non il ne s'agit pas de tout chiffrer en asymétrique, mais seulement les clés symétriques à échanger entre les utilisateurs. Les fichiers, eux, sont chiffrés avec ces clés symétriques.
Pas de problème, je comprends que ce point là soit particulièrement important pour ceux qui ont des connaissances techniques :)
Oui nous avons plus que commencé à travailler sur ce projet. La conception est quasiment terminé (voir les détails techniques dans un autre commentaire). Le financement, c'est pour passer à la phase de réalisation.
Comme cela semble très demandé, nous allons travailler dans les prochains jours au développement d'un prototype, qui montrera le futur fonctionnement de Lupo.
Merci à tous pour vos critiques constructives :)
Sylvain
En fait, les fichiers sont chiffrés avec des clés symétriques générées de manière aléatoire (sans rapport avec le mot de passe de l'utilisateur). Pour partager avec une personne qui a également un compte, il suffira de choisir son nom et techniquement la clé de chiffrement du fichier lui sera envoyé, chiffrée avec sa clé publique. Ainsi, l'utilisateur avec qui on partage aura accès au fichier sans mot de passe additionnel.
Pourquoi ?
Pour essayer de changer les choses.
Il y a une dizaine d'année j'ai découvert Wuala qui permettait de partager une partie de son espace disque avec le réseau et de bénéficier en retour de Go sur ce réseau, disponibles 24h/24 (même quand l'ordinateur est éteint). Le nombre de Go obtenus correspondait au nombre de Go mis à disposition pondéré par le nombre d'heures pendant lesquelles l'ordinateur restait en ligne : si l'on partageait 15Go pendant 8h/j en moyenne, on avait droit à 5Go (8 = 1/3 de 24, donc 15/3 = 5Go).
Je trouvais ça génial car cela permettait de stocker gratuitement des données sur internet (la véritable gratuité, celle qui est non commerciale) et je rêvais de quelque chose de similaire, en logiciel libre, ce qui aurait permis d'ajouter de nouveaux usage sur ce réseau porté par ses utilisateurs : pourquoi pas héberger de véritables sites internet (ou au minimum leurs données) et en finir avec les coûts d'hébergement qui freinent l'émergence de services non commerciaux.
Il n'y a pas eu d'évolution de ce type et même quelques années plus tard Wuala, qui avait été racheté par un fabricant de disques durs entre temps, a recentralisé toute son infrastructure et s'est mis à faire du cloud comme les autres.
Depuis des années sont passées, aucun Wuala libre n'a émergé. Des entreprises sont devenues immensément riches en utilisant la vie privée de millions de gens aveuglés par la gratuité. Et on découvre chaque jour un peu plus à quel point l'ensemble du net est sous surveillance permanente des agences de renseignements.
Je pense que l'on peut faire beaucoup mieux. La technique le permet. Il faut juste s'y atteler et oui, il y aura sûrement des "emmerdes" sur la route :) mais je pense que ça vaut vraiment le coup d'essayer.
Je ne me fais pas de soucis pour ceux qui maîtrisent bien l'outil informatique, ils sauront toujours s'en sortir en bidouillant (même si j'en connais beaucoup qui en ont marre de batailler et qui aimeraient une solution simple). C'est plutôt à M. et Mme Toutlemonde que je m'intéresse : ils se font tondre la laine sur le dos par des multinationales qui pillent leur vie privée et ils n'ont pas les connaissances pour s'en rendre compte et encore moins pour y changer quelque chose.
Donc je veux faire de la pédagogie et proposer une réelle alternative.
Je comprends tout à fait que de nombreuses personnes souhaitent des détails techniques. La seule raison pour laquelle je n'en ai pas donné plus jusqu'à présent c'est que j'appréhende l'avalanche de questions du type "pourquoi cette technologie et pas celle-là" ou "pourquoi pas ce langage de programmation", etc. et je ne souhaite pas rentrer dans ce type de polémique sans fin.
D'un point de vue général, et parce que c'est un objectif à moyen terme du projet, Lupo Libero sera développé de manière à être facilement décentralisable (plus d'informations à ce sujet dans le texte de la campagne de financement). Donc une des contraintes est de minimiser les traitements réalisés côté serveur. Nous souhaitons que le service soit accessible sans installer de logiciel donc il sera développé en HTML5 et javascript (avec un framework, probablement AngularJS).
Il y aura également un client lourd (optionnel) pour la synchronisation, qui n'aura pas d'interface graphique : un simple daemon, qui sera administré par l'interface web (sans passer par les serveurs). Le client lourd sera essentiellement une base de données CouchDB contenant les fichiers chiffrés de l'utilisateur et un script assurant le lien avec le système de fichier, le chiffrement/déchiffrement, l'augmentation du volume des données (voir zfec, ci-dessous) et leur découpage avant d'être stockées dans la base de données (et donc sur les serveurs, par synchronisation).
Côté serveur, il y aura un cluster de serveurs de bases de données CouchDB (et des proxies) qui aura essentiellement trois missions : stocker les données chiffrées (côté client), servir l'interface web et gérer les quotas. A peu près tout le reste sera géré côté client.
Ce qui fait défaut à la plupart de nos concurrents qui proposent du chiffrement côté client (généralement de manière optionnelle) c'est la granularité du partage : avoir tous ses fichiers chiffrés mais garder la possibilité d'en partager des sous-ensembles (un ou plusieurs fichiers ou répertoires) avec une ou plusieurs personnes sans dévoiler les autres fichiers et sans mots de passe additionnels. Elle n'est pas forcément évidente à comprendre mais il y a une réelle complexité à gérer cela : il ne faut pas chiffrer tous les fichiers avec les mêmes clés et il faut procéder à l'échange de clés de manière automatisée (par du chiffrement asymétrique) et avec les bonnes personnes.
Pour ce faire, nous nous appuieront sur le travail de chercheurs qui sont à l'origine de Wuala (à ma connaissance, le seul de nos concurrents à offrir le même niveau de sécurité, mais qui a malheureusement fait le choix du logiciel propriétaire, ce qui nous empêche de vérifier ce qu'ils font véritablement avec nos données) : CrypTree. En quelques mots, il s'agit de construire un arbre de clés hiérarchisé, qui suit la structure de l'arborescence des fichiers et qui permet, entre autres, qu'un partage d'un répertoire donne également l'accès implicitement à son contenu et au chemin pour accéder à ce répertoire. Pour ceux qui voudrait en savoir plus, le document est librement téléchargeable (des connaissances en cryptologies sont nécessaires pour comprendre ce document) : http://dcg.ethz.ch/publications/srds06.pdf.
Autre point clé, la réplication (partielle) des données. Nous utiliserons la bibliothèque de code correcteurs zfec, développée par Tahoe-lafs. Elle nous permettra, après découpage de chaque données en un certain nombre de bloc, d'augmenter le volume de chaque donnée avec des informations redondantes (un peu comme avec du RAID5) et donc d'augmenter le nombre de blocs pour chaque donnée, de manière a pouvoir résister à la perte de k blocs parmi m.
Tout à fait. C'est un des rares logiciels à proposer exactement ce que l'on veut faire dans la première version de Lupo Libero.
Seul problème : Wuala est un logiciel propriétaire.
Je vois que vous allez lu beaucoup de choses très intéressantes à notre sujet (notamment l'adresse du siège social), mais vous semblez être passé à côté de cette mise à jour sur le site de la campagne (mise en évidence au début de la version de chaque langue) : https://www.indiegogo.com/projects/lupo-libero-an-open-source-online-storage-protecting-your-privacy/#activity "Comment contribuer de manière totalement anonyme".
J'explique comment contribuer à ce projet sans que même nous ne sachions qui vous êtes.
Par ailleurs Indiegogo propose aux contributeurs de masquer leur nom ou d'afficher un autre nom à la place.
Cette attaque me semble assez peu méritée.
Et à propos d'attaque… pourquoi cette agressivité ?
Que vous pensiez qu'il s'agit peut-être d'une arnaque, je peux le concevoir (il y a toujours ce risque avec des personnes que l'on ne connaît pas). Que vous en soyez sûr au point d'en être agressif, je le comprends déjà nettement moins.
De ce que je comprends, par défaut, les fichiers sont chiffrés sur les serveurs (ça n'est pas précisé donc c'est probablement le cas) et les clés ne sont pas gardées sur les mêmes serveurs que les fichiers. Le gain en terme de sécurité est minime : si un attaquant peut compromettre un serveur il peut très probablement compromettre le serveur voisin ; si une autorité demande à accéder au fichier, elle demandera la clé aussi ; etc.
Il y a une autre possibilité, si l'utilisateur le choisi (un mauvais point à mon avis) :
Les utilisateurs qui souhaitent un niveau de sécurité encore plus important peuvent choisir d’utiliser leur propre clé de chiffrement en sélectionnant l’option « Utiliser une clé personnalisée ». Afin de garantir une sécurité maximale, la clé de chiffrement n'est alors plus stockée par Ubikube et devra être entrée à chaque authentification. Ubikube n'a pas la possibilité de reconstituer les fichiers sans la clé.
Il n'est pas dit explicitement que le chiffrement se fait côté client, donc je pense que la clé "personnalisée" est envoyée au serveur (sans y être stockée) à chaque fois que l'utilisateur veut accéder à un fichier, le serveur déchiffre le contenu et le renvoie à l'utilisateur.
Si c'est confirmé (je vérifierai si je trouve un peu de temps, mais peut-être que quelqu'un me devancera), cela voudrait dire que Ubikube ne fait pas de chiffrement de bout-en-bout (ou "côté client").
D'autre part, j'aimerais bien savoir s'il est toujours possible de partager un seul fichier avec une personne lorsque l'on utilise une "clé personnalisée".
Je garde le problème le plus "grave" (à mon sens) pour la fin : les composantes logicielles d'Ubikube ne semblent pas être sous licence libre. Donc on ne sait pas ce qu'ils font réellement avec les données de leurs utilisateurs ni ce que fait le logiciel client sur le poste de travail. En sécurité plus qu'ailleurs, la licence libre est à mon sens une nécessité.
A mon sens ce problème est le moins important et le plus facile à modifier de la liste. Comme je l'ai écrit en-dessous, le chiffrement généralisé (que l'on pourrait effectivement mettre en place avec SeaFile), n'est pas compatible avec le partage sélectif (un seul fichier avec une seule personne sans dévoiler le reste) et même si il l'était il resterait ce grand nombre de mots de passe à gérer.
Je n'en suis pas convaincu. Et si c'est le cas, je suis très surpris qu'ils ne s'en servent pas comme argument de vente dans leur Pricing Plan (http://seafile.com/en/product/cloud_service/) et je trouve cela assez malhonnête de ne pas informer plus clairement l'utilisateur.
SeaFile propose un service similaire avec des différences qui ne me semblent pas négligeables. On peut installer SeaFile sur son propre serveur ou on peut utiliser SeaCloud, le cloud proposé par la société Seafile et qui utilise le logiciel SeaFile.
Je vais commencer par SeaCloud :
Après avoir testé et analysé (avec un simple Firefox) les requêtes, il apparaît clairement que SeaCloud ne fait pas du chiffrement côté client ce qui va à l'encontre de ce qui est décrit dans la documentation de SeaFile. Je trouve cela extrêmement malhonnête de ne pas prévenir clairement l'utilisateur que le niveau de sécurité de SeaCloud est largement inférieur à celui de SeaFile ou du moins à celui que SeaFile prétend avoir car je n'ai pas testé SeaFile en l'installant sur un serveur.
The server sends back the encrypted data, then the browser decrypts them with JavaScript on the client side;
The browser encrypts the data with JavaScript on the client side then sends encrpted data to the server. The server just store the encrypted result directly.
In both cases, your password won't be transferred to the server side.
Dans l'application, au moment d'accéder à une partie chiffrée, on a le message :
This library is encrypted. Please input the password if you want to browse it online. And the password will be kept on the server for only 1 hour.
Je ne sais pas ce qu'il en est de SeaFile, si on l'installe sur un serveur ou si un autre prestataire le propose, mais SeaCloud n'a pas le niveau de sécurité que nous souhaitons proposer car il ne chiffre pas les données sur l'ordinateur de l'utilisateur.
Venons en à SeaFile. L'outil est bien fait et peut correspondre à certains usages, mais il n'est pas équivalent à ce que nous proposons :
Les fichiers ne sont pas chiffrés par défaut : il faut volontairement créer une "library" (ou "bibliothèque" : une collection de documents et répertoires) chiffrée. Dans le système que je propose tout est chiffré est c'est important car c'est une protection additionnelle pour les données sensibles : elles n'attirent pas plus l'attention que des données sans importance.
Si on chiffre une "bibliothèque", on peut la partager, mais on ne peut pas partager un seul fichier ou répertoire à l'intérieur ce cette "bibliothèque". Donc on ne peut pas compenser le #1 en mettant tous ses fichiers dans une "bibliothèque" chiffrée sans renoncer à la possibilité de partager ses fichiers.
Lorsque l'on partage une "bibliothèque" avec une autre personne utilisatrice de SeaCloud, il faut lui communiquer le mot de passe de celle-ci manuellement. La probabilité que cet échange de mot de passe se fasse par un canal peu ou pas sécurisé me semble malheureusement assez grande.
D'un certain côté cela peut-être vu comme un avantage : il faut plus de mots de passe pour accéder à une donnée partagée. Mais c'est à mon avis une erreur : si 23 personnes partagent avec moi des "bibliothèques" chiffrées, je dois retenir 24 mots de passe (23 + celui d'authentification à mon compte), donc je vais…. les écrire sur un bout de papier ou demander à ces 23 personnes d'arrêter de chiffrer leurs données. La sécurité résiste très mal face à l'expérience utilisateur.
SeaFile peut être tout à fait satisfaisant pour de l'archivage, pour une utilisation sans chiffrement ou pour partager le même contenu chiffré avec toujours les mêmes personnes.
Nous proposons un système dans lequel toutes les données sont chiffrées par défaut et où il facile de partager un seul fichier avec une autre personne, sans dévoiler ses autres données et sans définir de mots de passe additionnels.
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 1.
Bonjour,
Oula effectivement, ma mémoire a quelque peu exagérer sur les dates… :)
Effectivement 2008 pour la version stable et septembre 2011 pour l'abandon du troc d'espace disque (et donc de la décentralisation). (petit historique sur Wikipedia-EN
A défaut de pouvoir tester, si vous voulez des informations sur le fonctionnement et la conception de l'ex-partie P2P de Wuala, j'ai trouvé ce document : http://www.slideshare.net/adunne/wuala-p2p-online-storage.
Wuala avait un potentiel énorme pour faire évoluer le web vers une large décentralisation. D'autres qu'eux auraient pu le faire si les sources avaient été disponibles…
La déduplication est effectivement un point critique. Celle des données de l'utilisateur peut être facilement implémentée et sans risque. Par contre la déduplication globale comporte les risques que cite l'article de Wikipédia : on peut déterminer qu'un fichier est déjà sur le réseau (et connaître son identifiant et donc potentiellement savoir qui l'a dans ses fichiers) et cela fragilise beaucoup le chiffrement d'un fichier dont le contenu serait connu sauf une partie.
Nous travaillons sur une solution qui résoudrait ces problèmes et permettrait la déduplication globale.
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 2.
Tout d'abord une petite question sur quelque chose que je ne m'explique pas : pourquoi une telle agressivité ?
On se connait ? J'ai été agressif envers vous ?
Pour vous c'est réflexion ou action ? Il n'est pas envisageable de paralléliser ? De mon côté je ne fonctionne pas comme ça. Oui nous commençons la réalisation alors que tout n'est pas figé.
Petite parenthèse sur le récurrent "vous payer pour réfléchir" : tous les logiciels que vous utilisez ont eu une phase de conception, pendant cette phase des gens ont été payé à réfléchir. Et dans le cas d'un logiciel libre cela ne me choquerait pas que le financement couvre la phase de conception vu qu'il n'est pas vendu à la fin (ce qui permettrait de récupérer les fonds qui auront payé la conception). Dans notre cas, on peut dire qu'il reste entre 5 et 10% de conception à finaliser.
"LA problématique de sécurité" ? Je doute qu'il n'y en ait qu'une seule. Et je me suis attaché à les séparer clairement dans mes précédents messages là où vous les mélanger : il y a la situation de l'admin qui modifierait le code pour obtenir des mots de passe et il y a le hacker qui s'introduirait sur le serveur et ferait de même.
Si, au lieu d'être agressivement "mort de rire" vous vouliez bien répondre à mes arguments un par un, l'on pourrait avoir une discussion constructive. J'ai déjà apporté pas mal d'éléments de réponse sur ce sujet mais vous les avez totalement ignorés.
J'ai l'impression que votre lecture déforme complètement ce que j'ai écrit. Je n'ai pas dit "on est plus secure". J'ai dit : d'un côté il y a un problème, de l'autre il y a un risque de problème ; de mon côté je préfère le risque. Mais chacun est libre de faire son choix. Et si vous préférez Dropbox, cela ne me pose aucun problème. Par contre si vous dites qu'il vaut mieux utiliser Dropbox, là je ne suis pas d'accord.
Vous faites exprès de ne pas citer la phrase qui est juste après ? "Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre."
Si vous voulez nous condamner seulement sur ce point, libre à vous.
Pourquoi ne pas poser des questions précises sur les arguments que j'avance comme faisant la différence ?
Ce que je retiens de vos propos (en excluant toute l'agressivité), c'est que pour vous le chiffrement de bout en bout n'apporte rien parce qu'il est possible qu'un administrateur mal intentionné puisse modifier le code et récupérer les données des utilisateurs (en récupérant d'abord les identifiants). Je vous ai répondu :
1. les logiciels qui sont mis à jour automatiquement (donc même sans JS) ont le même problème
2. nous travaillons à améliorer ce point et nous sommes prêt à aller très loin pour arriver à une solution qui soit plus sécurisée que les clients lourds.
Et du coup vous sortez de vos gonds parce que l'on voudrait "être payer à réfléchir", ce qui, comme déjà dit plus haut, n'est pas vraiment le cas.
De nouveau de l'agressivité en appuyant sur ce "sacré échec" pour la deuxième fois (votre précédent message se terminait de la même manière). Ca vous apporte quelque chose d'essayer de nous rabaisser ?
Oui c'est un échec et il est (comme souvent) très instructif. Et je suis d'accord sur un point : il montre que nous n'avons pas réussi à trouver notre public.
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 1.
Le précédent texte de la campagne était très orienté moyen/long terme. De par les retours que j'ai eu, j'ai compris qu'il fallait surtout parler de ce que sera Lupo à court terme.
Je n'ai pas l'impression de cacher quoi que ce soit. J'ai précisé (dans le texte de campagne et dans le billet ci-dessus) ce que serait ce service et (dans le texte de campagne, dans le billet et dans les commentaires) ce qu'il apporte par rapport à ce qui existe. De mon point de vue les fonctionnalités qui "manqueront" dans la première version sont à la fois nombreuses et bien moins importantes que le chiffrement de bout en bout, le fait que le logiciel soit libre, etc. Exemple : il n'y aura peut-être pas de streaming pour les vidéos dans la première version.
Clairement cette dernière s'adresse à des personnes qui comprennent les enjeux du respect de la vie privée. Et les versions suivantes apporteront ces fonctionnalités qui rendent l'outil plus agréable à utiliser.
Euh, ça n'est pas évident ?
C'est pareil, sauf que Dropbox n'est pas libre.
Intéressant. Le Wuala d'il y a un peu moins de 10 ans correspondait assez bien à tout ça (pour la déduplication, je ne suis pas certain ; et en non libre), avant d'être racheté.
Et ce Wuala d'il y a un peu moins de 10 ans, c'est précisément notre objectif à moyen terme.
Est-ce que vous parlez de déduplication globale ou pour l'utilisateur seulement ?
Cela ne me surprends pas, même en français on a du mal à s'entendre sur ce terme : voir la définition dans Wikipédia qui renvoie au Cloud computing ce qui ne correspond pas du tout au sens que j'y mettais dans ma phrase (qui est plutôt le sens commun du mot : Dropbox & co).
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 3.
Je vais essayer d'être plus clair.
Dropbox chiffre le transfert entre l'utilisateur et ses serveurs web (HTTPS) puis chiffre avant d'envoyer sur les serveurs de stockage (AES). Entre ces deux chiffrement Dropbox a accès à tous les fichiers de ses utilisateurs (et au mot de passe).
Personnellement cela me pose problème et donc je n'utilise pas Dropbox (ni ses concurrents qui procèdent de la même manière).
Ce que nous proposons c'est de chiffrer depuis l'ordinateur de l'utilisateur, et plus précisément, dans la version web, dans son navigateur. Donc oui, le chiffrement sera fait par du javascript qui viendra du serveur. Donc il y a un risque que le fichier javascript soit corrompu par un attaquant qui aurait réussi à accéder au serveur (qui n'est pas un moulin non plus) et à gagner des droits suffisants pour pouvoir modifier le bon fichier javascript. Comme je l'ai précisé dans un précédent message, il y a ce même risque avec les autres clients web (par ex, sauf erreur, SeaFile) et pour les clients lourds qui se mettent à jour automatiquement (rien empêche un attaquant de pousser une mise à jour qui lui permettrait de récupérer tous les identifiants et mot de passe.
Pour résumer nous avons une situation problématique (une entreprise à accès à toutes mes données) et une situation à risque (en cas d'attaque active contre le serveur, un attaquant peut accéder à mes données).
De notre côté, nous allons travailler à réduire un maximum ce risque. Mais même en attendant, personnellement, je préfère la 2e situation à la 1ère.
Pourquoi "incapacité" ?
Il me semble avoir expliqué dans un précédent commentaire que la chiffrement du HTTPS n'apporterait que bien peu de sécurité à des données qui sont déjà chiffrées en AES256.
Le HTTPS a un intérêt cette situation mais plutôt au niveau de l'authentification du serveur : pour éviter qu'un autre serveur se fasse passer pour le nôtre. Mais il s'agit d'un prototype, pas d'un service en production.
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 4.
J'ai tenu compte de votre premier message, en ajoutant à la FAQ du précédente texte de campagne le détail des différences entre Lupo Libero et ce qui existe déjà. Voici la version actuelle (qui est dans le nouveau texte de la campagne de financement, bien plus en évidence) :
Visiblement ça n'est pas assez parlant.
Voici quelques logiciels concurrents et le numéro des items qui font la différence.
Dropbox : 1, 2, 3, 4, 5
SeaFile : 2 (pour le cloud hébergé par eux), 3 (il faut choisir de chiffrer une bibliothèque), 4 (il faut un mot de passe supplémentaire pour chaque bibliothèque chiffrée), 5 (on ne peut pas partager un seul fichier d'une bibliothèque chiffrée)
Owncloud : 2, 3, 4, 5 (pas de chiffrement)
Owncloud + encFS (ou autre solution de chiffrement côté client) : 4 (mot de passe pour déverrouiller encFS), 5 (on ne peut pas partager un seul fichier)
Tahoe-LAFS est vraiment un système différent : c'est un système de fichiers et non pas un "cloud" (stockage en ligne orienté partage). Ses performances - qui ne sont pas forcément gênantes pour une entreprise qui cherche un système de stockage pour son archivage - ne sont pas acceptables pour un produit grand public. Malgré toutes les différences affichés avec Dropbox et autres, avoir des performances similaires n'est pas optionnel. Et Tahoe-LAFS a clairement été construit avec d'autres priorités.
Personnellement j'aurais bien aimé travaillé sur ce logiciel car j'aime beaucoup le python, mais ses concepteurs en ont fait quelque chose d'extrêmement complexe (pour qu'il puisse s'adapter à toutes les situations, ce qui impacte probablement les performances) et donc de difficile à modifier. Avec Lupo nous partons sur des bases plus simples, plus claires et aussi plus orienté : nous ne souhaitons pas faire quelque chose d'aussi généraliste qu'un système de fichiers.
A noter que Tahoe-LAFS est depuis environ un an assez faiblement maintenu (https://github.com/tahoe-lafs/tahoe-lafs/graphs/contributors).
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 0.
"pas de réflexion aboutie"
"Ca manque (…) (de maturité)"
"la réflexion en est à "reste à valider""
Ca m'apprendra à vouloir partager mes réflexions en toute transparence…
Pour votre information, Lupo Libero n'est pas encore développé et oui, il reste des choix à faire dans se conception.
"Ca manque d'argument (de maturité) pour dire que ce sera mieux que les autres"
"Autant prendre […] Dropbox"
J'en reste sans voix… Vous avez lu le texte de la campagne (les autres liens) ?
Il vaudrait mieux choisir Dropbox (non libre et sans chiffrement) plutôt qu'une solution libre chiffrant de bout en bout seulement parce que notre prototype n'a pas de mécanisme d'authentification du code ?
[^] # Re: différences avec mega ?
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 3.
Je ne pense pas. Il est même très probable que Mega ait plus de fonctionnalités que n'en comptera Lupo dans sa première version :)
Par contre dans les versions suivantes, cela devrait changer. Deux exemples : ajout de fonctionnalités de réseaux sociaux (profils, messagerie, messagerie instantanée, etc.) et de travail collaboratif.
Et bien sûr il y a les deux différences majeures que vous citez :)
[^] # Re: Quelques remarques
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 2.
Les identifiants ne sont pas envoyés au serveur donc cela n'apporte rien à cette authentification qui est de type cryptographique (voir le wiki)
[^] # Re: Hmm
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 1.
Bonjour,
Un client "installé une bonne fois pour toute", ça n'existe pas (ou plus) car il est forcément mis à jour et le plus souvent automatiquement pour les petites mises à jour. Et il est tout à fait faisable de glisser la faille à laquelle vous faites référence (récupération des identifiants des utilisateurs) par ce moyen.
Avec le javascript, la mise en place volontaire de ce type de faille est juste un peu plus facile.
Nous étudions plusieurs pistes pour améliorer cela :
- stocker le code de l'application dans le navigateur et ne le modifier qu'en cas de réception d'une mise à jour dûment signée par la clé du gestionnaire du dépôt ; solution la plus intéressante puisque sans installation et donc utilisée par tout le monde, mais la faisabilité technique reste à valider ;
- proposer une extension de navigateur qui vérifierait que le code est correctement signé avant de l'exécuter, en utilisant le certificat HTTPS ; intéressant aussi parce que ça apporte une plus grande sécurité, mais la proportion de gens qui installeront cette extension risque d'être faible ;
- faire servir l'application par le daemon de synchronisation, ainsi elle n'est plus téléchargée à chaque fois ; comme la solution 1 sauf que ne fonctionne que sur les ordinateurs qui ont installé le daemon de synchronisation.
1.
Mais tout ceci vise surtout à résoudre le problème d'un attaquant qui diffuserait du code à notre place en piratant le serveur.
Se protéger de l'éditeur du logiciel est bien plus complexe… Mais ce type de problématique m'intéresse beaucoup. J'aimerais pousser loin la transparence (technique ici) pour arriver à réduire un maximum ce que j'appelle la "nécessité de confiance à un inconnu" : le fait d'avoir besoin de faire confiance à un inconnu ou groupe d'inconnus (l'éditeur) avant de pouvoir faire quelque chose (ici, accéder au service).
J'ai déjà pas mal réfléchi à tout cela mais votre message a indirectement attiré mon attention sur la confiance en un logiciel libre mais fréquemment mise à jour : s'il faut relire le code tous les jours pour savoir si on peut faire confiance au code ça n'est pas gérable.
[^] # Re: Quelques remarques
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 5.
Le HTTPS vous semble plus nécessaire pour un site qui fait du chiffrement de bout en bout que pour un site sans chiffrement ? J'avoue ne pas trop comprendre. Toutes les données sont chiffrées dans le navigateur donc ce qui voyage sur le réseau est chiffré (ainsi que ce qui est stocké sur le serveur).
Nous envisageons de permettre le partage avec les utilisateurs non inscrits. Je ne sais pas encore si cette fonctionnalité sera ajouté au prototype car si elle l'est, de part l'implémentation actuelle du système de chiffrement des fichiers, il y aura une grosse faille de sécurité (qui peut être acceptable pour un prototype) : la clé de l'utilisateur sera transmise dans une url. Bien entendu ce problème n'existera pas dans la première version de Lupo. La clé contenue dans l'url sera seulement celle du fichier partagé.
Je ne reviens pas sur les raisons qui nous ont poussé à ne pas utiliser SeaFile ou une autre solution existante car je viens d'y répondre longuement dans un autre commentaire (avant que vous ne postiez le vôtre).
Merci pour les encouragements :)
[^] # Re: Test
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 1.
Bonjour,
La barre de chargement est dans les bacs :)
Il est également prévu d'améliorer l'intégration d'un maximum de types de fichiers (vidéos, pdf, textes, etc.).
Mais je ne vous promets pas que tout ceci soit ajouté tout de suite :)
Merci pour les encouragements !
[^] # Re: Je n'ai pas très bien compris
Posté par lupolibero . En réponse à la dépêche Un prototype de Lupo Libero. Évalué à 4.
Bonjour,
Effectivement il y a une erreur pour "Différences avec les autres services", en réalité il s'agit de "Différences entre le prototype et la première version". Si un modérateur passe par ici, je le/la remercierais grandement de bien vouloir corriger cette petite erreur :) (ou de me signaler comment le faire, si cela est possible).
En ce qui concerne le fait de se baser sur un logiciel existant et de lui ajouter des fonctionnalités, c'est une question qui revient très souvent et je le comprends tout à fait : c'est une des richesses du libre que de pouvoir mutualiser. Mais il y a au moins un cas où cette stratégie n'est pas aussi intéressante qu'il y parait : lorsque l'on veut faire quelque chose de très différent de ce qui existe. Bien sûr la première version de Lupo, même si elle apporte des améliorations au stockage en ligne, pourrait très bien être bâtie en utilisant des briques existantes (SeaFile par exemple) mais pour nous cette première version n'est en réalité qu'une étape dont l'objectif est de créer un socle de stockage/synchronisation de données (quel que soit leur type, fichier ou autre) qui puisse facilement évoluer dans deux directions :
- ajout d'autre types de données (gestion de mots de passes, marques-pages, contacts, messagerie, etc.) ;
- décentralisation
Et c'est surtout ce deuxième point qui nous a fait choisir de ne pas réutiliser SeaFile ou un autre : il n'est absolument pas trivial de décentraliser un logiciel. Pour ne donner qu'un exemple (que je donne également sur le wiki ou dans le prototype) : l'authentification, sur SeaFile ou tout autre service centralisé, consiste à envoyer au serveur un identifiant et un mot de passe et celui-ci vérifie qu'ils correspondent bien à ce qu'il a stocké dans sa base de données. Dans un système décentralisé ce n'est pas possible : chaque noeud est un serveur donc qui peut vérifier et affirmer que je suis bien qui je prétends être ? La solution que nous avons choisi est celle de la cryptographie : le navigateur génère une clé de façon déterministe (et donc répétable) à partir de l'identifiant et du mot de passe. Cette clé servira à chiffrer les éléments importants de l'espace de stockage de l'utilisateur (d'autres clés de chiffrement, l'identifiant du répertoire racine, etc.). Et cette forme d'authentification ne nécessite pas de serveur.
De manière plus générale cette stratégie de préparation à la décentralisation consiste à transférer autant que possible les opérations du serveur vers le client (pour l'instant : le navigateur seulement). Dans notre cas le serveur n'est qu'une base de données, mais pas n'importe laquelle, une qui a de très grandes capacités de synchronisation : CouchDB. Je la cite car c'est là que nous utilisons vraiment de l'existant parce qu'il est tout à fait compatible avec les futures version de Lupo Libero et cela va grandement nous faciliter la synchronisation qui n'est pas une tâche aisée.
Et nous allons également utiliser autant que possible les technologies développées par d'autres logiciels libres, comme par exemple, zfec.
J'espère avoir bien répondu à votre question :)
[^] # Re: Différence avec Ubikube ?
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 1.
Tout à fait d'accord. Mais dans notre cas, nous souhaitons pousser la transparence plus loin. Comme nous utiliserons CouchDb, qui permet par défaut une très grande transparence, il sera possible de voir une partie du code serveur (en allant voir le "design document" de la base de données, pour ceux qui connaissent un petit peu) en ayant une certaine assurance qu'il s'agit bien du code exécuté. Et nous allons chercher un moyen pour qu'il soit possible de vérifier que le serveur exécute bien le code qu'il prétend exécuter.
Personnellement je tiens beaucoup . Un de mes rêves fous de transparence totale serait de développer un module du noyau Linux pour qui permettrait de donner une très grande visibilité de tout ce qui se passe sur les serveurs, sans mettre en péril la sécurité de ceux-ci. Peut-être que cela peut se faire avec les modules d'audit existant. Mais il reste la question de savoir comment prouver qu'il n'y a pas eu de modifications qui permettraient de cacher des informations.
Si un développeur qui passerait dans le coin s'intéresse à cette question, qu'il n'hésite pas à me contacter (une fois que Lupo sera un succès !) :)
La documentation du protocole est effectivement un élément important pour l'interopérabilité et pour laisser la liberté aux développeur de créer autre chose avec.
Sylvain
[^] # Re: et Seafile
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 3.
Non il ne s'agit pas de tout chiffrer en asymétrique, mais seulement les clés symétriques à échanger entre les utilisateurs. Les fichiers, eux, sont chiffrés avec ces clés symétriques.
Sylvain
[^] # Re: Arnack?
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 1.
Pas de problème, je comprends que ce point là soit particulièrement important pour ceux qui ont des connaissances techniques :)
Oui nous avons plus que commencé à travailler sur ce projet. La conception est quasiment terminé (voir les détails techniques dans un autre commentaire). Le financement, c'est pour passer à la phase de réalisation.
Comme cela semble très demandé, nous allons travailler dans les prochains jours au développement d'un prototype, qui montrera le futur fonctionnement de Lupo.
Merci à tous pour vos critiques constructives :)
Sylvain
[^] # Re: et Seafile
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 4.
En fait, les fichiers sont chiffrés avec des clés symétriques générées de manière aléatoire (sans rapport avec le mot de passe de l'utilisateur). Pour partager avec une personne qui a également un compte, il suffira de choisir son nom et techniquement la clé de chiffrement du fichier lui sera envoyé, chiffrée avec sa clé publique. Ainsi, l'utilisateur avec qui on partage aura accès au fichier sans mot de passe additionnel.
Sylvain
[^] # Re: Arnack?
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 4.
Merci pour les encouragements :)
Pourquoi ?
Pour essayer de changer les choses.
Il y a une dizaine d'année j'ai découvert Wuala qui permettait de partager une partie de son espace disque avec le réseau et de bénéficier en retour de Go sur ce réseau, disponibles 24h/24 (même quand l'ordinateur est éteint). Le nombre de Go obtenus correspondait au nombre de Go mis à disposition pondéré par le nombre d'heures pendant lesquelles l'ordinateur restait en ligne : si l'on partageait 15Go pendant 8h/j en moyenne, on avait droit à 5Go (8 = 1/3 de 24, donc 15/3 = 5Go).
Je trouvais ça génial car cela permettait de stocker gratuitement des données sur internet (la véritable gratuité, celle qui est non commerciale) et je rêvais de quelque chose de similaire, en logiciel libre, ce qui aurait permis d'ajouter de nouveaux usage sur ce réseau porté par ses utilisateurs : pourquoi pas héberger de véritables sites internet (ou au minimum leurs données) et en finir avec les coûts d'hébergement qui freinent l'émergence de services non commerciaux.
Il n'y a pas eu d'évolution de ce type et même quelques années plus tard Wuala, qui avait été racheté par un fabricant de disques durs entre temps, a recentralisé toute son infrastructure et s'est mis à faire du cloud comme les autres.
Depuis des années sont passées, aucun Wuala libre n'a émergé. Des entreprises sont devenues immensément riches en utilisant la vie privée de millions de gens aveuglés par la gratuité. Et on découvre chaque jour un peu plus à quel point l'ensemble du net est sous surveillance permanente des agences de renseignements.
Je pense que l'on peut faire beaucoup mieux. La technique le permet. Il faut juste s'y atteler et oui, il y aura sûrement des "emmerdes" sur la route :) mais je pense que ça vaut vraiment le coup d'essayer.
Sylvain
[^] # Re: Un dropbox de plus....un.....
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 1.
Je ne me fais pas de soucis pour ceux qui maîtrisent bien l'outil informatique, ils sauront toujours s'en sortir en bidouillant (même si j'en connais beaucoup qui en ont marre de batailler et qui aimeraient une solution simple). C'est plutôt à M. et Mme Toutlemonde que je m'intéresse : ils se font tondre la laine sur le dos par des multinationales qui pillent leur vie privée et ils n'ont pas les connaissances pour s'en rendre compte et encore moins pour y changer quelque chose.
Donc je veux faire de la pédagogie et proposer une réelle alternative.
Sylvain
# Détails techniques
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 10.
Je comprends tout à fait que de nombreuses personnes souhaitent des détails techniques. La seule raison pour laquelle je n'en ai pas donné plus jusqu'à présent c'est que j'appréhende l'avalanche de questions du type "pourquoi cette technologie et pas celle-là" ou "pourquoi pas ce langage de programmation", etc. et je ne souhaite pas rentrer dans ce type de polémique sans fin.
D'un point de vue général, et parce que c'est un objectif à moyen terme du projet, Lupo Libero sera développé de manière à être facilement décentralisable (plus d'informations à ce sujet dans le texte de la campagne de financement). Donc une des contraintes est de minimiser les traitements réalisés côté serveur. Nous souhaitons que le service soit accessible sans installer de logiciel donc il sera développé en HTML5 et javascript (avec un framework, probablement AngularJS).
Il y aura également un client lourd (optionnel) pour la synchronisation, qui n'aura pas d'interface graphique : un simple daemon, qui sera administré par l'interface web (sans passer par les serveurs). Le client lourd sera essentiellement une base de données CouchDB contenant les fichiers chiffrés de l'utilisateur et un script assurant le lien avec le système de fichier, le chiffrement/déchiffrement, l'augmentation du volume des données (voir zfec, ci-dessous) et leur découpage avant d'être stockées dans la base de données (et donc sur les serveurs, par synchronisation).
Côté serveur, il y aura un cluster de serveurs de bases de données CouchDB (et des proxies) qui aura essentiellement trois missions : stocker les données chiffrées (côté client), servir l'interface web et gérer les quotas. A peu près tout le reste sera géré côté client.
Ce qui fait défaut à la plupart de nos concurrents qui proposent du chiffrement côté client (généralement de manière optionnelle) c'est la granularité du partage : avoir tous ses fichiers chiffrés mais garder la possibilité d'en partager des sous-ensembles (un ou plusieurs fichiers ou répertoires) avec une ou plusieurs personnes sans dévoiler les autres fichiers et sans mots de passe additionnels. Elle n'est pas forcément évidente à comprendre mais il y a une réelle complexité à gérer cela : il ne faut pas chiffrer tous les fichiers avec les mêmes clés et il faut procéder à l'échange de clés de manière automatisée (par du chiffrement asymétrique) et avec les bonnes personnes.
Pour ce faire, nous nous appuieront sur le travail de chercheurs qui sont à l'origine de Wuala (à ma connaissance, le seul de nos concurrents à offrir le même niveau de sécurité, mais qui a malheureusement fait le choix du logiciel propriétaire, ce qui nous empêche de vérifier ce qu'ils font véritablement avec nos données) : CrypTree. En quelques mots, il s'agit de construire un arbre de clés hiérarchisé, qui suit la structure de l'arborescence des fichiers et qui permet, entre autres, qu'un partage d'un répertoire donne également l'accès implicitement à son contenu et au chemin pour accéder à ce répertoire. Pour ceux qui voudrait en savoir plus, le document est librement téléchargeable (des connaissances en cryptologies sont nécessaires pour comprendre ce document) : http://dcg.ethz.ch/publications/srds06.pdf.
Autre point clé, la réplication (partielle) des données. Nous utiliserons la bibliothèque de code correcteurs zfec, développée par Tahoe-lafs. Elle nous permettra, après découpage de chaque données en un certain nombre de bloc, d'augmenter le volume de chaque donnée avec des informations redondantes (un peu comme avec du RAID5) et donc d'augmenter le nombre de blocs pour chaque donnée, de manière a pouvoir résister à la perte de k blocs parmi m.
Et voici quelques documents plus récents que nous sommes en train d'étudier pour voir si ils pourraient être utilisés pour améliorer l'infrastructure de Lupo :
- http://css.csail.mit.edu/mylar/mylar.pdf
- http://www.ieeeprojects.yavum.com/basepaper/Dotnet/Privacy-Preserving%20Multi-keyword%20Ranked%20Search%20over%20Encrypted%20Cloud%20Data.pdf.
Je vais essayer de trouver du temps pour clarifier et compléter tout cela et l'exposer sur une page du site.
Sylvain
[^] # Re: Différence avec Ubikube ?
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 8.
Tout à fait. C'est un des rares logiciels à proposer exactement ce que l'on veut faire dans la première version de Lupo Libero.
Seul problème : Wuala est un logiciel propriétaire.
[^] # Re: Arnack?
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 4.
Dans un datacenter…
Je vois que vous allez lu beaucoup de choses très intéressantes à notre sujet (notamment l'adresse du siège social), mais vous semblez être passé à côté de cette mise à jour sur le site de la campagne (mise en évidence au début de la version de chaque langue) : https://www.indiegogo.com/projects/lupo-libero-an-open-source-online-storage-protecting-your-privacy/#activity "Comment contribuer de manière totalement anonyme".
J'explique comment contribuer à ce projet sans que même nous ne sachions qui vous êtes.
Par ailleurs Indiegogo propose aux contributeurs de masquer leur nom ou d'afficher un autre nom à la place.
Cette attaque me semble assez peu méritée.
Et à propos d'attaque… pourquoi cette agressivité ?
Que vous pensiez qu'il s'agit peut-être d'une arnaque, je peux le concevoir (il y a toujours ce risque avec des personnes que l'on ne connaît pas). Que vous en soyez sûr au point d'en être agressif, je le comprends déjà nettement moins.
Sylvain
[^] # Re: Différence avec Ubikube ?
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 6.
De ce que je comprends, par défaut, les fichiers sont chiffrés sur les serveurs (ça n'est pas précisé donc c'est probablement le cas) et les clés ne sont pas gardées sur les mêmes serveurs que les fichiers. Le gain en terme de sécurité est minime : si un attaquant peut compromettre un serveur il peut très probablement compromettre le serveur voisin ; si une autorité demande à accéder au fichier, elle demandera la clé aussi ; etc.
Il y a une autre possibilité, si l'utilisateur le choisi (un mauvais point à mon avis) :
Il n'est pas dit explicitement que le chiffrement se fait côté client, donc je pense que la clé "personnalisée" est envoyée au serveur (sans y être stockée) à chaque fois que l'utilisateur veut accéder à un fichier, le serveur déchiffre le contenu et le renvoie à l'utilisateur.
Si c'est confirmé (je vérifierai si je trouve un peu de temps, mais peut-être que quelqu'un me devancera), cela voudrait dire que Ubikube ne fait pas de chiffrement de bout-en-bout (ou "côté client").
D'autre part, j'aimerais bien savoir s'il est toujours possible de partager un seul fichier avec une personne lorsque l'on utilise une "clé personnalisée".
Je garde le problème le plus "grave" (à mon sens) pour la fin : les composantes logicielles d'Ubikube ne semblent pas être sous licence libre. Donc on ne sait pas ce qu'ils font réellement avec les données de leurs utilisateurs ni ce que fait le logiciel client sur le poste de travail. En sécurité plus qu'ailleurs, la licence libre est à mon sens une nécessité.
[^] # Re: et Seafile
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 3.
A mon sens ce problème est le moins important et le plus facile à modifier de la liste. Comme je l'ai écrit en-dessous, le chiffrement généralisé (que l'on pourrait effectivement mettre en place avec SeaFile), n'est pas compatible avec le partage sélectif (un seul fichier avec une seule personne sans dévoiler le reste) et même si il l'était il resterait ce grand nombre de mots de passe à gérer.
[^] # Re: et Seafile
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 6.
Je n'en suis pas convaincu. Et si c'est le cas, je suis très surpris qu'ils ne s'en servent pas comme argument de vente dans leur Pricing Plan (http://seafile.com/en/product/cloud_service/) et je trouve cela assez malhonnête de ne pas informer plus clairement l'utilisateur.
[^] # Re: et Seafile
Posté par lupolibero . En réponse à la dépêche Service de stockage en ligne libre et respectueux de la vie privée en financement participatif. Évalué à 10.
SeaFile propose un service similaire avec des différences qui ne me semblent pas négligeables. On peut installer SeaFile sur son propre serveur ou on peut utiliser SeaCloud, le cloud proposé par la société Seafile et qui utilise le logiciel SeaFile.
Je vais commencer par SeaCloud :
Après avoir testé et analysé (avec un simple Firefox) les requêtes, il apparaît clairement que SeaCloud ne fait pas du chiffrement côté client ce qui va à l'encontre de ce qui est décrit dans la documentation de SeaFile. Je trouve cela extrêmement malhonnête de ne pas prévenir clairement l'utilisateur que le niveau de sécurité de SeaCloud est largement inférieur à celui de SeaFile ou du moins à celui que SeaFile prétend avoir car je n'ai pas testé SeaFile en l'installant sur un serveur.
Extrait du wiki (https://seacloud.cc/group/3/wiki/faq-for-security-features/) :
Dans l'application, au moment d'accéder à une partie chiffrée, on a le message :
Je ne sais pas ce qu'il en est de SeaFile, si on l'installe sur un serveur ou si un autre prestataire le propose, mais SeaCloud n'a pas le niveau de sécurité que nous souhaitons proposer car il ne chiffre pas les données sur l'ordinateur de l'utilisateur.
Venons en à SeaFile. L'outil est bien fait et peut correspondre à certains usages, mais il n'est pas équivalent à ce que nous proposons :
Les fichiers ne sont pas chiffrés par défaut : il faut volontairement créer une "library" (ou "bibliothèque" : une collection de documents et répertoires) chiffrée. Dans le système que je propose tout est chiffré est c'est important car c'est une protection additionnelle pour les données sensibles : elles n'attirent pas plus l'attention que des données sans importance.
Si on chiffre une "bibliothèque", on peut la partager, mais on ne peut pas partager un seul fichier ou répertoire à l'intérieur ce cette "bibliothèque". Donc on ne peut pas compenser le #1 en mettant tous ses fichiers dans une "bibliothèque" chiffrée sans renoncer à la possibilité de partager ses fichiers.
Lorsque l'on partage une "bibliothèque" avec une autre personne utilisatrice de SeaCloud, il faut lui communiquer le mot de passe de celle-ci manuellement. La probabilité que cet échange de mot de passe se fasse par un canal peu ou pas sécurisé me semble malheureusement assez grande.
D'un certain côté cela peut-être vu comme un avantage : il faut plus de mots de passe pour accéder à une donnée partagée. Mais c'est à mon avis une erreur : si 23 personnes partagent avec moi des "bibliothèques" chiffrées, je dois retenir 24 mots de passe (23 + celui d'authentification à mon compte), donc je vais…. les écrire sur un bout de papier ou demander à ces 23 personnes d'arrêter de chiffrer leurs données. La sécurité résiste très mal face à l'expérience utilisateur.
SeaFile peut être tout à fait satisfaisant pour de l'archivage, pour une utilisation sans chiffrement ou pour partager le même contenu chiffré avec toujours les mêmes personnes.
Nous proposons un système dans lequel toutes les données sont chiffrées par défaut et où il facile de partager un seul fichier avec une autre personne, sans dévoiler ses autres données et sans définir de mots de passe additionnels.