Re: [tor-bugs] #16052 [Tor]: Hidden service DoS by hammering RELAY_BEGIN

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#16052: Hidden service DoS by hammering RELAY_BEGIN
------------------------+--------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-hs dos
Actual Points:          |  Parent ID:
       Points:          |
------------------------+--------------------------------
Changes (by yawning):

 * cc: yawning (added)


Old description:

> Hello,
>
> it seems that some HSes are getting DoSed by an attacker who establishes
> a few circuits and then sends thousands of `RELAY_BEGIN` cells through
> them. It's basically a variant of #15515, but fortunately this can be
> fixed by patching the HS.
>
> Here are some fixes ideas from Yawning:
>
> a) Some variation on "implement a hard cap on the number of simultaneous
> streams that can be associated to a given circuit before we start
> rejecting RELAY_BEGINs".  Will break apps if the hard cap is too low due
> to web browsers wanting to open tons of TCP/IP connections (limiting it
> to something like... 16/32/64 with it being tunable may be ok, consult
> Mike?)
>
> b) Apply throttling to RELAY_BEGINs over a given circuit.  Something like
> "allow up to N streams to complete immediately, then each subsequent
> stream will be delayed for x seconds, doubling for each additional
> RELAY_BEGIN, resetting after y seconds".  Annoying since queuing is
> required (OOM hazard here?).
>
> c) "If you want to be more resilient to this, use an AF_UNIX backed HS".
> This should* shift the part that crumples to the app code, at which point
> it's kind of not our problem.

New description:

 Hello,

 it seems that some HSes are getting DoSed by an attacker who establishes a
 few circuits and then sends thousands of `RELAY_BEGIN` cells through them.
 It's basically a variant of #15515, but fortunately this can be fixed by
 patching the HS.

 Here are some fixes ideas from Yawning:

 a) Some variation on "implement a hard cap on the number of simultaneous
 streams that can be associated to a given circuit before we start
 rejecting RELAY_BEGINs".  Will break apps if the hard cap is too low due
 to web browsers wanting to open tons of TCP/IP connections (limiting it to
 something like... 16/32/64 with it being tunable may be ok, consult Mike?)

 b) Apply throttling to RELAY_BEGINs over a given circuit.  Something like
 "allow up to N streams to complete immediately, then each subsequent
 stream will be delayed for x seconds, doubling for each additional
 RELAY_BEGIN, resetting after y seconds".  Annoying since queuing is
 required (OOM hazard here?).

 c) "If you want to be more resilient to this, use an AF_UNIX backed HS".
 This should shift the part that crumples to the app code, at which point
 it's kind of not our problem (the HS code might fall down for other
 reasons in this case, so I don't see this as being a real solution...)

--

Comment:

 Personally I'm in favor of "a" since it's the easiest to implement, and if
 it's tunable, people can choose the right number for their HS.  Something
 that's more automagic like "b" would be nicer, but the implementation gets
 more complicated.

 As far as I can tell the impact of this is only a DoS, either through
 totally bogging the application/tor down, or by causing exhaustion of file
 descriptors/unused ports on the loopback interface (which is why I suggest
 "c", though realistically I suspect that the app or tor will die before
 most systems manage to exhaust the available port space).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16052#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs