Re: [tor-bugs] #16052 [Tor]: Hidden service socket exhaustion by opening many connections

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

#16052: Hidden service socket exhaustion by opening many connections
------------------------+------------------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-hs dos SponsorR SponsorU
Actual Points:          |  Parent ID:
       Points:          |
------------------------+------------------------------------------

Comment (by arma):

 Re Nick's 'e', see also #4700. I think we definitely do want to build this
 somehow. We could imagine doing it over the control port; we could imagine
 designing an exthsport or some godawful thing similar to the extorport; or
 we could imagine doing some sort of in-band signaling where the first k
 bytes of the connection are the identifier, and then we give people a
 little shim that does access control before passing on connections to the
 'real' service. A fourth, better, option would be great too.

 More broadly, this particular connection flooding attack is just one
 example out of many in the DoS field. Another variation is simply sending
 a whole lot of drop cells, and using up the bandwidth of the hs, or using
 up the bandwidth of its entry guard.

 This broad DoS field is one that we'd like to investigate for the future
 too. That's why we made sure to put it on the SponsorU topic list:
 https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorU/Tor

 We should keep two principles in mind while we're pondering solutions
 here:
 - We should think of ways to introduce or exploit asymmetry between the
 attacker and defender. For example, if our response to the attacker doing
 k things is to make sure the defender can handle n>k things, the defenders
 are going to be constantly sad.
 - One defense that we haven't brought to bear as much as we might is the
 initial rendezvous decision: when the service gets the intro2 cell, it can
 decide whether to perform the rendezvous. For a service that's under too
 much load, that's the right point for opting out of further load, because
 it controls all levels of interaction. (The corollary is that bugs like
 #15515 are really bad news because they threaten the service's control at
 this stage of the interaction.)

 Of course, ultimately, if all of the users are anonymous, and you want to
 serve all of them, and some of them are noisy, you will be unable to serve
 all of them. We can offer heuristics to the service operators so they can
 specify their preference on which ones to not serve. I'm having trouble
 seeing a future where we have an on-by-default one-size-fits-many
 heuristic though.

 For this particular situation, if I'm reading the logs right, the attacker
 sends 100 or so begin requests, and then pauses until he receives a
 circuit-level sendme cell giving him permission to send the next batch. So
 if our hack is of the form "hang up if there are 2000 concurrent
 connection requests", we'll never get to that state because of our flow
 control. That said, offering an off-by-default knob for "if you get
 totally flooded, close the circuit", that the people who are experiencing
 this attack in the wild can try, is a fine idea for a short-term hack.
 It's not yet clear to me what exactly should be the trigger for this knob
 though.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16052#comment:4>
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