James,
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.
---------------------------------
Tom Mowbray
tmowbray@xxxxxxxxxx
703-829-6694
On Wed, Jun 24, 2015 at 2:05 PM, James Lay <jlay@xxxxxxxxxxxxxxxxxxx> wrote:
On 2015-06-24 11:46 AM, Tom Mowbray wrote:
James,
Yes, as a matter of fact I have read through those exact posts and
modeled my config very similarly. What I have found is that, however,
when the line "http_access allow SSL_ports" is placed above the
ssl_bump stuff and other acl's (as you have it), it seems to simply
allow ALL https without doing any filtering whatsoever.
Thanks for the response.
---------------------------------Tom Mowbray
_tmowbray@dalabs.com_
_703-829-6694_
On Wed, Jun 24, 2015 at 1:31 PM, James Lay <jlay@xxxxxxxxxxxxxxxxxxx>
wrote:
On 2015-06-24 09:41 AM, 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?
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.
Any help or advice is appreciated!
Thanks,
Tom
Tom,
You kinda have to change the way you think about filtering when it
comes to Squid 3.5.5 and SSL(TLS). Normal http traffic is
easy....here's where we're trying to go and here's a list of place
we're alloed to go...simple.
Not so with SSL(TLS). Squid can't filter, since Squid may or may
not know where we're going...and that's the issue..it's where those
ssl_bump atStep ACL's come in. Some sites when you connect to them
are easy-ish..when you connect your device sends a "Server Name
Information" (SNI) that says where you're going. Other sites don't
have any information until you complete the SSL handshake (how can
you filter a site name, until squid KNOWS the site or at least
domain name?).
If you're still wanting to go through with transparent (intercept)
proxy with SSL, search through the list for my SSL Deep dive
posts...that config is working for me so far (granted, not in an
enterprise environment). However, as Amos said,....if you choose
not to install the cert on the client machines, you are either a)
going to be out of luck on LOT'S of websites because they will fail
the SSL handshake, or b) teaching your users to ignore the security
warnings of their browser's....neither of which is a good thing.
Hope that helps.
James
Tom,
You are right...that absolutely will allow all SSL initially...the filtering is down lower in the config here:
With single list of regex sites/domains like \.google\.com...peek, splice, no bump...I'm currently using this config section.
############################################################################
ssl_bump peek step1 all
ssl_bump peek step2 all
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump splice step3 allowed_https_sites
ssl_bump terminate all
With broken acl list of networks list 208.85.40.0/21
###########################################################################
ssl_bump peek step1 broken
ssl_bump peek step2 broken
ssl_bump splice broken
ssl_bump peek step1 all
ssl_bump peek step2 all
acl allowed_https_sites ssl::server_name_regex "/opt/etc/squid/http_url.txt"
ssl_bump bump allowed_https_sites
ssl_bump terminate all
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:
openssl s_client -connect x.x.x.x:443
The above will test with no SNI...these look like the below in the logs:
Jun 24 11:35:08 gateway (squid-1): 192.168.1.101 - - [24/Jun/2015:11:35:08 -0600] "CONNECT 31.13.76.101:443 HTTP/1.1" - - 200 0 TAG_NONE:ORIGINAL_DST peek
wget -d --ca-certificate=<your.cert.file)
The above WILL send an SNI...which you should see in your logs as:
Jun 24 12:01:44 gateway (squid-1): 192.168.1.101 - - [24/Jun/2015:12:01:44 -0600] "CONNECT 172.230.156.79:443 HTTP/1.1" device-api.urbanairship.com - 200 0 TAG_NONE:ORIGINAL_DST peek
Hope that helps.
James
Excellent!
James
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
