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

James Lay jlay at slave-tothe-box.net
Wed Jun 24 18:05:53 UTC 2015


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 at dalabs.com_
> _703-829-6694_
> 
> On Wed, Jun 24, 2015 at 1:31 PM, James Lay <jlay at slave-tothe-box.net>
> 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


More information about the squid-users mailing list