Opened 5 years ago

Closed 2 years ago

#1199 closed task (wontfix)

tunnel node selection

Reported by: user Owned by:
Priority: minor Milestone:
Component: router/general Version: 0.9.10
Keywords: peer-selection privacy anonymity Cc:
Parent Tickets:

Description (last modified by zzz)

current version: 0.9.10-9

One and the same peer should not be chosen as direct neighbor in both inbound and outbound tunnels of the same destination, as he could easily determine his position by timing.


Change History (8)

comment:1 Changed 5 years ago by zzz

What kind of timing? Example please. Must it be "direct neighbor" on both? Or elsewhere in the tunnel? Is this just a special case of a general traffic analysis attack?

Right now in the code, every "tunnel pool" selects its peers independently. Inbound and outbound for a destination are separate pools. To implement some inter-pool dependencies could be difficult.

comment:2 Changed 5 years ago by user

direct neighbor to the tunnel builder, i.e. first hop in outbound and last hop in inbound.

You (U) are a participating node in two tunnels, in one of which the previous hop is A in the other the next hop is A.
Since tunnels bring a certain intrinsic delay, there's a time that passes between a http request and the response. If you now find that the traffic pattern going to A and coming from A is correlated and the delays are especially small, you can with high probability deduce that you are the first hop on that tunnel. This does not yet deanonymize the service, but could be used in attacks. nodes participating in tunnels should only know whether they are OBEP, IBGW or other, but this introduces the possibility to tell in certain cases that you are first hop.

Maybe I'm just paranoid, but to me it sounds like this would ideally be prevented.
(I guess same reasons why we're at unidir tunnels in the first place, so _maybe_ we'D even want in and out tunnels not to share nodes at all???)

comment:3 Changed 5 years ago by zzz

  • Description modified (diff)

Yeah, I don't think there's anything special here about 'direct neighbor', you can do timing attacks from any position in the tunnel.

Your premise is flawed, as the "direct neighbors" would see the greatest time between request and response, not the smallest. the OBEP/IBGW pair would see the smallest time.

The (undocumented? see #1154) tier slicing doesn't help here, as IB and OB are different pools.

You say the knowledge of being in an IB and OB tunnel "could be used in attacks". Example please.

Last edited 5 years ago by zzz (previous) (diff)

comment:4 Changed 5 years ago by zzz

  • Description modified (diff)

comment:5 Changed 5 years ago by zzz

  • Milestone changed from 0.9.13 to 0.9.15
  • Status changed from new to infoneeded_new

comment:6 Changed 4 years ago by str4d

  • Keywords peer-selection privacy anonymity added
  • Milestone 0.9.15 deleted

comment:7 Changed 4 years ago by user

  • Status changed from infoneeded_new to new

i don't know, it's a gut feeling. maybe someone smarter than me can turn it into an attack, maybe not. i don't have a concrete attack, so feel free to close this bug.
my feeling was that each node should be in each tunnel only once and also only never in any structure twice where the is only one node in between. if i run a hidden server, then in my understanding the last inbound node is the last one to see the packet destined to me and the first outbound hop sees my immediate response, without network delays and might thus conclude that i am indeed the originator, i.e. the one hosting a the service, and not just another hop.
That alone does not deanonymize anything as they don't know which service it is. But ideally only OBEP and IBGW know about their position in a tunnel.
That was all of my thinking when i saw i was connecting to the same peer in inbound and outbound for the same local dest.
maybe my concerns are not justified, i am not an expert. gut feeling, as i said.

comment:8 Changed 2 years ago by zzz

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.