Tout ceci me paraît bien compliqué pour un problème de piratage de DNS qui peut être résolu en ne passant pas par un DNS !
Si chaque hébergeur de CesiumWeb communique une adresse IP fixe et non plus un nom de domaine usurpable, le problème est résolu !
Ceci s’accompagne d’une petite explication pour l’utilisateur final des risques liés au DNS et qu’il est 100% en sécurité seulement en passant par un liens commençant par une IP.
Il pourrait être maintenu par la dev team une whiteliste d’IP indiquant qui est l’hébergeur, clé de membre éventuellement (l’ajout/vérification de ces informations est faite en dehors du système par d’autres moyens de confiance), et invite les utilisateurs à “cliquez droit sur le lien et ajouter aux favoris”.
Changements dans la user story de création d’un compte membre
Aucun
Changements dans le protocole DUBP
Aucun
[edit] Changements pour les hébergeurs de CesiumWeb
Corriger le certificat HTTPS pour qu’il soit valide avec l’IP ( ?heu je maitrise pas, est-ce faisable? ou bien le certificat ne vautque pour des noms de domaines? )
Transition en deux étapes pour la Ğ1
Créer une page de liste blanche avec message éducatif avec des liens et/ou QRCode
exemple: g1.duniter.fr << glissez ce lien dans vos favoris
Effacer toute traces de lien avec DNS dans les docs te sites parlant d’instances de CesiumWeb
(post écrit par un utilisateur averti, pas dev ni sysadmin)
Ca n’est pas qu’un problème de DNS. En règle générale, sur les Blockchain, avoir accès à une clef privée permet d’avoir accès à la monnaie sur le compte. En plus, sur la June, une clef privée membre permet de calculer des blocs. Le problème est la centralisation d’un certain nombre de clefs privées potentiellement calculantes sur des serveurs Césium (qui pour le moment n’enregistrent pas ces clefs, à ma connaissance).
Ces serveurs sont des points d’attaque faibles de la monnaie pour mener des attaques 67%.
On peut avoir comme attaques :
par DNS menteur
par prise de contrôle d’un serveur (faille ou erreur humaine)
par corruption d’un admin
et sans doute d’autres.
Donc la question n’est pas simplement du DNS, c’est “comment éviter que des identités calculantes ne soient exposées sur des serveurs”. Par précaution.
Si tu lis TOUS les tutos concernant la gestion de portefeuilles d’autres cryptomonnaies, ils insistent bien : ne communiquez pas vos clefs privées sur internet ni à personne alors même que ces clefs sont bien moins critiques car sans rapport avec la sécurité du réseau de calcul. Et sur la June, on a une situation inverse : des clefs privées critiques pour le calcul, potentiellement exposées sur des serveurs.
La solution d’Eloïs renforce la sécurité bien au dela d’un piratage DNS d’instance cesium-web.
Plus le nombre de membre forgeron est proche du nombre de membre dans la fenêtre de calcul courante, plus il sera difficile pour un attaquant d’avoir suffisement de clef membre forgeron pour effectuer une attaque significative.
Le fait que les clef membre forgeron ne puisse pas se connecter sur un cesium-web est selon moi un bonus accessoire d’un point de vu sécurité par rapport à l’ampleur du problème actuel : De nombreux membres prosélyte son prêt à certifier qui que ce soit qu’ils ont vu 1 ou 2 fois et semble intéressé, donc il est facile pour quelqu’un de nomade de se faire certifier plusieurs compte, comptes pouvant écrire en blockchain, donc il est relativement simple d’effectuer une attaque pouvant prendre la main sur la blockchain aujourd’hui.
Restreindre l’écriture blockchain aux seuls membres forgerons, créé pour cela, et avoir une licence spécifique, renforcée sur les principes de sécurité pour ces membres me semble certes ajouter une contrainte non négligeable pour ces derniers, mais améliorer considérablement la sécurité de l’ensemble, cesium-web ou non.
Heu… pardon ? Qui a dit que c’était pour “résoudre un problème de DNS” ??
Je ne l’ai effectivement pas rappelé dans mon premier post, mais le fait que tout les membres est le droit au calcul est un problème de sécurité a de nombreux égards et tout les dev sont déjà d’accord sur le fait qu’il est nécessaire de restreindre ce droit d’accès au calcul. On n’avais simplement pas de proposition claire et arrêtée sur comment procéder exactement, ou alors des solutions bien trop complexes, la proposition que je fais ici est au contraire la plus simple à implémenter parmi toutes les propositions qui ont été faites jusque la
L’app Cesium n’a pas de logique serveur, tout se passe dans le navigateur de l’hote, en tout cas sur une version non modifiée/piratée…
Ha ça! Effectivement, c’est une réflexion que je me suis déjà faite, et j’ai même penser à le réaliser, et puis manque de temps pour jouer à ce petit jeu…
C’est un réel problème je suis d’accord… Et je dirais même que c’est du ressort de la conception de la TdC, le fait de ne pas avoir de “finesse” dans l’acte de certifier, ni d’outils supplémentaires d’aide à la confiance qu’une licence qu’on suppose respectée…
Alors effectivement il y’a peut être des choses à faire niveau protocol !
Bah c’est que le méchant CesiumWeb reviens souvent sur le tapis comme un risque MAJEUR, alors que je vois des solutions pour ce problème-ci…
Maiiiiis j’entends je lis vos réponses et je comprends le problème plus profond pas de soucis !!
Si @cgeek a envie de le faire dans Duniter je suivrais, mais perso je ne serais pas moteur pour ces 3 propositions, car nous avons bien d’autres priorités concernant l’évolution du protocole. Je préfère donc qu’on se limitent aux changements absolument nécessaires dans un premier temps, et j’estime que tes propositions permettent concernant l’uid ne sont pas une nécessité
Je pense au contraire que la Licence Ğ1 doit expliciter l’ensemble des droits et devoir nécessaires et suffisants qui incombent a tout membre de la Ğ1, en ce sens la présence de la formule de calcul du DU me semble indispensable, c’est la formule officielle a laquelle se référer sans avoir besoin d’aller chercher dans la documentation du site web ou sur le forum
Oui c’est une bonne idée
En fait il y aurait toujours qu’un seul et unique type de certification dans le protocole. Donc c’est énormément plus simple a implémenter et énormément plus simples pour les utilisateurs finaux, qui n’auront rien de plus a savoir s’il ne calculaient pas de blocs.
Les membres forgerons n’auront qu’un seul type de certif, c’est juste qu’il devront faire preuve de plus de vigilance lorsqu’il certifieront d’autres membres forgerons. Les clients pourrait par exemple, ré-afficher la licence forgeron avec une checklist de points a vérifier chaque fois qu’un membre forgeron est sur le point de certifier une identité forgeron.
Je me suis déjà exprimé sur le fait que la proposition de 3 types de liens qu’avait soumis cgeek était beaucoup trop complexe et allait rendre illisible pour l’utilisateur final un concept déjà fort complexe a comprendre.
Cela complexifierai également beaucoup trop le protocole a mon goût, il me semble qu’un bon protocole se doit d’être le plus simple possible pour répondre a un besoin donné, car plus il est simple plus il est maintenable, réimplémentable et optimisable.
Donc si l’on peut répondre a un même besoin avec une solution technique plus simple, j’estime qu’il nous faut opter pour la solution la plus simple, conformément au principe du Rasoir d’Ockham.
Mouais, donc concrètement, ça reviens à dire qu’il y a 2 types de certifications pour l’utilisateur, il n’y a juste pas besoin de modifier le protocole pour le prendre en compte au niveau des document de certification (c’est le sigPowQty qui sert à vérifier qu’il y a bien suffisement de certification de type forgeron à forgeron), mais pour l’utilisateur, c’est une vigilance différente, des vérification supplémentaire… bref, un autre type de certification (mais pas techniquement, humainement seullement).
C’est vrai que si les forgerons, qui sont souvent des gens impliqués, restreignent leurs certifications il faudra aviser.
Ou alors afficher dans les outils (sauf dans Cesium-web) “l’identité que vous souhaitez certifier a/n’a pas droit de forgeage” pour ne pas les limiter dans leurs certifications de villageois.
Je repense à la solution d’@elois pour corriger le souci de sécurité actuel de la centralisation cesium-web.
La solution protège d’une prise de contrôle de l’écriture dans la blockchain, mais pas d’une création massive de faux comptes en cas de piratage réussi de g1.duniter.fr.
L’usage de hardware wallet, solution bien plus lourde à mettre en place, j’en conviens, résout ces deux enjeux de sécurité, et d’autres :
permet d’utiliser son compte membre pour signer des documents arbitraires sur des applications tiers sans exposer ses secrets -> exemple d’usage : vendeur identifié sur gchange ou assimilé.
libère les usagers de la nécessité de retenir un identifiant secret et un mot de passe sur les quels toutes la sécurité repose (trop complexe, ils l’oublient, trop simple, ils sont vulnérable aux attaque brute force un peu évoluée)
n’introduit pas de centralisation de pouvoir dans la capacité à écrire dans la blockchain -> conserve la pleine citoyenneté à chaque membre.
Dans les aspects moins sympa :
implique d’équiper les usager de hardware wallet.
implique de coder le nécessaire pour avoir des hardware wallet compatible avec nos besoins.
implique d’avoir un hardware wallet branché sur chaque noeud membre, à moins d’ajouter un mécanisme de délégation pour cet usage.
Je ne dit pas que c’est la solution à adopter dès demain, vu qu’elle est plus lourde à mettre en place, mais ça me semble une meilleur solution à terme car elle offre :
plus de sécurité pour tous
la conservation d’une gouvernance horizontale / d’une pleine citoyenneté pour tous.
Le principal aspect durablement gênant est le cout UNL non nul pour chaque nouvel entrant, tant que nous n’avons pas de fournisseur de hardware wallet en Ǧ1.
Une solution intermédiaire ou de transition serait de considérer les comptes (membre) actuel comme “compte découverte” avec les possibilité du N1 de la proposition de @cgeek (pas d’écriture blockchain ni de membre référent), et de considérer les comptes créés avec hardware wallet comme “compte (membre) citoyen”. Techniquement cela revient globalement à avoir des compte membre simple et des compte forgeron, mais en pratique, au lieu de diffuser le message à la communauté : votre compte membre fait l’affaire, laisser les choses importante au forgerons, ça ne vous concerne pas, on leur envoi le message : bienvenue, vous avez maintenant un compte découverte qui vous permet de gouter aux avantage d’une monnaie libre. Pour devenir pleinement citoyen, il reste un pas à faire, qui vous sécurise tout en vous donnant des droits supplémentaire, et sécurise toute la communauté.
Quelque soit la solution adoptée et les efforts pour garder une gouvernance “horizontale” par le plus grand nombre, il y aura toujours la fracture de “l’expertise”.
Il y a ceux qui “savent” :
Contribuer au code, faire tourner un nœud, sécuriser ses comptes, installer un client, utiliser un client.
Faire tourner un nœud, sécuriser ses comptes, installer un client, utiliser un client.
Sécuriser ses comptes, installer un client, utiliser un client.
Installer un client, utiliser un client.
Utiliser un client.
On pourra toujours faire ce qu’on veut, on aura toujours cette “fracture numérique” pour parler poliment ou une “hiérarchie par l’expertise” inévitable.
On aura beau essayer de transmettre le savoir, d’éduquer aux bonnes pratiques, (et il faut le faire !) on aura malheureusement toujours des fractures.
J’aime bien le concept de hardware wallet, mais il est plus facile à voler et aussi facile à perdre (vous n’avez jamais perdu une clef usb ?). Et comment le brancher sur un serveur hébergé ?
Il faut que ce soit un choix (je préfère les mots de passes, ou bien je préfère un fichier de clef privée).
@elois a exposé une solution qui acte de fait une fracture dans l’expertise et sépare les responsabilités.
J’y suis assez favorable.
Pour alimenter le débat entre les niveaux de certifications proposés par @cgeek et les comptes forgerons, la communauté PGP a déjà expérimenté les certifications graduelles, puis est revenue en arrière en ajoutant un mode avec moins de niveaux (le mode TOFU - Trust on First Use qui sera le mode par défaut pour rendre PGP plus accessible).
En tout cas c’est pour moi une priorité de sécurité. Pour exagérer un peu, je dirais que pour l’instant, on a un sudo chmod 777 sur tous les comptes membres…
point de vue utilisateur, ca me semble assez simple: on désactive progressivement l’authentification sur les instance cesium web (en retirant l’authent par salt & password sur les version publique )
On peut faire le test une semaine sur le g1.duniter et voir les retours obtenu. dans le pire des cas on vera d’autre instances fleurir pour combler ce manque pour les utilisateur non geek. dans le meilleur des cas une augmentation dans les installation de clients.
En parallèle, on déploies des solution d’installation facile. (plugin firefox? ),
en ce qui me concerne je penses shipper un cesium pré-configuré en local dans juniter tant que je n’aurais pas codé ces fonctionnalité dans le client lourd. Y a-t’il des install duniter incluant cesium ?
j’envisage différent mode de sync :
light : sync mes données & celles de mes potes & état actuel du reseau
keep up : stay synced, maintain indexing and forks, listen to network
compute blocks
de sorte qu’on puisse l’utiliser en client ou server, avec / sans GUI
Ya un avantage stratégique a shipper un paquet Duniter+Cesium: l’utilisateur ne fait pas la différence entre le back et le front, c’est génial!! chaque fois qu’on repousse l’authent en ligne, on stimule en même temps l’installation d’un noeud.
les cesiums en ligne existeront évidement mais s’il est d’usage de n’utiliser que “celui du copain” occasionnellement c’est déjà moins grave et plus dans l’idée de la WoT. moi je suggère de retirer l’authent depuis g1.duniter.fr. même si les gens utilisent une version “MLOccitanie” ou “le sou” de Cesium, c’est toujours mieux que le serveur “officiel” montre l’exemple. les entrant, les curieux vont arrivé par là. c’est donc sur cette page là qu’il faut initier l’utilisateur aux bonnes pratiques. en parler entre nous et chercher a palier le problèmes techniquement c’est pousser le probleme ailleurs: WoT = facteur humain => éducation.
C’était le cas à une époque, dans Duniter 1.x (mais je ne sais plus quelle version).
Mais Duniter proposera bientôt ses propres écrans de gestion de wallet / identité / certifications / adhésions, avec des utilisations avancées (nouveautés !). Cesium est bien, mais pour une utilisation basique.
Cette proposition traite qu’un des trois droits du statut de membre parmi la création monétaire, l’écriture de la blockchain et la certification.
Elle met de côté l’aspect monétaire (vol des sources de monnaie et de la création monétaire) qui n’est critique que pour l’individu. Ce choix me semble pertinent pour l’instant et moins grave que ce qui suit. Mais, je verrais mal quelqu’un perdre ses sources de monnaie quand la monnaie vaudra beaucoup.
Là où la proposition me pose problème, c’est qu’elle ignore le droit de certification. Dans le cas où cinq comptes membres sont récupérés et contrôlés par un attaquant, ce dernier peut faire ce qu’il veut : créer d’autres comptes (même forgerons), créer de la monnaie, écrire des blocs et attaque Sybil…
J’ai juste lu le post original et le reste en diagonale. Il est possible que j’aie raté des informations.
Si ma proposition est implémentée et que l’attaquant dérobe des clés privés de compte membre uniquement via instances web, alors non il ne pourra pas forger de blocs, car les membres forgerons ne peuvent pas utiliser d’instances web et qu’il n’est pas possible de devenir membre forgeron sans l’accord d’autres membres forgerons.
En revanche, l’attaquant pourra bel et bien voler des G1 a ses victime, ou/et certifier a leur place.
Cependant, les victimes vont rapidement se rendre compte que quelqu’un certifie a leur place et seront invitées a révoquer leur compte afin d’endiguer l’attaque sybil.
De plus, une attaque sybil qui ne peut pas forger, dont le seul risque est donc de créer de la fausse monnaie, devra être d’ampleur très conséquente pour avoir un impact non-négligeable sur la monnaie.
Le vrai risque des attaques sybil aujourd’hui c’est le risque de prise de controle de la blockchain par majorité de forgeron, ce que m’a proposition adresse parfaitement.
Gardons en tête que le sujet des attaques sybil est différent et doit être traité via d’autres propositions (la proposition de membres n1 et N2 de poka par exemple).
Tout ceci suit une logique de réponse proportionnée au risque ( le risque est le produit de la probabilité et de la dangerosité)
Risque de majorité de forgeron => risque très élevé => demande des règles strictes.
Risque de création de fausse monnaie par attaque sybil => risque faible => peut être traité par des règles plus souples.
Merci pour la précision, j’avais pas bien compris la proposition avec cette lecture. Je me suis rappelé de la proposition que j’avais lue lors de sa publication.
La mesure de protection me semble astucieuse. Par contre, j’ai encore un problème avec le fait que les forgerons se cooptent entre-eux. Ils utilisent la toile de confiance actuelle. Ça ne demande pas de toile supplémentaire pour gérer des liens de forgerons.
La question qui se pose est comment faire pour différencier les certifications classiques d’identification et celle de forgerons ? Si un membre souhaite devenir forgeron et qu’il ne connaît pas de forgerons, il va demander une certification classique à un forgeron qu’il ne lui aurait pas donné de certification classique en temps normal ? Ça serait contraire à la licence Ğ1. La question, alors se pose d’avoir deux toiles en parallèle pour différencier tout ça. Mais, là ça fait trop. Tu vois comment cette partie ?
Si un membre souhaite devenir forgeron il sera obligé de révoquer son compte pour créer une nouvelle identité de type forgeron. Si une identité forgeron certifie une autre identité forgeron alors la certification est d’office de type forgeron, sans qu’il y ai besoin de modifier le document certification.
Donc non ce n’est pas une certification “classique” qui sera demandée.
Non pas du tout, je crois que tu n’a pas encore saisie quelques subtilités de ma proposition
