<div dir="ltr"><div>James,<br><br></div>Thank for for your help.  Now that I have a better understanding of how the https traffic is handled, I've been able to get things working as intended.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div><br></div><div>---------------------------------</div>Tom Mowbray<div><a href="mailto:tmowbray@dalabs.com" target="_blank"><i>tmowbray@dalabs.com</i></a></div><div><i>703-829-6694</i></div></div></div>
<br><div class="gmail_quote">On Wed, Jun 24, 2015 at 2:05 PM, James Lay <span dir="ltr"><<a href="mailto:jlay@slave-tothe-box.net" target="_blank">jlay@slave-tothe-box.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-06-24 11:46 AM, Tom Mowbray wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
James,<br>
<br>
Yes, as a matter of fact I have read through those exact posts and<br>
modeled my config very similarly.  What I have found is that, however,<br>
when the line "http_access allow SSL_ports" is placed above the<br>
ssl_bump stuff and other acl's (as you have it), it seems to simply<br>
allow ALL https without doing any filtering whatsoever.<br>
<br>
Thanks for the response.<br>
<br>
---------------------------------Tom Mowbray<br></span>
_tmowbray@dalabs.com_<br>
_<a href="tel:703-829-6694" value="+17038296694" target="_blank">703-829-6694</a>_<div><div class="h5"><br>
<br>
On Wed, Jun 24, 2015 at 1:31 PM, James Lay <<a href="mailto:jlay@slave-tothe-box.net" target="_blank">jlay@slave-tothe-box.net</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2015-06-24 09:41 AM, Tom Mowbray wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Squid 3.5.5<br>
<br>
I seem to have some confusion about how acl lists are processed<br>
in<br>
squid.conf regarding the handling of SSL (HTTPS) traffic,<br>
attempting<br>
to use ssl_bump directives with transparent proxy.<br>
<br>
Based on available documentation, I believe my squid.conf is<br>
correct,<br>
however it never seems to actually behave as expected.<br>
<br>
I define the SSL port, as usual:<br>
<br>
acl SSL_ports port 443<br>
<br>
But here's where my confusion lies... Many state to place the<br>
following line above the ssl_bump configuration lines:<br>
<br>
http_access allow SSL_ports<br>
<br>
However when I do this, it appears to simply stop processing any<br>
other<br>
rules and allows ALL https traffic through the proxy (which is<br>
actually how I'd expect a standard ACL list to operate, but then<br>
how<br>
do I actually filter the traffic though our content-based ACL<br>
lists?).<br>
If I put the above line below the ssl_bump configuration options<br>
in<br>
my squid.conf, then it appears to BUMP all, even though I've told<br>
the<br>
config to SPLICE all https traffic, which doesn't work for our<br>
deployment.<br>
<br>
So, does squid actually continue to process the https traffic<br>
using<br>
the ssl_bump rules if the "http_access allow SSL_ports" line is<br>
placed<br>
above it in the configuration?<br>
<br>
I should note that we've been able to get filtering to work<br>
correctly<br>
when using our configuration in NON-transparent mode, however our<br>
goal<br>
is get this functionality working as a transparent proxy. We're<br>
unable to load our self-signed cert onto client machines that<br>
will be<br>
accessing the proxy, so using the "bump" or man-in-the-middle<br>
style<br>
https filtering isn't a viable option for us.<br>
<br>
Any help or advice is appreciated!<br>
<br>
Thanks,<br>
<br>
Tom<br>
</blockquote>
<br>
Tom,<br>
<br>
You kinda have to change the way you think about filtering when it<br>
comes to Squid 3.5.5 and SSL(TLS). Normal http traffic is<br>
easy....here's where we're trying to go and here's a list of place<br>
we're alloed to go...simple.<br>
<br>
Not so with SSL(TLS). Squid can't filter, since Squid may or may<br>
not know where we're going...and that's the issue..it's where those<br>
ssl_bump atStep ACL's come in. Some sites when you connect to them<br>
are easy-ish..when you connect your device sends a "Server Name<br>
Information" (SNI) that says where you're going. Other sites don't<br>
have any information until you complete the SSL handshake (how can<br>
you filter a site name, until squid KNOWS the site or at least<br>
domain name?).<br>
<br>
If you're still wanting to go through with transparent (intercept)<br>
proxy with SSL, search through the list for my SSL Deep dive<br>
posts...that config is working for me so far (granted, not in an<br>
enterprise environment). However, as Amos said,....if you choose<br>
not to install the cert on the client machines, you are either a)<br>
going to be out of luck on LOT'S of websites because they will fail<br>
the SSL handshake, or b) teaching your users to ignore the security<br>
warnings of their browser's....neither of which is a good thing.<br>
<br>
Hope that helps.<br>
<br>
James<br>
<br>
</blockquote></div></div></blockquote>
<br>
Tom,<br>
<br>
You are right...that absolutely will allow all SSL initially...the filtering is down lower in the config here:<br>
<br>
With single list of regex sites/domains like \.google\.com...peek, splice, no bump...I'm currently using this config section.<br>
############################################################################<br>
ssl_bump peek step1 all<br>
ssl_bump peek step2 all<br>
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"<br>
ssl_bump splice step3 allowed_https_sites<br>
ssl_bump terminate all<br>
<br>
<br>
With broken acl list of networks list <a href="http://208.85.40.0/21" rel="noreferrer" target="_blank">208.85.40.0/21</a><br>
###########################################################################<br>
ssl_bump peek step1 broken<br>
ssl_bump peek step2 broken<br>
ssl_bump splice broken<br>
ssl_bump peek step1 all<br>
ssl_bump peek step2 all<br>
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"<br>
ssl_bump bump allowed_https_sites<br>
ssl_bump terminate all<br>
<br>
In both configs above, the SNI and server names are checked, bounced off the http_url.txt list, and if the site/domain is NOT in the list the ssl session is terminated.  The big drag is, you won't be able to see that in the squid logs.  I have a bug open ( I don't remember the number :( ) to show this in the logs...so far in my setup I only see the first peek, nothing after that.  You can test the above setups with:<br>
<br>
openssl s_client -connect x.x.x.x:443<br>
<br>
The above will test with no SNI...these look like the below in the logs:<br>
Jun 24 11:35:08 gateway (squid-1): 192.168.1.101 - - [24/Jun/2015:11:35:08 -0600] "CONNECT <a href="http://31.13.76.101:443" rel="noreferrer" target="_blank">31.13.76.101:443</a> HTTP/1.1" - - 200 0 TAG_NONE:ORIGINAL_DST peek<br>
<br>
wget -d --ca-certificate=<your.cert.file)<br>
<br>
The above WILL send an SNI...which you should see in your logs as:<br>
Jun 24 12:01:44 gateway (squid-1): 192.168.1.101 - - [24/Jun/2015:12:01:44 -0600] "CONNECT <a href="http://172.230.156.79:443" rel="noreferrer" target="_blank">172.230.156.79:443</a> HTTP/1.1" <a href="http://device-api.urbanairship.com" rel="noreferrer" target="_blank">device-api.urbanairship.com</a> - 200 0 TAG_NONE:ORIGINAL_DST peek<br>
<br>
Hope that helps.<span class="HOEnZb"><font color="#888888"><br>
<br>
James<br>
</font></span></blockquote></div><br></div>