La défense par preuve de travail de Tor : rendre le déni de service contre les onion services hors de prix
Un onion service sous inondation ne peut pas faire ce que fait un site web normal : il n'y a aucune adresse IP à limiter en débit, car ni les visiteurs ni les attaquants n'en révèlent une. La réponse de Tor, livrée avec Tor 0.4.8 et annoncée sur le blog du projet en août 2023, consiste à facturer l'étape d'introduction en temps de calcul. Le design descend de la proposition 327, rédigée en avril 2020 par George Kadianakis, Mike Perry, David Goulet et tevador, qui posait le problème sans détour : construire des circuits de rendez-vous coûte cher au service comme au réseau, et la limitation de débit seule n'y a jamais rien changé.
Un puzzle qui n'apparaît qu'en surcharge
Le schéma est transparent au sens du protocole : aucun aller-retour de défi supplémentaire. Les paramètres du puzzle logent dans le descripteur de l'onion service que les clients récupèrent de toute façon - une balise de version, une graine de 32 octets, un niveau d'effort suggéré et une expiration. Tant que l'effort suggéré reste à zéro, la défense sommeille et les introductions se déroulent exactement comme avant. Quand le service détecte une surcharge, il relève l'effort suggéré. Les clients résolvent alors Equi-X, la fonction de puzzle spécifiée dans la proposition, sur un défi construit à partir d'une chaîne de personnalisation, de l'identifiant de service aveuglé, de la graine, d'un nonce aléatoire de 16 octets et de l'effort choisi. La solution, d'environ 43 octets, voyage dans la cellule INTRODUCE1 sous forme d'extension. Selon le blog de Tor, une première résolution coûte environ 5 millisecondes sur une machine rapide et jusqu'à 30 sur du matériel plus lent ; sous attaque soutenu, le travail requis peut grimper vers une minute de calcul.La file paie à l'effort
Vérifier une solution est volontairement bon marché ; la partie coûteuse - construire le circuit de rendez-vous - est différée. Les requêtes vérifiées entrent dans une file de priorité ordonnée par l'effort revendiqué, les entrées plus anciennes gagnant les égalités, et un ordonnanceur la vide à un rythme maîtrisé. La difficulté suit un cycle d'augmentation-addition et de réduction-multiplication par fenêtres de 300 secondes : tant que la file reste saturée, le service porte l'effort soit à sa valeur précédente plus un, soit à l'effort moyen des introductions traitées, selon la plus grande des deux valeurs ; quand la pression retombe, l'effort décroît d'environ un tiers. Les clients réessaient avec un effort croissant - doublement sous 1 000, puis multiplication par 1,5 - entre les bornes que la spécification fixe à 8 et 10 000. Les graines tournent environ toutes les deux heures, la précédente restant acceptée un temps pour éviter les conditions de course.Pourquoi les utilisateurs ordinaires ne le remarquent guère
Comme le puzzle n'existe que lorsque le service est sous stress, le trafic ordinaire en faible charge ne paie rien. Une personne qui ouvre quelques pages pendant une attaque dépense des millisecondes, une expérience que le blog compare à attendre sur une connexion lente, tandis qu'un attaquant qui lance des millions d'introductions paie chacune d'elles. Résumé du Tor Project :"Blocks attackers while giving real users a chance to reach their destination" - blog du Tor Project, août 2023
Comment les services l'activent
Les opérateurs commandent la défense via torrc. Les commutateurs documentés dans le guide DoS des onion services du projet :- HiddenServicePoWDefensesEnabled - publie le puzzle dans le descripteur et active la file ordonnée par effort
- HiddenServicePoWQueueRate et HiddenServicePoWQueueBurst - la vitesse à laquelle les requêtes vérifiées quittent la file
- CompiledProofOfWorkHash - option globale choisissant la fonction de hachage utilisée pour les puzzles