La couche Tor ne suffirait-elle pas ?
1 Like
Elle permet effectivement de masquer son ip, mais il est toujours possible de lancer une attaque DDOS sur le endpoint public en .onion. Et c’est dommage de ne faire que du ws2p privé je trouve 
De plus beaucoup d’"informations restent publiques :
- On sait quand un membre a des nœuds sur le réseau ou pas et combien il en a.
- on sait qui tente de se connecter a soi et donc on peut refuser selon des critères personnels, c’est le même problème qu’avec les unités monétaires non-anonymes an final.
Enfin TOR est quand même lent et n’est pas user-friendly, donc seul ceux qui ont un très bon niveau technique pourront s’anonymiser, ce que je ne trouve pas très juste. Si on se contente de TOR, dans les faits la majorité des nœuds membres seront vulnérables, l’anonymisation sur le réseau me semble indispensable a long terme !
2 Likes
Et puis surtout si tous les nœuds font du privé ça ne marche plus ! C’est bien le WS2P public qui permet le privé.
Après je n’ai pas de solution immédiate à proposer pour protéger son nœud, mais j’ai tout un tas de pistes en tête. Je suis confiant sur ce sujet. Il nous faut continuer à creuser, et notamment identifier notre besoin : est-ce que l’on veut se cacher ? se protéger ? Car la réponse n’est pas forcément la même.
Par contre concernant le besoin d’ @Inso, à savoir requêter directement les nœuds membres, je pense qu’à terme c’est une chose qui va sauter. Interroger les nœuds de membre en direct me semble être un luxe, leur rôle devrait se limiter à dialoguer entre eux pour garantir l’écriture de la blockchain.
Car au final, l’authenticité, c’est dans la blockchain qu’on la constate. Même un nœud miroir devrait pouvoir répondre à nos questions sans qu’on ait le moindre doute quant à la véracité de l’information donnée qui doit pouvoir être recoupée.
4 Likes
Il y a peut être une forme de délégation de clé pour les réponses aux API à mettre en place.
Par contre je suis beaucoup moins confiant que toi sur la possibilité de demander aux clients de vérifier ce qui est dans la chaîne. La distance, la destruction de monnaie, etc, rendent tout ça bien plus difficile. De plus, on a de la chance dans Duniter de pouvoir identifier les noeuds et se protéger facilement et de manière certain des attaques sybilles. Ce serait vraiment dommage de garder les même faiblesses que bitcoin/ethereum là dessus. (Ils souffrent du même risque, si le client télécharge les headers de la chaine sur un réseau majoritairement corrompu, il télécharge une chaine corrompue…)
Mais du coup, je pense à quequechose : les noeuds miroirs peuvent être utilisés pour le obtenir les données, les noeuds membres pour valider. Et c’est une nuance importante ! C’est peut être ça la clé qui peut nous aider à résoudre notre problème. cc @vit
Par exemple, on peut imaginer 2 couches :
- Une couche “obtenir les données” où une requête = une liste de données complètes. On ne peut pas filtrer les données autant que ce qu’on voulait avec GraphQL, on les obtient nécessairement en bloc pré-définis, mais au moins on peut les obtenir en une seule requête “Qui sont les certifieurs de X, quel est leur statut d’adhésion ?”
- Une couche “validation des données” où les requêtes sont clairement définies “Quel est le statut d’adhésion de X” “Qui sont les certifieurs de X”.
Cette couche de validation peut être requêtée sur un noeud membre ou non-membre. Sur un noeud non-membre, il requête des noeuds membres directement connectés pour obtenir une liste de hash de réponses signées.
Le client, pour obtenir et valider des données, va donc :
- Requêter un noeud aléatoire, de préférence non-membre, pour obtenir des données
- Requêter 3 à 4 noeuds, membres ou non-membres, pour valider des données. Les données ne sont validées que pour par exemple 12 validations authentifiées. On peut s’appuyer sur WS2P pour transférer des demandes de validation, comme l’a suggéré elois (développement d’un module “ws2p-validation” ?) Pour chaque “bloc” de données obtenu, il calcul l’arbre merkle et vérifie qu’il peut trouver 12 signatures authentifiées qui garantissent de la validité des données parmis toutes les validations reçues.
Un réseau qui serait victime d’attaque sybille serait fortement paralysé (difficulté pour les clients léger de faire valider des données si il n’y a pas de noeud membre qui répond), mais ne serait pas compromis.
Tout ce que ça implique, c’est de télécharger dans un premier temps la liste de toutes les clés publiques membres, et de les mettre à jour régulièrement, afin de pouvoir vérifier les validations authentifiées.
Pour se défendre contre les attaques sybilles qui parallyserait le réseau, il faudrait implémenter un système de “délégation de clé pour les API”. Ainsi les noeuds membres qui calculent des blocs peuvent le faire de manière distincte des noeuds membres qui répondent aux requêtes des clients.
2 Likes
Oui mais contrairement à Bitcoin/Ethereum, nos blocs sont signés et donc authentifiables. Nous pouvons donc aisément détecter si l’on se trouve sur le chaîne principale ou pas, par simple constat d’inertie : si je regarde les 100, 500 ou 1500 derniers headers (en-tête de bloc, en supposant que les transactions n’en font plus partie pour un téléchargement rapide et une vérification immédiate du chaînage), je peux voir si en effet les données sont cohérentes avec la tête d’une chaine principale ou non : nombre d’émetteurs différents correct, temps évoluant dans une forme similaire à d’habitude, taille de fenêtre qui varie peu, contenance d’un bloc préalablement connu et validé de longue date, etc.
Ce constat d’inertie me semble être une solution très simple et redoutablement efficace pour avoir des infos valables sans interroger de noeud membre.
Mais en plus il y a aussi la propagation du document réseau HEAD, qui permet de connaître formellement l’état courant de tout noeud du réseau, notamment ceux membres. Et ceci sans les interroger.
Oui c’est la bonne façon de faire je pense, mais pas besoin de réaliser cela sur la couche réseau. Les données suffisent : tu les obtiens par noeuds miroirs, et ensuite tu peux authentifier le contenu car tout est signé. Tout client peut vérifier la cohérence des données entre elles et détecter un éventuel floutage.
J’insiste vraiment sur le fait qu’il faut laisser les noeuds membres tranquilles car plus la monnaie va être utilisée, plus ils auront autre chose à faire que répondre à des questions. Ils passeront plutôt leur temps à recevoir des ordres et à écrire dans la blockchain, ce qui est véritablement le coeur du logiciel. Qui plus est en s’attelant à répondre à des requêtes, on expose les noeuds à des attaques réseau (seconde raison principale qui m’a fait développer WS2P : il n’y a qu’une porte d’entrée, le refus y est rapide et peu coûteux).
On peut imaginer que certains noeuds offrent plus comme avec l’ajout de l’API GVA par exemple, mais c’est du bonus. Ceux-là s’exposeront à des risques acceptés par leur mainteneur, et surtout par défaut leur noeud sera protégé car dépourvu d’API publique.
Je comprends bien votre problématique de mainteneurs de logiciel client, mais de mon côté je dois défendre le coeur du réseau car c’est vraiment la partie sensible. Avec le nombre d’utilisateurs qui grimpe, la pression monte et je vais devenir de plus en plus exigeant (qui a dit paranoïaque ?).
3 Likes
6 messages ont été déplacés vers un nouveau sujet : Machine à état infalsifiable et requêtes de clients ?
Alors selon moi on n’a besoin des deux :
Se cacher permet d’empêcher toute attaque ciblée sur un membre particulier, mais les attaques non-ciblés qui vise juste “l’ensemble des nœuds membres ayant un endpoint ws2p public” restent possibles.
Il faut donc aussi des mesures de protection, mais même les protections les plus parfaites possibles ne suffiront pas face a une attaque ciblée sur un seul noeud en particulier, il est donc essentiel a long terme de permettre aux nœuds membre de ne pas dévoiler leur identité sur le réseau et ceux de façon user-friendly (un trousseau de clé alternatif a saisir point), donc TOR ne peut pas répondre a se besoin.
TOR reste cependant un atout fort appréciable pour sécuriser la monnaie car il permet d’avoir tout un réseau de nœuds membres dont on ne connais pas les IP, ce qui limite la surface d’attaque aux seuls endpoints publics en .onion.
Alors qu’un noeud dont un connais l’ip, on peut attaquer la machine correspondante sous d’autres angles, scan de port, ddos sur d’autres services derrière la même ip, exploitations de failles de sécurité, etc…
Exactement, et c’est pour cela que j’insiste, la feature d’anonymisation sur le réseau me semble obligatoire a long terme, ça ne nous sera sans doute pas utile avant des années, mais si un jours nous sommes des millions de membres et qu’on empiète sérieusement sur l’économie dominante les membres calculants seront bien content de pouvoir se cacher (car au final c’est d’abord la la faute des membres calculants tout ça, c’est eux qu’il faut anéantir).
1 Like