#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs