Are latency based Proof-of-Work systems capable of preventing DDoS attacks on popular hidden tor services (.onion websites)?

Question

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.

Thoughts?

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.