>>I don't understand, the use cases I'm suggesting are as "unsafe" as >>relying on ACLs with either client.ip or server.ip. > > With your suggestion, any traffic coming through a particular > listen address would be trusted, even if that traffic does not > have anything to do on that particular subnet.
That's the point of providing the mechanism. If you trust your network because you happen to have a trustworthy and competent team of network engineers, why turn a networking problem into an application problem? >>You have the same problem if anything matching one of your ACLs >>trusted address is compromised. > > There is a big difference between hijacking the IP of a server in > use, which is likely to trigger alarms, and being able to attack > using any IP going in through a particular interface. I don't see any difference between dealing with clunky VCL constructs and using a label to achieve the same. > Neither is watertight, but I don't see "convenience" as a valid argument > for increasing the sizes of the holes. The main goal is not *mere* convenience but actual decoupling between the application layer and the networking nitty gritty. On my dev box the "hitch" listen address might mean localhost:8888 while in production the hitch server may be on a different host in front of a Varnish cluster. With named listen addresses I can write my VCL policy once and not require changes between environments (dev, qa, prod...) instead of using platform-dependent server.ip. Dridi _______________________________________________ varnish-dev mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
