Thanks for the response. Our understanding was that by using the "peek and splice" options, we could transparently filter https traffic using the SNI at the very least (though perhaps the issue lies with our external ACL?), without having to decrypt the SSL session or use MITM cert. Our results in testing, however, have been less than promising.
On Wed, Jun 24, 2015 at 12:41 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 25/06/2015 3:41 a.m., Tom Mowbray wrote:
> Squid 3.5.5
>
> I seem to have some confusion about how acl lists are processed in
> squid.conf regarding the handling of SSL (HTTPS) traffic, attempting to use
> ssl_bump directives with transparent proxy.
>
> Based on available documentation, I believe my squid.conf is correct,
> however it never seems to actually behave as expected.
>
> I define the SSL port, as usual:
>
> acl SSL_ports port 443
>
> But here's where my confusion lies... Many state to place the following
> line above the ssl_bump configuration lines:
>
> http_access allow SSL_ports
>
> However when I do this, it appears to simply stop processing any other
> rules and allows ALL https traffic through the proxy (which is actually how
> I'd expect a standard ACL list to operate, but then how do I actually
> filter the traffic though our content-based ACL lists?). If I put the
> above line below the ssl_bump configuration options in my squid.conf, then
> it appears to BUMP all, even though I've told the config to SPLICE all
> https traffic, which doesn't work for our deployment.
>
> So, does squid actually continue to process the https traffic using the
> ssl_bump rules if the "http_access allow SSL_ports" line is placed above it
> in the configuration?
The order for these only matter for lines of the same directive name.
The http_access set get tested on the initial CONNECT request, then the
ssl_bump on each of the bumping steps, then if bumping decrypts the
http_access is run on the decrypted request(s).
>
> I should note that we've been able to get filtering to work correctly when
> using our configuration in NON-transparent mode, however our goal is get
> this functionality working as a transparent proxy. We're unable to load
> our self-signed cert onto client machines that will be accessing the proxy,
> so using the "bump" or man-in-the-middle style https filtering isn't a
> viable option for us.
Then don't bother with any of this. You wont get transparent HTTPS
interception working without that MITM certificate install you already
ruled out.
Just use "ssl_bump none all" and Squid will relay the intercepted TCP
connections to the server they were destined for. Or better yet get rid
of the Squid step and let the traffic out on port 443 without slowing it
down for useless proxying.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
