[tor-bugs] #32794 [Core Tor/Tor]: improve OOS (out-of-sockets) handler victim selection and more
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Feb 14 03:59:40 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 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
More information about the tor-bugs
mailing list