[squid-users] Questions Regarding Transparent Proxy, HTTPS, and ssl_bump

Tom Mowbray tmowbray at dalabs.com
Wed Jun 24 17:27:27 UTC 2015


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.


---------------------------------
Tom Mowbray
*tmowbray at dalabs.com* <tmowbray at dalabs.com>
*703-829-6694*

On Wed, Jun 24, 2015 at 12:41 PM, Amos Jeffries <squid3 at treenet.co.nz>
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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150624/9ea652d2/attachment-0001.html>


More information about the squid-users mailing list