[tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more

[Tor Bug Tracker & Wiki]

#32794: improve OOS (out-of-sockets) handler victim selection and more
--------------------------+------------------------------------
 Reporter:  starlight     |          Owner:  starlight
     Type:  defect        |         Status:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.4.4.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.4.2.5
 Severity:  Normal        |     Resolution:
 Keywords:  security      |  Actual Points:
Parent ID:                |         Points:
 Reviewer:  nickm         |        Sponsor:
--------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:17 nickm]:
 > So as I understand it, the proposed new algorithm is:
 >
 > > Consider only edge connections and OR connections with no identity
 set.
 > >
 > > Close the newest N such connections, until we have regained enough
 sockets.
 >
 > There are some problems here that we should think about.  They all stem
 from the fact that an attacker is not required to do the kind of DoS
 attack that we expect: the attacker will know our algorithm, so they can
 adjust their attack to work around it.
 >
 > 1. If we have a DirPort open, the attacker can open connections to our
 DirPort: so we should also consider DirPort connections that have sockets
 set.    (The fix for this one is easy: just check Directory connections
 too.)
 >
 > 2. Checking whether a connection's identity_digest is zero will not
 always do what we want.  First, bridges do not set their identity digest,
 even though a bridge may have circuits from multiple users.  Second, any
 client can pretend to be a relay and provide authentication when it
 connects to us, thereby setting an identity digest.  (This one is harder
 to fix: we could look for relays that are in the consensus, but a relay
 that is not in the consensus might just be a new one that we don't know
 about yet.  I don't know a supported way to detect bridges -- there isn't
 supposed to be one, really.  We could look at the number of circuits,
 perhaps?)

 It's also worth thinking about onion services and single onion services
 here. A busy onion service may look similar to a bridge, from the
 perspective of the upstream hop: both open lots of circuits.

 Also, bridges and onion services can experience a socket DoS, too. We
 should think about how this algorithm might work for them, even if we
 don't activate it right now.

 > 3. The attacker is not required to flood us with connections: they can
 send a trickle instead.  Instead of opening a whole bunch of connections
 at once, the attacker can open a new connection every 5 minutes. This will
 still eat up all of our sockets over time, but when we go to close the
 newest ones, the attacker will still have a bunch of our capacity.  (I do
 not know the right fix for this. We could randomize the algorithm, I
 guess?)

 I think randomising the sockets we close is the hardest algorithm to
 exploit, because the attacker can't know which sockets were going to close
 next.

 We may want to assign a lower probability to sockets that we have recently
 opened to fetch directory documents, and connections on which we are
 currently fetching directory documents. (Attackers can occupy these
 sockets using a slowloris attack, so we should still be prepared to close
 them, if we have a lot of them open.)

 We should also assign a threshold value, so we keep a few directory
 sockets. (150 seems like a good threshold for relays, because they do
 approximately 7000 relays / 96 descriptors per request * 2 requests for
 descriptors, when they don't have any cached descriptors.)

 Remember, relays can use remote DirPorts and ORPorts for directory
 fetches, the code should handle both.

 We should also try to think of any other kinds of essential sockets, that
 we don't want to close.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32794#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online