[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos
#26294: attacker can force intro point rotation by ddos
-------------------------------------------------+-------------------------
Reporter: arma | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs, tor-dos, network-team- | Actual Points:
roadmap-2019-Q1Q2 |
Parent ID: #29999 | Points: 7
Reviewer: | Sponsor:
| Sponsor27-must
-------------------------------------------------+-------------------------
Comment (by asn):
Back when that ticket was filed, I also had the chance to meet with some
onion service experts and independently discuss this issue. Here are some
unpublished notes:
We decided that allowing this attack because of the replay cache is a red
herring. Specifically, the replay cache is not that big with only 16k-32k
requests so we could indeed grow it. Furthermore, we could also clear the
cache after X requests and start with a new one; that would allow the
attacker to replay each introduction once, but that's fine because making
new intro requests is not *that heavy* anyway, and it's definitely better
than allowing them to rotate our intro points non-stop.
Also it's important to realize that the replay cache is held on the HS-
side and not on the intropoint-side. I just verified this in our codebase,
because I was also confused about this! The HS keeps two (!) replay caches
for each INTRODUCE2 cell: one is per-intropoint (v3: replay_cache / v2:
accepted_intro_rsa_parts) and the other is per-HS and (v3:
replay_cache_rend_cookie / v2: accepted_intro_dh_parts).
I think what we should do here is:
a) Short-term: Reevaluate our replay detection strategy and see whether
it's indeed too heavy. Evaluate whether we need both caches. Evalute the
size of our replay caches given X requests. Evaluate whether we can clear
our replay caches after Y requests and just keep on using the same intro
points.
c) Medium-term: Consider more high-level directions to handle big load,
like proof of work, path selection, or other intro protocol.s
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26294#comment:8>
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