On 06/18/2015 04:37 AM, Florent Daigniere wrote: > On Wed, 2015-06-17 at 16:40 +0200, xor wrote: >> On Wednesday, June 17, 2015 09:49:57 AM Steve Dougherty wrote: >>> Any thoughts on removing (in 1469 or later - scope creep bad!) >>> fproxy.allowedHosts? Not to be confused with >>> fproxy.allowedHostsFullAccess, this is a list of IPs / netmasks outside >>> of which FProxy closes the connection immediately after accepting it. [0] >>> >>> Why does the functionality exist? >> >> I would guess that its necessary for public gateway mode. Gateway users >> shouldn't have full access. >> >> It also might help people to share Freenet with their roommates on the LAN.
Sure, but this could happen without fproxy.allowedHosts. Any connection let through the firewall and not in allowedHostsFullAccess is given partial access. >>> This seems like a confusing way to >>> poorly reimplement a firewall's job. Unlike fullAccessHosts which will >>> respond with a 403, the user gets no feedback. >>> >>> The motivation for this is twofold - if a feature is useless it should >>> probably be removed, and it cost jeffpc and I two hours to figure out >>> why FProxy was immediately closing connections when he had added 0.0.0.0 >>> intending it to mean all addresses. >> >> You don't need to remove the feature since the problem IMHO was not the >> existence of the feature but this: >> There was no error message. >> >> As you've noticed, the code to fix the lack of an error message already >> exists: allowedHostsFullAccess is able to deliver 403. >> So fix the other one to show 403 as well :) I think it would be clearer to refuse the connection outright than the current behavior of accept() and immediately close() it. > There's a reason why it's like that: security. > Right now the connection is "tcpwrapped": if a host is not on the > allowedHosts list, the connections gets closed before accept() > happens... protecting it from any potential bug we might have with > toadlets. You mentioned on IRC that there is a semantic difference between allowedHosts and allowedHostsFullAccess. I do understand the utility of partial access and do not intend to remove that use case. My confusion comes when it seems like allowedHosts does not provide functionality when combined with allowedHostsFullAccess that could not also be provided by a firewall. Is there a use case I'm not thinking of that can be achieved with allowedHosts but not a firewall? If I'm reading the code [0] correctly it actually does accept() the connection before refusing it for being outside of allowedHosts. > Some might say that this is paranoid; to them I'd reply that: > - it's how it works historically on unix (see *inetd) > - they're unlikely to have re-invented their own HTTPd... we have. > > Last time we've discussed it the consensus was that what needed to > change is the configuration toadlet, not the functionality. Maybe we > should have another wizard for "I want to share my fproxy instance" I'd be on board with documenting changing the default bindTo interfaces along with firewall and allowedHostsFullAccess configuration - a guide for setting up a gateway. > It's true that there are many settings: > > fproxy.bindTo > fproxy.allowedHosts > fproxy.allowedHostsFullAccess > fproxy.publicGatewayMode > > > I see three solutions: > > 1) change fproxy.allowedHosts to be the union of fproxy.allowedHosts and > fproxy.allowedHostsFullAccess (easy to do, would solve this particular > bug) > 2) configuration helper (new wizard) > 3) do what the RFC suggests and get rid of (IMO useful) functionality... > > NextGen$ [0] https://github.com/freenet/fred/blob/205979a250f6664aeb9f0b12c4bde49691bc5e64/src/freenet/io/NetworkInterface.java#L389
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
