Proposition de solution user-friendly au problème de sécurité des instances cesium web


#11

Sauf pour le changement d’uid, je suis pour les changements technique que tu propose. ça me semble aussi être le plus urgent pour augmenter la sécurité du système autour de la Ǧ1. (et ça me semble être un pas dans une direction similaire à la proposition de cgeek vu que concrètement, cela distingue 2 type de compte (forgeron ou non) et 2 types de certifications (entre forgerons ou non), mais avec une approche plus sécuritaire (puisqu’un compte ne peux pas devenir forgeron en cours de route, soit il est créé pour l’être soit non). ça n’adresse en revanche pas la problématique d’extension de la communauté plus aisée, mais les changement coté code à faire sont moindre.

J’ai tout bien compris ?


#12

Cela empêcherait de pouvoir faire tourner un Duniter membre sur une machine à laquelle on n’a pas accès physiquement… Alors que j’espère pouvoir le faire un jour avec un conteneur qui garde secret les credentials.

Je plussoie ! Il y a les membres forgerons, les membres villageois (et les membres loup-garous qui sont de fausses identités…) :wink:

Sinon la proposition @elois me semble bonne.


#13

Franchement j’adorerais qu’on utilise ces termes ! Ludiques et clairs !

La proposition d’@elois me semble très intéressante en tout cas. Le seul truc embêtant c’est la perte de quelques DU lorsqu’on veut passer de villageois à forgeron… Mais ça impact peu de personnes, donc ça me semble acceptable (et si c’est bien fait, on peut même éviter ça)

Autre point d’attention : en général, les membres forgerons sont des noeuds importants de la toile actuelle. Il faut faire gaffe, car lorsqu’ils révoqueront leurs comptes, on a beaucoup de liens qui vont disparaitre avec eux (et qui mettront plusieurs mois pour revenir).


#14

Je sais que ce n’est peut-être pas très propre, mais ce serait pour la bonne cause :
Ne pourrait-on pas écrire à la main la liste des membres “forgerons de départ” ?
C’est encore possible vu la taille de la toile, en prenant bien la peine de communiquer en amont auprès de tous ceux qui ont déjà calculé au moins 1 bloc.
Processus transparent, on accepte tous ceux qui demandent (et on voit, encore une fois “à la main”, s’il y a 200 nouveaux forgerons dont personne n’a entendu parler sur le forum qui s’inscrivent). Si la démarche est clairement expliquée ici ça ne devrait pas être trop critiquable si ?

Pour le problème des comptes potentiellement compromis, il faut se demander quel % de comptes ça représente, car le nombre de comptes :

  1. Qui demandent à pouvoir calculer,
  2. Qui se sont déjà connectés à CesiumWeb,
  3. Sur une instance qui soit au choix :
    a) déjà compromise
    b) tenue par quelqu’un qui refusera une MaJ qui “nettoiera” les connexions de la liste.

me semble faible (mais je me trompe peut-être).


#15

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

  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
  2. Effacer toute traces de lien avec DNS dans les docs te sites parlant d’instances de CesiumWeb

Changements pour l’utilisateur

  • Mettre à jour son-ses favori-s

#16

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


#17

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.


#18

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


#19

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 !!


#20

La solution de @cgeek n’est pas réalisable pour éviter que tous le monde puissent calculer des blocs ? :thinking:


#21

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é :slight_smile:

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

Oui c’est une bonne idée :slight_smile:

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.


#22

@vincentux relis bien ce que j’ai écrit :

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.


#23

ok :blush:


#24

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


#25

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.


#26

Oui évidemment :slight_smile:


#27

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


#28

Merci @1000i100 pour cette proposition !

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

https://linuxfr.org/users/gouttegd/journaux/de-la-confiance-dans-le-monde-openpgp#principe

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… :wink:


#29

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.

Voila pour ma proposition “not-user-friendly” .


#30

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.