Investigate LS lookups over client tunnels
Opened 7 years ago
Last modified 6 years ago
#1166assigneddefect
Investigate LS lookups over client tunnels
Reported by:zzzOwned by:zzz Priority: minor Milestone:
Component: router/netdb Version: 0.9.9 Keywords: privacy anonymity Cc: dg Parent Tickets:
Sensitive: no
Description
Not a new idea but perhaps not documented before.
Better or worse for anon? Easy or hard? All LS lookups or only those originated from certain places?
-
OCMOSJ (messages)
-
LookupDestJob? (b32)
-
anywhere else?
Easy or hard?
Subtickets
Activity
changed milestone to %undecided
comment:1 Changed 7 years ago by dg
Cc:dg added
-
comment:2 Changed 7 years ago by zzz
Milestone: → 0.9.11Status:new → accepted
OCMOSJ in af58c48ba5314717accb8b2cad702e5b8c868825 0.9.9-8
LDJ target 0.9.11
-
comment:3 Changed 7 years ago by user
As of router version 0.9.9-10: from a short sample of 71 lookups that were NOT done via client tunnels: 64 are RI (that's fine), but 7 are for LS.
2nd sample only looking at LS now: 56 false, 890 true, so 6.3% of LS lookups still done via exploratory tunnel here.
(samples taken in chronological order with low router uptimes)
-
comment:4 Changed 7 years ago by user
Priority:minor → major
-
comment:5 Changed 7 years ago by user
upping priority, as this is anonymity-related and should therefore be high on the priority list.
not a blocker though since it's been running like this for long and no concrete case of the attack is knonwn. Still, anonymity issues should always be top priority, since that's what i2p is about.
-
comment:6 Changed 7 years ago by zzz
Was waiting for unrelated I2CP changes to be propped to avoid merge conflicts. These were merged in 0.9.10-6 so I'll get to the b32 changes shortly.
-
comment:7 Changed 7 years ago by zzz
Resolution: → fixedStatus:accepted → closed
LDJ in e7ad6d2e4c020323240c8a5dc4507f63ee5ec16e 0.9.10-7
-
comment:8 Changed 7 years ago by user
Milestone:0.9.11 → 0.9.13Priority:major → minorResolution:fixedStatus:closed → reopened
thx for the fixes so far.
router version 0.9.10-7 and still having some LS lookups via expl. tunels here.
very few but there are, and a leak's a leak.
we should get rid of them totally
I think it's also more during the startup
well, if it's a close-on-idle tunnel, it won't open the tunnel until you have a dest, but you have to resolve the b32 to get a dest…
there may be other cases, not sure
can't we have close on idle tunnels open w/o dest?
outbound would notice client-side activity and open up, and automatically resurect inbound too
if we agree that it is dangerous to lookup LS via expl, then only looking up most of the LS via client might not be the complete solution
or a textual warning that close-on idle may be less secure, if it'S really much work to change
I count only 45
I'm sorry for being such a nag
-
comment:9 Changed 6 years ago by str4d
Keywords:privacy anonymity added Milestone:0.9.13Status:reopened → infoneeded
Are there still LS lookups happening through exploratory tunnels?
How are you counting them, user?
What needs to happen to close this ticket?
-
comment:10 Changed 6 years ago by user
Status:infoneeded → assigned
I don't know, I have not looked in quite a while. But if that code was not touched, then it is likely still happening.
Once there is no more direct correlation of a LS and an exploratory tunnel, this ticket can be closed.
-
comment:11 Changed 6 years ago by user
also it only checked for the reply tunnel, not the out tunnel.
I can see why a reply tunnel is the bigger concern, but am not fully convinced that out tunnels are totally fine. I think I only tested for OCMOSJ going through expl tunenl, not for LDJ either.
Extensive logging should be added for all of those, I think. If under normal use there is no more leaks during the entire session, then all is fine. I think, it mainly wasduring startup or had to do with sleep on idle tunnels.