> Thanks, > > .vp > > >>From: "Vadim Pushkin" <wiskbroom@xxxxxxxxxxx> >>To: sven.frommholz@xxxxxxxxxx > >>Hi Sven; >> >>I am unable to use: >> >>acl allowed-CONNECT dst 192.168.0.0/24 >> >>Well, I could, but then I would have to add one for each host and or >> subnet >>in my list, far too inefficient. Depends on how granular you want the subnets. /0 has perfect efficiency, /32 much less so. /15-/26 seems to be what most people prefer. >> >>>squid will not see URLs at all during SSL traffic, so url_regex will not >>>work. >> >>Yes, since it is in the URL, it *will* see this. In fact, it does and it >>works with url_regex right now. It NOT matching the URL/URI. Its matching the destination hostname as given by the client. In the config you gave any of your clients can trivially bypass your ACL by issuing "CONNECT https://dhcp-192-168-1-99.example.com:587/* HTTP/1.0" etc, to any rDNS name. (Which is a nasty but valid request to the TOR system, or an authenticated mailserver, or HTTPS server, or a custom protocol nones never heard of.) >> >>The problem that I am having is that I need to maintain a list, defined >>below, which can use either wildcards or something else that would allow >> me >>to state subnets. Using a wildcard for a subnet is exactly the same operation in a less-efficient manner than using CIDR. Which has already been recommended as the only way of identifying entire network segments/subnets in squid acl. To identify individual hosts you can in late 2.6 and 3.0 squid; - specify the FQDN of the host in src or dst ACL. That will resolve the host IPA on squid startup or reconfigure. - alternatively use a srcdomain ACL which will resolve the rDNS FQDN of the client and test on each request. For anything else you need to code your own external acl. Amos
