[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 23:16:08 UTC 2020
#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
More information about the tor-bugs
mailing list