~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Leopold
+Xeha
+acetone
+bak83
+cancername
+cumlord
+hk
+profetikla
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest43426
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over
T3s|4_
anon2
anu3
boonst
mareki2pb
not_bob_afk
plap
poriori_
shiver_
simprelay
solidx66
thetia
tr
u5657
xeiaso_
eyedeekay: does later this week mean Wednesday/Thursday/Friday or the weekend
RN
Xei(TABFAIL) it seems you will find out later.
xeiaso
RN: ah but I want to poke holes in the fixes when they are inevitably found to be insufficient.
xeiaso
and saying it'll be fixed later increases the time a poke-fix cycle will take
RN
you are just a bundle of positivit, aren't you?
xeiaso
imagine playing tennis but the ball takes weeks to return
RN
*positivity
xeiaso
tennis is a fun and positive game
RN
if you have proof of concept code, maybe you could pm it to him
RN
if he and the others don't find an issue then it surely won't escalate the release cycle
RN
that's why resposible disclosure is a thing
RN
or you could pm it to me and once I decide it doesn't risk my anonymity to run it and I see working proof that there is an issue then I'd get everyone needed to fix it's attention.
xeiaso
> doesn't risk my anonymity < are you going to read thousands of lines of code?
RN
does your proof of concept take that many lines?
RN
from what you described, it could be done with a custom tunnel and a short script
xeiaso
a hypothetical PoC itself shouldn't be that long, but I do stuff from scratch
RN
and by definition, a proof of concept is not hypothetical
RN
if you were serious and not just trying to stir up drama, I'd have expected a pm from you by now with the code an eepsite serving a directory the needed files
RN
os such
RN
or such
RN
s/code/code or/
RN
&& s/the nee/with the nee/
xeiaso
learning of a successful deanon suddenly is much more dramatic then having a heads-up
RN
pardon my sloppy typing, on a new keyboard
xeiaso
say RN you run a Java I2P router right?
RN
you claim it is successful, but where is the proof?
RN
some of my routers are java yes.
RN
and?
xeiaso
you thought it would only take 20 minutes?
xeiaso
I have not touched my codebase since February. Have some empathy!
RN
ok. maybe not empathy that always gets me in trouble. but you have one more beer's worth of time... Σ:Đ
RN
while your code is trying... can I ask if your nick means something?
xeiaso
hey you did the major thing
xeiaso
three dots again...
RN
that... does not always work
xeiaso
it seems to only work if you don't intend for major to echo you
RN
so it reads intention... or what?
RN
while your code is trying... can I ask if your nick means something?
RN
hmm... disproved
xeiaso
why do you ask?
RN
so about your nick? is there an etymology?
RN
it is something I ask people with interesting nick names
RN
mine has a short story
RN
no answer?
xeiaso
I'm mostly working on things
RN
for the reccord, I didn't consent to being tested.
xeiaso
don't worry, I'll test in on an eepsite that's not anonymous.
RN
are you runnining the test yet?
RN
are you runnining the test yet? ◀━━ I guess it takes time to set up... or I pissed xeiaso off and am being ignored... ;)
xeiaso
the former
RN
:)
RN
I'm curious how you chose a site you felt would not mind
xeiaso
I looked for a eepsite with a clearnet site that hosts an i2p router.
RN
ok
xeiaso
I'm hoping they host the i2p destination on that router
xeiaso
I hope I don't have to set up a Java router myself.
RN
what?
RN
you mean I could make a tunnel to a tunnel on another router to a tunnel on another router to my eepsite?
xeiaso
I'm not sure what you mean by that
xeiaso
I'm not sure what you mean by that
RN
I'd imagine that'd make a lot of extra lag
RN
but in theory... I think it should work
RN
interesting. thanks for the idea
RN
lag would be really noticable on a static site
RN
er... I messed that up
RN
s/sta/non sta/
xeiaso
oh you mean bouncing traffic off a destination
mesh
RN: why do you think that would work
RN
as in inside I2P tunnels
mesh
you can't point a tunnel to a tunnel I don't think
xeiaso
yeah it should work
RN
pairs
RN
this is what I mean
mesh
Blinded message
mesh
you point a tunnel to a Destination
RN
on router A I serve the public site (b32, b64, etc)
xeiaso
but there are better ways to make longer tunnels
RN
but router A get's the http responsed from router C
RN
*responses
mesh
RN: ...again I don't think that's how it works
RN
router C obv relays and maybe filters
mesh
in fact the entire model is confused the java router does everything
xeiaso
it does
RN
with the right client and server tunnels on A B and C I think it might work
xeiaso
mesh: it makes sense if you consider the historical context
mesh
RN: routers don't "host" sites. A local i2cp client connects to a Router and creates/subscribes a Destination. Any traffic that the Router receives for that Destination will be routed to that local client. That's what routers do -- they route traffic
RN
router B obv relays and maybe filters
mesh
what happens inside the local i2cp client process that subscribed to that Destination is completely arbitrary. It could respond with a http response or it could forward traffic to another Destination. It's completely arbitrary
mesh
but even if you did create a special 'Http Mirror' router client that forwarded all http traffic it receives to another Destination the result would **not** be a longer tunnel
mesh
it would be two tunnels. One tunnel from the client to the mirror destination. And another tunnel from the mirror to the actual http service
RN
typo
RN
kinda like ssh A to B to C
mesh
why you would do this though is unknown. Unless you're insane like the joker and just like to do crazy shit
RN
mesh, on A I run an eepserver tunnel for http, that points to a local port running a webserver (jetty or other)
RN
so if instead that port on A is a ssh forwarded port from B through an I2P tunnel
xeiaso
mesh: traffic amplification
mesh
RN: that might work but again you're not getting one long tunnel, you're getting two tunnels, where the Destination at the end of the first tunnel is deliberately forwarding traffic on to some other Destination
xeiaso
nothing in the image I linked says that it has to be alice's inbound tunnel
RN
are you saying the return path would be C to A to i2puser?
mesh
RN: I'm saying in that scenario, where http traffic is received at one Destination, and then forwarded to another tunnel using I2P Tunnel... you have two destinations an two tunnels
RN
I2P user is connecting to A's 'eepsite'
mesh
there's little practical advantage to such a scheme
xeiaso
mesh: impractical does not mean impossible
mesh
RN: again there is no requirement that an eepsite run on the same machine as the router
mesh
it is possible to create an server tunnel that receives HTTP traffic from i2p and forwards it to a clearnet website running on a different machine
RN
right.... so in theory it would work. Not sure if there would be a lot of gains
RN
I think the extra lag would outweigh that
mesh
when you create a Server Tunnel you're prompted for the ip address of the service:
mesh
This is the IP that your service is running on, this is usually on the same machine so 127.0.0.1 is autofilled.
RN
right
RN
but if on 127.0.0.1 I point it instead of to jetty or another webserver, I point it to a port that is not local and reached by I2P
mesh
RN: that is impossible
mesh
at least the java router doesn't do that... yet
RN
but it appears local because of an ssh forward session
RN
through that it reaches B and eventually C
mesh
when you create a server tunnel you must point it at a clearnet ip:port, not another I2P DEstination
RN
no
RN
I point it at localhost:ssh-forwarded-through-i2p-port
RN
and that connects to the next in the chain
RN
by b32 or b64
mesh
RN: again that's not a thing
xeiaso
mesh: no, but it would be funny if it was.
mesh
RN: you can point it to a localhost port. That localhost port is a clearnet service
RN
test#1 with only 2 routers
RN
A has connect tunnel that is sshfw to B (ssh client tunnel on A, ssh server tunnel on B)
mesh
you could write a clearnet service that listens on a port and forwards to a remote Destination. That's called a "Client Tunnel"
mesh
RN: all you're doing is creating two tunnels. And there will be a clearnet hop in there. That's unavoidable.
RN
the ssh connection to B is to B's port 7658
RN
(I think 127.0.0.1:7658 is default eepsite if running)
RN
rather A requests ssh through the tunnel to B
RN
and forwards 7658 on B to 76582 on A
RN
then A's eepsite tunnel points to port 76582 and the site is not directly connected
mesh
(when I say clearnet I mean "not i2p")
RN
A and B don't need to know each other's clearnet IP
RN
increases plausible deniablity
RN
if the compromise of one of them triggers shutdown of connections on the other
mesh
RN: yeah. there's a great tool you can use called i2p that does the same thing. just have clients connect directly to B over i2p
mesh
and they won't know B's clearnet ip either
RN
right, but if I run A and LEA sieze A
mesh
going through A first really doesn't buy you much. clients may not know B exists
mesh
RN: ...
RN
A does not connect me to where the site runs from. if they sieze B it does not connect the site to me
RN
if things sever quickly enough when a deadman switch is triggered
RN
mesh, yeah?
RN
<mesh> RN: you can point it to a localhost port. That localhost port is a clearnet service ◀━━ not if what is running on that local port only listens on the local machine and firewalls are right
mesh
RN: the same is true without the nonsense traffic forwarding
mesh
RN: the only benefit of your scheme is if you thought the Destination b32 Address was going to change often and you wanted to give cleints a stable address
mesh
in that case you can use HTTP Redirects
mesh
RN: well no, the idea is when clients connect to A, A redirects them to B
mesh
and then clients connect directly to B
mesh
RN: the localost port is not an i2p service. There is a program (i2ptunnel or whatever) that is receiving traffic from I2P Destination and then creating a *new* I2P Tunnel to the second Destination
RN
with just two routers, user would request site from A, A would get content from B
RN
A would send back content from A's B64
RN
so user would be unaware of B or even C existing
mesh
it's not like they know that A exists
mesh
all they know is A's I2P Destination
RN
right
mesh
but an I2P Destination is just a set of keys
RN
so I was on a higer level of abstraction I think
RN
not explaining clearly
mesh
you're not gaining anything by "hiding" B's I2P Destination
mesh
at the end of the day users have no idea where A or B exists
RN
think of piratebay... you take down one A, but you don't find B
xeiaso_
mesh: unless...
RN
another A shows up
RN
site is still there
mesh
this is the way i2p's address book should probably work
mesh
a simple HTTP redirect
eyedeekay
xeiaso I have little doubt that you will receive a an affirmative test result in the scenario you described. Fortunately it is also extremely easy to prevent from ever happening altogether. However, even with an affirmative test result it doesn't actually prove what you need it to prove for a deanon. I will explain why in detail before Saturday. Please don't die of impatience before I do.
xeiaso_
eyedeekay: give me a number. any two digit number.
eyedeekay
42
xeiaso__
:)
RN
xeiaso__, did you just get a hard-on?
RN_
your tail just got longer... just saying...
xeiaso__
eyedeekay: do you see a difference between these two logs?
xeiaso
RN: well, you got your proof of concept
mesh
man that's weird
mesh
what is that.. a clearnet i2p forwarder pastebin?
eyedeekay
xeiaso yes I see the difference and as I said, I expected you to get an affirmative result in your test. FWIW I agree the replay handling should be different, so does everyone. As I also said the fix is extremely easy, and the affirmative result doesn't actually mean a successful deanon. I am not going to push the code to git ahead of schedule at 4:30 AM.
xeiaso
how exactly is this not deanon? we have seen difference in the behaviour of a router based on if it hosts a certain destination
xeiaso
we have gone from knowing destination + netdb -> a router
eyedeekay
I said I would explain by Friday and I will.
xeiaso
I expect cop-outs