[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 starlight):

 Replying to [comment:17 nickm]:
 > 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.)

 hi!  This is implemented. . .can add more comments to pick_oos_victims()
 if desired.

 > 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.

 ok, how to tell if it's a bridge?

 >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?)

 but can "any client" set the digest ''and'' be in the consensus with a
 stable flag a cbw 500 or higher?  Perhaps I should add some more comments.

 > 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?)

 Adding randomness while retaining some degree of time priority in band A,
 age*cbw in band B makes sense to me.

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