[squid-users] Any plan for an SSL bump mode ACL?
squid3 at treenet.co.nz
Fri Aug 28 11:08:46 UTC 2015
On 28/08/2015 5:27 p.m., Dan Charlesworth wrote:
> I’m trying to figure out if there’s a way to avoid those 0 byte
> “peeked” requests being processed by the rest of our external ACLs
> etc. by allowing them early on in the transaction.
> Unfortunately there doesn’t seem to be a way to target just those
> ones with http_access—the TAG_NONE isn’t an actual method and and
> there’s no ACL for the bump mode—without also targeting the spliced
If your helpers logic cant handle CONNECT method requests then you
should be using the default configs CONNECT acl definition to skip them.
The synthetic ones are just what regular explicit-proxy HTTP would
actually have at that point had HTTP been the used properly instead of
interception or SSL-Bump.
For intercepted port 443 traffic the synthetic/fake CONNECT requests
should match something like this:
acl portA myportname the-https_port-name
acl hasUA req_header User-Agent .+
acl syntheticCONNECT all-of portA CONNECT hasUA
http_access allow syntheticCONNECT
I have not tested this. All the synthetic CONNECT used by squid are
generated the same right now, and can be emulated by a client.
So you should use with care with teh above. And definitely try to avoid
eliding logs in case one comes from outside that matches.
I plan to have the squid User-Agent string added in there when it more
convenient. So the above will not work long-term. And a Forwarded header
with something to indicate intercept is also an eventual possibility.
More information about the squid-users