<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
On Thu, 2015-06-25 at 08:06 -0400, Tom Mowbray wrote:
<BLOCKQUOTE TYPE=CITE>
James,<BR>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
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>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
---------------------------------
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Tom Mowbray
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<I><A HREF="mailto:tmowbray@dalabs.com">tmowbray@dalabs.com</A></I>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<I>703-829-6694</I>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
On Wed, Jun 24, 2015 at 2:05 PM, James Lay <<A HREF="mailto:jlay@slave-tothe-box.net">jlay@slave-tothe-box.net</A>> wrote:<BR>
<BLOCKQUOTE>
On 2015-06-24 11:46 AM, Tom Mowbray wrote:<BR>
<BLOCKQUOTE>
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>
_tmowbray@dalabs.com_<BR>
_<A HREF="tel:703-829-6694">703-829-6694</A>_
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BLOCKQUOTE>
<BR>
<BR>
On Wed, Jun 24, 2015 at 1:31 PM, James Lay <<A HREF="mailto:jlay@slave-tothe-box.net">jlay@slave-tothe-box.net</A>><BR>
wrote:<BR>
<BR>
<BLOCKQUOTE>
On 2015-06-24 09:41 AM, Tom Mowbray wrote:<BR>
<BR>
<BLOCKQUOTE>
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>
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<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">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">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">172.230.156.79:443</A> HTTP/1.1" <A HREF="http://device-api.urbanairship.com">device-api.urbanairship.com</A> - 200 0 TAG_NONE:ORIGINAL_DST peek<BR>
<BR>
Hope that helps.<BR>
<BR>
<FONT COLOR="#888888">James</FONT>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BR>
Excellent!<BR>
<BR>
James
</BODY>
</HTML>