@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+RN_
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+wodencafe
Arch
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest19353
Irc2PGuest46029
Irc2PGuest64530
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
Teeed
aargh3
acetone_
anon4
b3t4f4c3
bak83_
boonst
cancername
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
mittwerk
not_bob_afk
plap
poriori_
profetikla
rapidash
shiver_
solidx66
u5657_1
uop23ip
w8rabbit
weko_
x74a6
eyedeekay
Wow that trip was brutal. On the ground in DE, back to work
dr|z3d
lederhosen pics or it didn't happen, eyedeekay
eyedeekay
Soon enough
dr|z3d
so I've got a very green method modification here to check if the requested URL via the SSL outproxy returns a 200 response code.
dr|z3d
the idea being we perform a head request on the requested url to verify that the selected proxy can see the requested host.
dr|z3d
if not, (todo) perhaps we should check against a known functional host to identify if the host is down/blocked, or the outproxy is down.
dr|z3d
the overarching idea is to attempt to minimize failed requests via outproxies. request failed? check known good host. known good host down? proxy is dead, cycle.
dr|z3d
grren code -> cake.i2p/view/79Cgqt3E14_C4ZdWpSM30jvuBPis9cHdKnetkrmxJ_xvVqzINXHw/79Cgqt3E14.txt
dr|z3d
both client and server side outproxy handling could use some love.
dr|z3d
yup, definitely some weird happening lately on the network. you seen all those X class Chinese routers?
dr|z3d
if we can determine that the proxy is down or that the site is unavailable, we can potentially display more informative proxy error messages to the user.
zzz
check the family on this one -aXAjMn70-Skoeb75UWbGzzYvxRxitJVUovQrv3VkpE=
dr|z3d
you haz groupies.
zzz
in china?
dr|z3d
they all love you over there. you're a celebrity. obviously. :)
dr|z3d
I see 2 routers in "your" family here.
dr|z3d
oA4f0RFH78WbqoT0vT3OlmOrlrAUEAwi-r0lGZblp5A= being the other.
zzz
seven MRs posted for consideration and cross-referenced on my roadmap page
zzz
more to follow
dr|z3d
did you have a look at my outproxy test code, zzz?
dr|z3d
snark bandwidth changes look interesting.
zzz
hate it :)
dr|z3d
what, your snark stuff, or my outproxy tester? :)
eyedeekay
Nice thanks zzz. I've never understood why publish a fake family key, especially ones that we ship a cert for?
dr|z3d
eyedeekay: not sure zzz has his own family. I think his family is i2p-dev?
dr|z3d
might be wrong.
eyedeekay
Dunno for sure, mine is mibhq, was added publicly, but if we have a cert and can say "this guy's a liar" aren't they footgunning themselves?
dr|z3d
sure, if there's a cert for a family and someone decides to spoof the family name, we can just mark the router as dubious (similar to how we do for validated) and add to the session blocklist.
eyedeekay
I just wonder what about it makes sense from the attacker side
eyedeekay
An ineffective disguise being worse than no disguise
dr|z3d
/** Get via getInstance() */
dr|z3d
private Analysis(RouterContext ctx, ClientAppManager mgr, String[] args) {
dr|z3d
super(ctx);
dr|z3d
_context = ctx;
dr|z3d
_log = ctx.logManager().getLog(Analysis.class);
dr|z3d
_cmgr = mgr;
dr|z3d
_persister = new PersistSybil(ctx);
dr|z3d
_familyExemptPoints24.add("SUNYSB");
dr|z3d
_familyExemptPoints24.add("stormycloud");
dr|z3d
}
dr|z3d
we could all just be coming to the wrong conclusion, and zzz family name isn't hostile at all.
dr|z3d
more a case of "maybe this will amuse someone".
eyedeekay
In between the two conclusions, I suppose, are decoys
eyedeekay
Maybe it's like the clone thing? Publish a real RI with a spoofed family key to get it banned?
dr|z3d
why would you want to get your own router banned?
eyedeekay
With the clone attack it was to get other routers banned
orignal
do we know if it's an attack or some idiots started something?
dr|z3d
we don't know anything, orignal :)
dr|z3d
it's all supposition and wild speculation right now.
orignal
well, what do you know so far?
orignal
beside number of trasit tunnels and bandwidth?
dr|z3d
we were talking about the zzz family in china, but regarding network performance.
dr|z3d
we know there are a ton of new X class chinese routers.
orignal
what's with it?
orignal
e.g. what is "zzz family"?
dr|z3d
we know the overall build success percentage has gone down in the last 24h or so.
dr|z3d
zzz family is a group of routers using the "zzz" name for their family.
orignal
my floodfill is banned by you guys as ususal
dr|z3d
chinese routers.
orignal
because too manu TBM comes from it
orignal
does zzz family cert exist?
eyedeekay
No it doesn't, I was mistaken abt that
orignal
well guys I told you from the beginning
dr|z3d
I think it's comedy more than anything else, the zzz family name.
orignal
about unregistered families
zzz
no I've never created a zzz family cert
orignal
i2pd doesn't honir unregistred families at all
orignal
like they don't exist
orignal
then implement it the same way as i2pd
dr|z3d
you were talking about hating it, zzz.. my outproxy testing code, or your snark b/w code?
orignal
if no family cert just ignore it
zzz
your testing code
orignal
if family signature mistmach with cert drop it
orignal
whole RI
orignal
that's how I do
zzz
wrong place, unnecessary, borked
orignal
hold on
zzz
eyedeekay, how goes the bundle?
orignal
so you are saying that zzz cert comes from I2P+ test code?
dr|z3d
maybe 1 and 3 you're right about, 2, I disagree, if we want a more robust outproxy solution.
zzz
no sorry orignal two conversations at once
dr|z3d
orignal: I never said that.
zzz
dr|z3d, how does it improve on the existing failure-tracking code?
orignal
just confused
dr|z3d
zzz: the intention is to check the url, and then check a known url, so you can determine if the outproxy is down or the requested URL is wrong or being blocked.
eyedeekay
Travel and holidays ended up crapping up my schedule pretty hard, finally got back to it this morning, Mozilla has my plugins, that usually only takes a few hours, arkenfox is updated in i2p.plugins.firefox, so once I get my emails from Mozilla I can push the button and have my build artifacts, after that it's a news update away
zzz
ok great eyedeekay
zzz
eyedeekay, if you want me to tweet this week about 'come meet us here' or 'we're wearing this hideous shirt, look for us' holler
zzz
eyedeekay, why does mozilla need a plugin before you release the bundle? doesn't the bundle have everything in it?
eyedeekay
Yeah sounds good, I've got my IPFS shirt, my Crypto-Privacy Village shirt, and a black t-shirt with 2 skeletons on it, one of which is holding the other's spine and telling his homie "I've got your back"
eyedeekay
I need to have Mozilla sign the plugin because the plugin signing cert for all Firefox plugins is under the control of Mozilla unless we want to fork Firefox
zzz
eyedeekay, yeah but I would need what's on your back at the time, not an inventory of your luggage :)
eyedeekay
Since we(especially me) don't want to fork Firefox I have to ask Mozilla to sign the plugins before I can include them
zzz
ok got it, didn't know
eyedeekay
Yeah that's the trade-off, it's why we can use vanilla Firefox instead of having to do a TBB-alike
zzz
sounds right
dr|z3d
y'all need silly hats.
dr|z3d
"we're wearing 3 ft tall wizard hats with attached bells"
eyedeekay
That would work lol
zzz
dr|z3d, but we have tracking if the outproxy is down now
zzz
and your code does not do any test of the 'requested URL'
dr|z3d
sure, like I said, the known good url code is to come, that was a first stab at getting the eephead stuff in there.
dr|z3d
it's more "here's the basic concept" that "here's the finished article".
dr|z3d
*than
dr|z3d
the other part of the handling that isn't there yet is an optional prioritization of outproxies, so first choice gets used first unless it's down, etc..
zzz
there's ancient problems with the way we do CONNECT but I'm not sure it's fixable.
zzz
and I'm not sure we can do anything to get better errors to the browser anyway, I don't think they care
zzz
but I do have a line item on my roadmap to investigate
dr|z3d
if we're doing a head request first, we can handle errors instead of the browser, that's the basic thinking.
dr|z3d
and at the same time inform the user that we're trying the next outproxy (if configured).
zzz
but you can't get errors to the browser
dr|z3d
we can, and we do.. proxy errors via proxy.i2p
zzz
doesn't work for CONNECT because it's TLS
zzz
all you have is the '200 Connection Established' line
zzz
which we send unconditionally from the client side, that's the ancient problem
zzz
but I don't know if we got more creative if the browser would do anything with it
zzz
on the server side we need to just reset the socket instead of sending errors
zzz
which will prevent the 'record too long' browser errors when we send non-TLS responses
zzz
thats whats on my list
dr|z3d
if we don't get a 200 response code via the head request, then we can handle that with a proxy error, no? that's part of the thinking behind using a head check.
zzz
no, the browser is looking for a TLS handshake, not a plaintext error page
zzz
and it won't display it, it just pukes out record too long
zzz
if you can make it do it, lmk, but I don't think so
dr|z3d
ok, something to look into further. I was assuming we either get a 200 back from a head check, or we don't. if we don't, then we can handle that appropriately.
zzz
this is all independent of any additional checks, this is the status quo
dr|z3d
ok, so you're talking about how we currently do things? I'm proposing a head pre-check that gives us extra options.
zzz
I'm saying that there's no facility to get error pages to the browser for CONNECT
zzz
adding "pre checks" doesn't solve that
dr|z3d
ok, more work/research to do.