La defensa de proof-of-work de Tor: encarecer la denegación de servicio contra los onion services
Un onion service bajo un ataque de inundación no puede hacer lo que hace un sitio web normal: no hay direcciones IP a las que aplicar límites de tasa, porque ni los visitantes ni los atacantes revelan una. La respuesta de Tor, incluida en Tor 0.4.8 y anunciada en el blog del proyecto en agosto de 2023, es ponerle precio en tiempo de procesador al paso de introducción. El diseño desciende del proposal 327, redactado en abril de 2020 por George Kadianakis, Mike Perry, David Goulet y tevador, que planteó el problema de raíz sin rodeos: construir circuitos de rendezvous es caro para el servicio y para la red, y el límite de tasas por sí solo nunca cambió eso.
Un puzle que solo aparece bajo carga
El esquema es transparente en el sentido protocolar: no hay un viaje de ida y vuelta extra de desafío. Los parámetros del puzle viven dentro del descriptor del onion service que los clientes descargan de todos modos: una etiqueta de versión, una semilla de 32 bytes, un nivel de esfuerzo sugerido y una fecha de caducidad. Mientras el esfuerzo sugerido se mantenga en cero, la defensa duerme y las introducciones proceden exactamente igual que antes. Cuando el servicio detecta sobrecarga, sube el esfuerzo sugerido. Los clientes resuelven entonces Equi-X, la función de puzle especificada en el proposal, sobre un desafío construido con una cadena de personalización, el ID de servicio cegado, la semilla, un nonce aleatorio de 16 bytes y el esfuerzo elegido. La solución, de unos 43 bytes, viaja dentro de la celda INTRODUCE1 como una extensión. Según el blog de Tor, una primera resolución cuesta alrededor de 5 milisegundos en una máquina rápida y hasta unos 30 en hardware más lento; bajo un ataque sostenido, el trabajo necesario puede acercarse a un minuto de cómputo.La cola cobra por esfuerzo
Verificar una solución es deliberadamente barato; la parte cara -construir el circuito de rendezvous- se aplaza. Las solicitudes verificadas entran en una cola de prioridad ordenada por el esfuerzo declarado, con las entradas más antiguas ganando los empates, y un planificador la drena a ritmo controlado. La dificultad sigue un ciclo de aumento-adición y reducción-multiplicación en ventanas de 300 segundos: mientras la cola siga saturada, el servicio sube el esfuerzo al valor anterior más uno o al esfuerzo promedio de las introducciones atendidas, lo que sea mayor; cuando la presión baja, el esfuerzo decae cerca de un tercio. Los clientes reintentan con esfuerzo creciente -duplicándolo por debajo de 1.000 y luego multiplicándolo por 1,5- entre los límites que la especificación fija en 8 y 10.000. Las semillas rotan cada dos horas aproximadamente, y la semilla anterior se acepta por un tiempo para evitar condiciones de carrera.Por qué los usuarios normales casi no lo notan
Como el puzle solo existe mientras el servicio está estresado, el tráfico ordinario con poca carga no paga nada. Una persona que abre unas cuantas páginas durante un ataque gasta milisegundos, una experiencia que el blog compara con esperar en una conexión lenta, mientras un atacante que lanza millones de introducciones paga por cada una. El resumen del Tor Project:"Blocks attackers while giving real users a chance to reach their destination" - blog del Tor Project, agosto de 2023
Cómo optan los servicios
Los operadores controlan la defensa mediante torrc. Los interruptores documentados en la guía de mitigación de DoS para onion services del proyecto:- HiddenServicePoWDefensesEnabled - publica el puzle en el descriptor y activa la cola ordenada por esfuerzo
- HiddenServicePoWQueueRate y HiddenServicePoWQueueBurst - a qué velocidad drenan de la cola las solicitudes verificadas
- CompiledProofOfWorkHash - opción global que elige la función hash usada en los puzles