[tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Feb 13 16:05:56 UTC 2020
#32794: improve OOS (out-of-sockets) handler victim selection and more
--------------------------+------------------------------------
Reporter: starlight | Owner: (none)
Type: defect | Status: needs_review
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 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?)
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?)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32794#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list