<!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>