[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #16052 [Tor]: Hidden service socket exhaustion by opening many connections
#16052: Hidden service socket exhaustion by opening many connections
------------------------+------------------------------------------
Reporter: asn | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.7.x-final
Component: Tor | Version:
Resolution: | Keywords: tor-hs dos SponsorR SponsorU
Actual Points: | Parent ID:
Points: |
------------------------+------------------------------------------
Comment (by yawning):
Replying to [comment:4 arma]:
> For this particular situation, if I'm reading the logs right, the
attacker sends 100 or so begin requests, and then pauses until he receives
a circuit-level sendme cell giving him permission to send the next batch.
So if our hack is of the form "hang up if there are 2000 concurrent
connection requests", we'll never get to that state because of our flow
control. That said, offering an off-by-default knob for "if you get
totally flooded, close the circuit", that the people who are experiencing
this attack in the wild can try, is a fine idea for a short-term hack.
It's not yet clear to me what exactly should be the trigger for this knob
though.
I asked Mike about this and got: "If tbb is making more than 6 concurrent
hs streams, that's a tbb bug.", with the caveat that "Some of these hs
chat protocols may be dumber.. I think the early torchat made one http
post per message".
So I still think providing a tunable (default-off) max-current-connection
knob makes sense here since it forces the attacker into doing more work.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16052#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs