- Tor 0.4.8 introduit une défense permettant aux services onion de traiter en priorité le trafic réseau vérifié lorsqu’ils subissent des attaques DoS
- Dans l’architecture des services onion, qui masque les adresses IP, la limitation de débit basée sur l’IP est incomplète, d’où le besoin d’une méthode de puzzles côté client qui ne porte pas atteinte à la vie privée
- Lorsqu’un service est sous pression, le client doit prouver une charge de travail via des calculs de puzzle de plus en plus difficiles, et la priorité de connexion varie selon ce niveau
- Le temps de résolution initial pour un utilisateur normal est d’environ 5 ms sur un ordinateur rapide, et jusqu’à 30 ms sur du matériel plus lent, ce qui reste supportable sur la plupart des appareils
- Si le trafic d’attaque augmente, la charge de travail demandée peut monter jusqu’à environ 1 minute, rendant les tentatives de connexion massives coûteuses, tandis que les utilisateurs légitimes conservent une chance d’accès même en situation de congestion
Défense PoW pour les services onion dans Tor 0.4.8
- Avec la sortie de Tor 0.4.8, Tor introduit officiellement une défense par preuve de travail (PoW) pour les services onion
- L’objectif est de freiner les attaques DoS tout en priorisant le trafic vérifié
- Il est recommandé aux opérateurs de services onion de mettre à jour vers la version 0.4.8
- Les services onion masquent les adresses IP pour protéger la vie privée des utilisateurs, ce qui peut les rendre vulnérables aux attaques DoS ; une limitation de débit traditionnelle basée sur l’IP ne suffit donc pas à les protéger complètement
Puzzles côté client et traitement prioritaire
- Le PoW fonctionne essentiellement comme un système de tickets désactivé par défaut, puis crée une file de priorité lorsqu’un stress réseau apparaît
- Avant d’accéder à un service onion, le client doit résoudre un petit puzzle afin de prouver qu’il a fourni une certaine quantité de travail
- Plus le puzzle est difficile, plus cela signifie qu’une quantité de travail importante a été fournie
- Le service onion détermine la priorité de connexion en fonction du niveau d’effort démontré par le client
- Si un attaquant inonde un service onion avec de nombreuses requêtes, l’effort de calcul nécessaire pour accéder au site .onion augmente
- Les tentatives de connexion massives exigent davantage de ressources de calcul
- Plus la charge de travail augmente, moins l’attaque devient rentable
Impact visible pour les utilisateurs ordinaires
- Les utilisateurs ordinaires n’envoient généralement qu’un petit nombre de requêtes à la fois, si bien que la charge liée à la résolution des puzzles reste gérable sur la plupart des appareils
- Le temps de résolution initial est d’environ 5 ms sur un ordinateur rapide
- Jusqu’à 30 ms sur du matériel plus lent
- Si le trafic d’attaque augmente, la charge de travail peut monter jusqu’à environ 1 minute
- Ce processus est invisible pour l’utilisateur, et l’attente d’une réponse PoW ressemble à l’attente d’une connexion réseau lente
- Si les grands sites adoptent cette approche, elle peut réduire les effets négatifs des attaques ciblées sur la vitesse du réseau et aider à équilibrer la charge lors de pics soudains de trafic, rendant l’accès aux services onion plus cohérent et plus fiable
1 commentaires
Avis sur Hacker News
Intéressant. La proposition fixe clairement les attentes : il ne s’agit pas de bloquer les grands botnets, mais de se défendre contre les script kiddies et les petits botnets.
Même pendant une attaque DoS, les utilisateurs qui veulent réellement se connecter peuvent passer, mais cela peut leur demander un certain effort.
Le choix de https://github.com/tevador/equix comme algorithme de preuve de travail est lui aussi intéressant.
Au lieu d’un système où la réussite consiste à passer sous une cible statique comme avec Bitcoin, les clients « enchérissent » avec leur effort de preuve de travail, et plus l’effort fourni est élevé, plus leur priorité augmente. L’explication dit que cela ressemble à une preuve d’enjeu, dans le sens où l’on dépose du travail au lieu de déposer des coins.
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
Cette version est déjà bien, mais je pense qu’elle serait meilleure avec un transfert de valeur en plus.
En plus, la preuve de travail n’est qu’un calcul inutile et gaspillé. Le calcul n’est pas gratuit, et chaque watt consacré à la preuve de travail aggrave la crise climatique actuelle.
En tant que personne vivant dans une région qui atteindra dans quelques jours 120 degrés ressentis et 109 degrés réels, pour le dire poliment, j’ai envie de dire à quiconque suggère que la preuve de travail est une bonne idée pour quoi que ce soit d’aller se faire voir.
Ce n’est pas intéressant : c’est l’exemple le plus flagrant de consommation ostentatoire sur Terre.
Le meilleur texte, avec les vrais détails techniques, est https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p....
La fonction de preuve de travail choisie semble être equi-X.
Je suis surpris que ce genre de chose n’ait pas été intégré plus tôt, et comme je n’ai pas lu la proposition [0] assez en détail, je ne sais pas encore si cela ajoutera des données susceptibles d’affecter l’anonymat des utilisateurs. Cela dit, si c’est lié à une paire utilisateur-service et que ce n’est stocké nulle part, cela me semble acceptable.
Je me demande aussi dans quelle mesure cela réduira respectivement la charge du service proxifié et celle du nœud lui-même. Comme l’accès est réparti entre plusieurs nœuds, j’imagine que le bénéfice sera plus important côté service.
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Bien. Bientôt, on n’aura peut-être plus besoin de CDN anti-DDoS. Il suffira de fournir son API sous forme de service Onion.
Cette approche avait déjà été proposée autrefois pour lutter contre le spam par e-mail.
Cloudflare pourrait aussi le faire. À chaque fois qu’on accède à un site très fréquenté, on se retrouverait à lancer des calculs inutiles pendant quelques secondes à quelques minutes. L’effet global serait probablement d’aspirer les batteries du monde entier.
http://www.hashcash.org/
Fait intéressant, cela a inspiré le minage par preuve de travail de Bitcoin.
Parce que cela rejettera aussi des gaz à effet de serre dans l’atmosphère.
Je me demande ce qui empêche un acteur malveillant d’obtenir une nouvelle identité et de continuer le DDoS une fois que la preuve de travail commence à fonctionner.
Modification : il semble que la preuve de travail soit configurée au niveau du « service » attaqué, et non du client.
À cause de l’anonymat et de la possibilité de créer librement de nouvelles identités, un attaquant peut épuiser la capacité via une attaque Sybil et provoquer un déni de service.
Je me demande s’il existe une manière plus élégante de résoudre ici les attaques Sybil. Par exemple, beaucoup de CPU contiennent une paire de clés unique par processeur, vérifiable via les certificats racines des CA des émetteurs comme Intel, AMD, etc. Si l’on lie la preuve de travail à des signatures en série tout en autorisant la vérification parallèle, chaque preuve de travail devient unique par CPU, ce qui empêche de la paralléliser avec un botnet
Ils semblent viser la mémoire pour augmenter le coût des botnets. Il paraît exister beaucoup d’autres façons de réduire ce scénario d’attaque. La même logique pourrait sans doute s’appliquer aux téléphones utilisant une eSIM. Ensuite, comme l’authentification au réseau mobile utilise la cryptographie à clé publique, une preuve unique devrait aussi être possible
C’est juste une idée venue comme ça, donc il est très probable que je passe à côté de problèmes évidents de cette approche
La raison du choix d’un algorithme gourmand en mémoire est d’empêcher l’utilisation de matériel spécialisé, c’est-à-dire d’ASIC
Dans une direction similaire, je me demande ce que donnerait un serveur disposant de plusieurs pools d’IP et demandant au client de renvoyer une preuve de port knocking. Par exemple, on donne un jeton, on lui dit de l’envoyer à telle IP:port, puis on attend une réponse unique que je puisse vérifier. On pourrait appeler cela une preuve de latence. L’usage CPU est faible et la charge peut être répartie sur plusieurs machines et ports. L’inconvénient évident est qu’il faut plusieurs IP et potentiellement plusieurs serveurs. On pourrait aussi l’implémenter sur la même machine, mais alors la charge CPU ne ferait que se déplacer vers les connexions aux ports
J’ai une idée pour réduire le trafic du réseau Tor ou le rendre plus rapide. Il faudrait pouvoir utiliser le réseau comme un CDN. Si l’on veut publier un fichier, on devrait pouvoir envoyer des fragments de ce fichier à des nœuds autorisés, puis, lorsqu’une requête arrive pour ce fichier, pointer vers ces nœuds
Bien sûr, il faudrait veiller à ce que le réseau Tor ne devienne pas un « substitut anonyme à BitTorrent », ce qui irait à l’encontre de son objectif
La proposition actuelle parle de « priorisation du trafic réseau vérifié ». Comme cela aide effectivement le réseau, il serait intéressant que le partage de « fragments de fichier » puisse augmenter la priorité du trafic. Ce serait en quelque sorte une preuve de contribution en bande passante au lieu d’une « preuve de travail »
Cela dit, je ne vois toujours pas vraiment en quoi cela réduirait le trafic réseau. Il faut de toute façon communiquer avec les nœuds CDN
Au vu des objectifs et des limites fixés par cette proposition, elle semble raisonnable, et elle atteindra probablement ces objectifs. Comme indiqué, cela fonctionnera contre les petits botnets, mais les grands botnets pourront toujours submerger les ressources disponibles d’un client individuel
Personnellement, je n’aime pas la preuve de travail. Ici, cela ressemble plutôt à de la désoptimisation comme mécanisme de défense ; cela peut rendre rapidement obsolète du matériel ancien et, à l’échelle de tous les appareils concernés, consommer potentiellement beaucoup d’électricité. Déployé à grande échelle, ce serait une charge environnementale importante
Du point de vue de l’attaquant, faire monter la difficulté aussi haut peut déjà être considéré comme un succès. Si l’utilisateur doit faire tourner son appareil à 100 % et attendre une minute, dans beaucoup de cas il partira tout simplement
Malgré tout, c’est une assez bonne manière d’atténuer les attaques DoS sans nuire à l’anonymat des utilisateurs ; de ce point de vue, malgré ses défauts, c’est une bonne solution. Tant que cela reste dans Tor, ce n’est pas un gros problème, mais appliqué au Web général, ce serait à mon avis un désastre complet
L’article dit que l’écart de temps de résolution entre un serveur haut de gamme et un téléphone bas de gamme n’est que de 6 fois. Je ne vois pas comment c’est possible. Un serveur a bien plus de 6 fois plus de RAM et de cœurs CPU qu’un téléphone, et son CPU est probablement plus rapide
De plus, dans un DDoS, le travail côté serveur se parallélise de manière embarrassante, alors que le travail côté client ne l’est pas forcément
Même si l’écart n’est que de 6 fois, voire de 1 fois, il est dit qu’en cas de détection de DDoS le temps de résolution est d’une minute. À ce stade, le service n’est-il pas pratiquement hors ligne ?
Le point clé du passage disant qu’en cas de détection de DDoS le temps de résolution est d’une minute, c’est de transformer une attaque DoS facile existante, l’introduction flooding, en panne partielle ou en ralentissement. C’est une amélioration progressive d’un problème difficile