~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_afk
plap
shiver_1
simprelay
solidx66
thetia
u5657
weko_
dr|z3d
looking at httpserver, zzz, I'm still thinking it's not a bad idea to block any attempts to access a localhost address.
dr|z3d
this is what I've got so far:
dr|z3d
try {
dr|z3d
URL parsedURL = new URL(url);
dr|z3d
InetAddress address = InetAddress.getByName(parsedURL.getHost());
dr|z3d
if (address.equals(InetAddress.getLocalHost()) || address.getHostAddress().equals("127.0.0.1")) {
dr|z3d
// Prevent access to localhost addresses
dr|z3d
if (_log.shouldWarn())
dr|z3d
_log.warn("[HTTPServer] Denying access to localhost address [" + url + "]");
dr|z3d
return;
dr|z3d
}
dr|z3d
} catch (MalformedURLException e) {
dr|z3d
// Handle malformed URL
dr|z3d
e.printStackTrace();
dr|z3d
return;
dr|z3d
} catch (UnknownHostException e) {
dr|z3d
// Handle unknown host
dr|z3d
e.printStackTrace();
dr|z3d
return;
dr|z3d
}
zzz
I suggest you test to try to break it before writing code to fix it
zzz
you may also be introducing security issues through DNS leaks via getByName()
dr|z3d
we've already demonstrated that it can be broken.
dr|z3d
for some definition of broken, anyways.
dr|z3d
if there's a method that doesn't require a dns lookup, that would be preferable.
dr|z3d
that said, I think you're overstating the issue of security. you run an outproxy, let's say, someone attempts to access *any* address, there's a DNS lookup involved.
zzz
sure but for the non-outproxy case
dr|z3d
so we just make sure the url doesn't contain .i2p before we do the lookup.
zzz
where does this code go?
dr|z3d
I2PTunnelHTTPServer
zzz
specifically where. There's no 'url' in there in canon
dr|z3d
I've got it in the run() method right now, haven't determined if that's the right place yet.
dr|z3d
url is grabbed via:
dr|z3d
// Parse request headers here to extract URL
dr|z3d
String[] requestLines = _headers.split("\r\n");
dr|z3d
String requestLine = requestLines[0];
dr|z3d
String[] requestParts = requestLine.split(" ");
dr|z3d
String url = requestParts[1];
zzz
there is no full-blown URL. The path is in the GET line and the host is set in the Host: header with the spoofed host
zzz
the Host: line from the client is stripped
zzz
so again, what's the definition of broken
dr|z3d
the definition of broken is fbi.com:{arbitary port} via the outproxy exposing {arbitrary port} on localhost.
dr|z3d
I really think we shouldn't let that happen in any context.
zzz
pretty sure we tested that before we approved the outproxy.
dr|z3d
yeah, we did, and we fixed the issue but I'm not happy with the fix.
zzz
that's for you to prevent at the outproxy, external to httpserver
dr|z3d
that's what you said, but I'm not happy with that. we should be preventing that from happening regardless of how the proxy server is configured.
zzz
but you can't inject security issues for everybody else except the outproxy just because you're not happy
dr|z3d
that's not the right way of looking at things. non-issue. we'd just add a toggle to the http server config that enables outproxy mode.
zzz
there is no 'outproxy mode'.
dr|z3d
right, that's why we'd need to add a toggle :)
dr|z3d
either that or add a new tunnel type explicitly for outproxies that allows more fine-grained control.
zzz
I know nothing about the outproxy architecture or why you're unhappy, but it sounds like this is better and more securely fixed outside the i2p code
zzz
if you do want to add special outproxy shenanigans into the i2p code, I suggest you do it in a fork so you don't add security holes for your other users
dr|z3d
not convinced by either of those suggestions, tbh. you're not going to be looking up DNS requests if your server tunnel is hosting an .i2p site, and we can filter those out in any event. and providing a secure method for hosting an outproxy that mitigates possible issues regardless of the proxy software being used seems to me to be something we should be doing, being as we're security focused.
dr|z3d
and a toggle in the UI that enables outproxy mode addresses any security issues. if your http server tunnel isn't an outproxy, then any code relating to outproxy functionality doesn't get enabled.
zzz
seems like a lot of work if the fbi.gov fix from a year ago is still working, happy or not
dr|z3d
maybe, but I think it's worth the effort. we should be able to provide a watertight outproxy tunnel config that doesn't rely on configuring the proxy server where there may be non-obvious issues. prevent gun->foot issues.
dr|z3d
block localhost, enable a whitelist/backlist for hosts, enable auto-ban for clients attempting to access prohibited sites, that sort of thing.
dr|z3d
custom dns server config, multiple backend server config... I know you'll say that's not the job of i2p, but I think having all these things within i2p would make running an outproxy much more viable.
dr|z3d
that's on the server side of things, on the client side, there's various things we could do to improve things.
dr|z3d
*poof*
zzz
look, it's up to you and StormyCloud to holistically design and maintain a secure outproxy. You don't have to convince me; nobody's running a canon outproxy and so I'm not interested in adding 'outproxy mode' attempting to guess what a non-existent outproxy op might want
dr|z3d
ok, fine.
zzz
ofc, checking for localhost alone wouldn't allow you to remove external defenses for other outproxy IPv4/v6 IPs or hostnames
dr|z3d
nope, but it's a start.