[tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Jul 2 11:06:00 UTC 2019
#26294: attacker can force intro point rotation by ddos
-------------------------------------------------+-------------------------
Reporter: arma | Owner: asn
Type: defect | Status:
| needs_review
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs, tor-dos, network-team- | Actual Points: 6
roadmap-2019-Q1Q2 |
Parent ID: #29999 | Points: 7
Reviewer: | Sponsor:
| Sponsor27-must
-------------------------------------------------+-------------------------
Changes (by asn):
* status: assigned => needs_review
* actualpoints: 4 => 6
Comment:
OK here we go: https://github.com/torproject/tor/pull/1163
The functionality was not so hard to do, but the tests were a real PITA to
write since I needed to create a parseable INTRO2 cell (they actually look
quite simple in the final branch but that took tons of experimentation and
mocking to do).
WRT v3 code quality, I created a new periodic function called
`maintain_intro_point_replay_caches()` which maintains the replay cache.
An alternative (perhaps cleaner but definitely harder) approach would be
to make this "max number of entries" to be a parameter of the replaycache
and do the purging when we add elements as part of the replaycache
subsystem. I tried to do this, but the replaycache code is kinda messy and
I opted for the easier approach.
Also, I made good unittests for v3, but I never attempted to do the same
for v2. It just seems like too much work, given how much work the v3 test
was.
Finally, I have not tested this on chutney or the real network. This is
something I need to do before putting it in merge_ready.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26294#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list