L'articolo che citi applica il loro sistema di latenza sui pacchetti SYN, il primo passo di un handshake TCP . Per gli aggressori, gli attacchi SYN flood sono interessanti perché funzionano bene con IP spoofing : poiché l'autore dell'attacco non ha bisogno di vedere i pacchetti di risposta dal server (SYN + ACK), quindi l'attaccante può usare un falso indirizzo sorgente, e quindi rimanere" nascosto". Nulla di tutto ciò si applica a un server Tor nascosto, perché, per definizione, l'utente malintenzionato non può conoscere il vero indirizzo IP del server. Infatti, quando si accede a un server tramite Tor, qualsiasi client parla solo attraverso più router successivi, e il router che effettivamente parla al server nascosto non sarà la macchina dell'attaccante (o, almeno, così speriamo) - quindi, no SYN flood.
(O, più precisamente, un utente malintenzionato può inondare SYN qualsiasi nodo di relay Tor, ma non può sapere quale nodo relay è in realtà il suo specifico sito di destinazione.)
Il principio della latenza potrebbe ancora essere applicato, ad un livello più alto. Esiste nel caso di e-mail; questo è chiamato Greylisting . Alla prima connessione, il mittente dell'e-mail viene temporaneamente respinto e informato che dovrebbe riprovare più tardi. Solo se ritorna dopo alcuni minuti (o ore), l'e-mail è accettata come autentica. Ciò presuppone che lo spammer non allocherà risorse per ricordare l'invio di e-mail, quindi non tornerà.
Tradotto in un contesto Web, questo assumerebbe la forma di una risposta HTTP speciale "torna indietro" che includerebbe un token segreto calcolato dal server, da includere nella risposta, in modo che il server sappia che è "lo stesso cliente" di prima. Fare ciò senza allocare troppa memoria sul server può essere complicato (le date di codifica, i contatori e un MAC nel token possono aiutare ). Tuttavia, rimane un grosso problema: questo sistema ha bisogno della collaborazione del cliente. Non possiamo fare affidamento sull'attaccante per aver collaborato ...
I sistemi basati sulla latenza funzionano fintanto che il server può sapere quando un determinato client sta tornando, ma anche quando questo è un nuovo client. Questo deve funzionare in entrambi i modi: un client di ritorno deve essere in grado di dimostrare che è lo stesso client di prima (il "token segreto" di cui sopra può farlo), ma deve non essere in grado di masquerade come un nuovo client quando è in realtà un client di ritorno. Le caratteristiche di privacy di Tor lo impediscono in modo efficace. In effetti, se una qualsiasi connessione potesse essere identificata in modo inequivocabile come "nuovo client" o "lo stesso client di prima", il monitoraggio dei clienti sarebbe troppo semplice.
Quindi, possiamo dire che Tor è effettivamente incompatibile con i sistemi anti-DDoS che si basano sul tracciamento del client, incluso il sistema basato sulla latenza.