Opened 8 years ago

Last modified 7 years ago

#1166 assigned defect

Investigate LS lookups over client tunnels

Reported by: zzz Owned by: zzz
Priority: minor Milestone:
Component: router/netdb Version: 0.9.9
Keywords: privacy anonymity Cc: dg
Parent Tickets: Sensitive: no


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?

Easy or hard?



Change History (11)

comment:1 Changed 8 years ago by dg

Cc: dg added

comment:2 Changed 8 years ago by zzz

Milestone: 0.9.11
Status: newaccepted

OCMOSJ in af58c48ba5314717accb8b2cad702e5b8c868825 0.9.9-8
LDJ target 0.9.11

comment:3 Changed 8 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 8 years ago by user

Priority: minormajor

comment:5 Changed 8 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 8 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 8 years ago by zzz

Resolution: fixed
Status: acceptedclosed

comment:8 Changed 8 years ago by user

Priority: majorminor
Resolution: fixed
Status: closedreopened

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

<zzz> 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…
<zzz> there may be other cases, not sure

<superuser> can't we have close on idle tunnels open w/o dest?
<superuser> outbound would notice client-side activity and open up, and automatically resurect inbound too
<superuser> 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

<superuser> or a textual warning that close-on idle may be less secure, if it'S really much work to change
<superuser> I count only 45
<superuser> I'm sorry for being such a nag

comment:9 Changed 7 years ago by str4d

Keywords: privacy anonymity added
Milestone: 0.9.13
Status: reopenedinfoneeded

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 7 years ago by user

Status: infoneededassigned

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 7 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.

Note: See TracTickets for help on using tickets.