IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/05/17
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83
+cancername
+cumlord
+hk
+poriori
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest15271
Irc2PGuest28511
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over
acetone_
anon4
anu3
boonst
mareki2pb
not_bob
plap
shiver_1
simprelay
solidx66
thetia
u5657
weko_
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.
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