#26294: attacker can force intro point rotation by ddos -------------------------------------------------+------------------------- Reporter: arma | Owner: asn Type: defect | Status: | merge_ready Priority: Medium | Milestone: Tor: | 0.4.2.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: tor-hs, tor-dos, network-team- | Actual Points: 6 roadmap-august, security, 042-should | Parent ID: #29999 | Points: 7 Reviewer: dgoulet | Sponsor: | Sponsor27-must -------------------------------------------------+-------------------------
Comment (by arma): Replying to [comment:27 asn]: > We actually had not heard that replay caches are there to protect against traffic analysis attacks. How does the attack work? I considered that identical INTRO2 cells could be used as a signal to the HS guard, but since they are end-to-end encrypted the singal should not be visible, right? The encryption protects the payload, but not the communications metadata (timing and volume). I worry about two impacts from replays by the intro point: * Capture an intro2 cell and later play it repeatedly, to create a pattern at the onion service's guard, at a time of our choosing. The replay cache at the onion service doesn't completely resolve this concern, because the intro point gets to send the cells before the onion service can realize they're replays. But if Mike succeeds at removing every side channel from the world, then the replayed intro1 cells are "legitimate" (i.e. expected and correctly formed) cells so without a replay cache there is no way to realize that they're not wanted. * Capture an intro2 cell and later play it repeatedly to create a pattern at the rendezvous point. This one is directly resolved by a replay cache at the onion service side. The impact is a bit subtle/indirect, but it would for example allow attacks where later you discover which rendezvous point a given introduction attempt used. The generalization of that second issue is that you get to induce the onion service to interact with the Tor network, at a time and frequency of your choosing, when otherwise you shouldn't have that capability. That possibility seemed like a good building block to all sorts of traffic confirmation attacks, and that's why we put the replay cache in place. I think the thinking has gone deeper since this original design, e.g. in the Vanguards discussion. So if are are ok with these issues, great. But at least now you know the original context. :) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26294#comment:33> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs