Re: [tor-bugs] #16824 [Tor]: coexistence of client and relay processing on same thread poses traffic confirmation risk

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#16824: coexistence of client and relay processing on same thread poses traffic
confirmation risk
-----------------------------------------+---------------------------------
 Reporter:  starlight                    |          Owner:
     Type:  defect                       |         Status:  new
 Priority:  High                         |      Milestone:  Tor:
Component:  Tor                          |  0.2.8.x-final
 Severity:  Normal                       |        Version:  Tor: 0.2.6.10
 Keywords:  PostFreeze027, 027-backport  |     Resolution:
Parent ID:                               |  Actual Points:
  Sponsor:                               |         Points:
-----------------------------------------+---------------------------------

Comment (by mikeperry):

 First off, guard discovery attacks are far more an issue for a hidden
 service than a normal client. In general, guard discovery works by causing
 the tor instance to create lots of new circuits, and waiting until a
 malicious middle node is chosen. That malicious middle then gets to learn
 the guard node next to it.

 I think a normal client probably could get away with just using 3 hops as-
 is in this local-relay-as-bridge configuration, and not modify their
 second tor client instance at all, because the traffic volumes are should
 be much smaller and not directly under adversary control. Also, for many
 client application protocols, there's not an easy way to cause the client
 to keep building circuits.

 The reason I think it's a bad idea to run a hidden service in this
 configuration without an actual guard after the local-relay-as-bridge is
 because I suspect that the combination of guard discovery and the ability
 for the adversary to generate a lot of traffic to a hidden service means
 that it will be obvious to someone who is monitoring your guard that it is
 both the relay and the client: They can perform guard discovery, find your
 relay, and then send a bunch of traffic at the hidden service and not see
 that traffic volume leave the guard to any currently connected remote
 clients. If instead, your hidden service is using an additional guard
 after your relay, you benefit from the additional relay cover traffic
 between those two nodes. I could explain this more formally, but it
 basically all boils down to the base rate of background traffic that the
 adversary needs to consider in each situation.

 However, I could see an argument that removing the side channel that
 client activity is happening at all on a given relay is more important
 than these second-order guard discovery concerns. After all, the adversary
 does need two attacks to determine the existence of a client on a relay
 for the 'local bridge' configuration, where as they only need passive
 monitoring to determine if relays are running a hidden service in the
 standard configuration (via bug #16585 - nice find btw).

 Therefore, I could personally be convinced that a simple log message
 telling users that they may want to run a second tor instance and use the
 relay as a local bridge is a good enough stopgap. I don't know how Nick
 and Roger feel, though, and they are both highly distracted by ED
 responsibilities.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16824#comment:16>
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