[tor-dev] Onion Service - Intropoint DoS Defenses

[George Kadianakis]

George Kadianakis <desnacked at riseup.net> writes:

> George Kadianakis <desnacked at riseup.net> writes:
>
>> juanjo <juanjo at avanix.es> writes:
>>
>>> Ok, thanks, I was actually thinking about PoW on the Introduction Point 
>>> itself, but it would need to add a round trip, like some sort of 
>>> "authentication based PoW" before allowing to send the INTRODUCE1 cell. 
>>> At least it would make the overhead of clients higher than I.P. as the 
>>> clients would need to compute the PoW function and the I.P. only to 
>>> verify it. So if right now the cost of the attack is "low" we can add an 
>>> overhead of +10 to the client and only +2 to the I.P. (for example) and 
>>> the hidden service doesn't need to do anything.
>>>
>>
>> Also see the idea in (b) (1) here: https://lists.torproject.org/pipermail/tor-dev/2019-April/013790.html
>> and how it couples with the "rendezvous approver" from ticket #16059.
>> Given a generic system there, adding proof-of-work is a possibility.
>>
>> Another option would be to add the proof-of-work in the public parts of
>> INTRO1 and have the introduction point verify it which is not covered in
>> our email above.
>>
>> Proof-of-work systems could be something to consider, altho tweaking a
>> proof-of-work system that would deny attackers and still allow normal
>> clients to visit it (without e.g. burning the battery of mobile clients)
>> is an open problem AFAIK.
>>
>>
>
> Here is how this could work after a discussion with dgoulet and arma on IRC:
>
> 1) Service enables DoS protection in its torrc.
>
> 2) Service uploads descriptor with PoW parameters.
>
> 3) Service sends special flag in its ESTABLISH_INTRO to its intro points
>    that says "Enable PoW defences".
>
> 4) Clients fetch descriptor, parse the PoW parameters and now need to
>    complete PoW before they send a valid INTRO1 cell, otherwise it gets
>    dropped by the intro point.
>
> All the above seems like they could work for some use cases.
>
> As said above, I doubt there are parameters that would help against DoS
> and still allow people to pleasantly visit such onion services through
> an uncharged mobile phone, but this choice is up to the onion
> service. The onion service can turn this feature on when they want, and
> disable it when they want. And mobile clients could also disallow visits
> to such sites to avoid battery/CPU burns.
>
> All the above seems likely, but it's significant work. We first need a
> proposal to discuss, and then there is lots of code to be written...
>

FWIW, thinking about this more, I think it's quite unlikely that we will
find a non-interactive PoW system here (like hashcash) whose parameters
would allow a legit client to compute a PoW in a reasonable time frame,
and still disallow a motivated attacker with GPUs to compute
hundreds/thousands of them in a single second (which can be enough to
DoS a service).

We should look into parameters and tuning non-interactive PoW systems,
or we could look into interactive proof-of-work systems like CAPTCHAs
(or something else), which would be additional work but might suit as
more.