I was reading an interesting article found here: http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-703.pdf

It's titled "Lazy Susan: dumb waiting as proof of work".

It suggested the following in section 3.1.1:

Consider as a strawman a system in which the server responds to a client’s request with a delay(d) message, where d is some time that the client must delay before continuing the communication. If the client does not respond after d ticks then the server will simply drop the request. If and only if the client responds after a delay of at least d ticks will the server process the client’s request. Earlier requests by the client are ignored, or worse, cause the server to disconnect the client. We will later demonstrate how the latter technique can be securely implemented as a variant of SYN cookies [9] (§3.1.2).

I assume that this technique would be impossible to implement from behind a tor hidden service because it would be impossible to differentiate clients by IP address.


1 Answer 1


The article you quote applies their latency system on SYN packets, the first step of a TCP handshake. For the attacker, SYN flood attacks are attractive because they work well with IP spoofing: since the attacker does not need to see the response packets from the server (the SYN+ACK), then the attacker can use a fake source address, and thus remain "hidden". None of this really applies to a Tor hidden server, because, by definition, the attacker cannot know the true IP address of the server. Indeed, when accessing a server through Tor, any client talks to it only through several successive routers, and the router which actually talks to the hidden server will not be the attacker's machine (or, at least, so we hope) -- thus, no SYN flood.

(Or, more accurately, an attacker can SYN flood any Tor relay node, but cannot know which relay node is actually his specific target site.)

The principle of latency might still be applied, at a higher level. It exists in the case of emails; this is called Greylisting. Upon first connection, the email sender is being temporarily rejected, and informed that it should try again later on. Only if it comes back after a few minutes (or hours) then the email is accepted as genuine. This assumes that the spammer won't allocate resources to remember the email sending, thus won't come back.

Translated to a Web context, this would take the form of a special HTTP response "come back later" which would include a secret token computed by the server, to be included in the response, so that the server knows that it is "the same client" than previously. Doing that without allocating too much memory on the server can be tricky (encoding dates, counters and a MAC in the token can help). However, a big issue remains: this system needs client cooperation. We cannot rely on the attacker for cooperating...

Latency-based systems work as long as the server can know when a given client is coming back, but also when this is a new client. This must work both ways: a returning client must be able to prove that it is the same client than previously (the "secret token" alluded to above can do that), but it must not be able to masquerade as a whole new client when it is actually a returning client. The privacy features of Tor effectively prevent that. Indeed, if any connection could be unambiguously identified as "new client" or "same client than previously", then client tracking would be too easy.

Thus, we can say that Tor is indeed incompatible with anti-DDoS systems which rely on client tracking, including latency-based system.

  • regarding this statement "if any connection could be unambiguously identified as 'new client' or 'same client than previously', then client tracking would be too easy." - Can cookies not provide this functionality? If the cookie does not contain the required token, treat as new client. If cookie contains the required token, treat as same client as before. Not knowing anything except the token you gave them and when you gave it to them should be enough, no? Apr 21, 2013 at 18:07
  • 1
    The cookie is something sent by the server and stored on the client. The client is responsible for sending it back to the server. But when the client is the attacker (the DDoS situation), the client may prefer not to send the cookie if it serves best its nefarious schemes. If client cooperation is needed to recognize the client as "returning", then a malicious client can pass as a "new" client whenever it wishes to. Apr 21, 2013 at 18:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .