[squid-users] Any plan for an SSL bump mode ACL?

[Amos Jeffries]

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
> ones.


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.

Amos