#saltr (irc2p) | I2P+ 2.5.2+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

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

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

xeiaso i2p-projekt.i2p/_static/images/garliccloves.png

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__ paste.i2pd.xyz/?ce9d9528e099933e#D4HSRkuaHeohHp4HCcrejkwDNBUwBKctCunQqTbixFrz

xeiaso__ paste.i2pd.xyz/?70baf979539f346f#9yrRjNw11rnsWeCr9CmAMZFB7fqH5s7AhwHSFhAqntNP

xeiaso RN: well, you got your proof of concept

xeiaso paste.i2pd.xyz/?7709d282f9e92a84#4P2PpwQkw4KZurCWa1zymi1Tb5CxGzVXtiC7dXTMyiJX

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