La difesa proof-of-work di Tor: rendere costosi i DDoS contro gli onion service
Un onion service sotto flood non può fare ciò che fa un sito normale: non ci sono indirizzi IP da limitare, perché né i visitatori né gli attacker ne rivelano uno. La risposta di Tor, consegnata con il Tor 0.4.8 e annunciata sul blog del progetto nell'agosto 2023, è mettere un prezzo in tempo di CPU alla fase di introduzione. Il design discende dalla proposal 327, redatta nell'aprile 2020 da George Kadianakis, Mike Perry, David Goulet e tevador, che metteva il problema a nudo: costruire circuiti di rendezvous costa caro al servizio e alla rete, e il solo rate limiting non ha mai cambiato questo.
Un puzzle che compare solo sotto carico
Lo schema è trasparente nel senso del protocollo: non c'è un round-trip di sfida extra. I parametri del puzzle vivono dentro il descrittore dell'onion service che i client scaricano comunque - un tag di versione, un seed di 32 byte, un livello di sforzo suggerito e una scadenza. Finché lo sforzo suggerito resta a zero, la difesa dorme e le introduzioni procedono esattamente come prima. Quando il servizio rileva sovraccarico, alza lo sforzo suggerito. I client risolvono allora Equi-X, la funzione di puzzle specificata nella proposal, su una sfida costruita da una stringa di personalizzazione, l'ID cieco del servizio, il seed, un nonce casuale di 16 byte e lo sforzo scelto. La soluzione, di circa 43 byte, viaggia dentro la cella INTRODUCE1 come estensione. Secondo il blog di Tor, una prima risoluzione costa circa 5 millisecondi su una macchina veloce e fino a 30 su hardware più lento; sotto attacco sostenuto il lavoro richiesto può salire verso un minuto di calcolo.La coda paga a sforzo
Verificare una soluzione è volutamente economico; la parte costosa - costruire il circuito di rendezvous - è rimandata. Le richieste verificate entrano in una coda di priorità ordinata per sforzo dichiarato, le voci più vecchie vincono i pareggi, e uno scheduler la svuota a ritmo controllato. La difficoltà segue un ciclo add-increase e multiply-decrease su finestre di 300 secondi: finché la coda resta satura, il servizio porta lo sforzo al valore precedente più uno oppure allo sforzo medio delle introduzioni gestite, la cifra maggiore; quando la pressione cala, lo sforzo si riduce di circa un terzo. I client riprovano con sforzo crescente - raddoppio sotto 1.000, poi moltiplicazione per 1,5 - tra i limiti che la specifica fissa a 8 e 10.000. I seed ruotano circa ogni due ore, e il seed precedente resta accetto per un po' per evitare race condition.Perché gli utenti comuni se ne accorgono poco
Siccome il puzzle esiste solo finché il servizio è sotto stress, il traffico ordinario a basso carico non paga nulla. Una persona che apre qualche pagina durante un attacco spende millisecondi, un'esperienza che il blog paragona a aspettare su una connessione lenta, mentre un attacker che spara milioni di introduzioni paga per ognuna. La sintesi del Tor Project:"Blocks attackers while giving real users a chance to reach their destination" - blog del Tor Project, agosto 2023
Come i servizi aderiscono
Gli operatori comandano la difesa via torrc. Gli interruttori documentati nella guida DoS per onion service del progetto:- HiddenServicePoWDefensesEnabled - pubblica il puzzle nel descrittore e accende la coda ordinata per sforzo
- HiddenServicePoWQueueRate e HiddenServicePoWQueueBurst - a che velocità le richieste verificate lasciano la coda
- CompiledProofOfWorkHash - opzione globale che sceglie la funzione hash usata per i puzzle