[tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Sep 10 23:12:19 UTC 2019


#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


More information about the tor-bugs mailing list