[squid-users] [EXTERNAL]Re: URL Regex ACLs Don't Evaluate After Bumping

[Shane Poage]

Alex,

Thanks for all your help so far - I really appreciate it. However, I'm not sure
we're on the same page for some reason because as I said previously, the
suggestions you have made do not appear to be having the effect I'm looking
for. Let me back up a bit and clarify a few things to make sure I am
understanding properly, because there seem to be a few things that I have
thus far fundamentally misunderstood.

My understanding of how SSL bumping works is as follows, based on what
I have read in all of the documentation I could possibly find:

1. A CONNECT request comes in to the proxy from a client.
2. The proxy does access control on that CONNECT request and decides
     whether or not to permit the tunnel. For the sake of moving on, let's
     assume that it decides to allow.
3. The proxy then begins processing the rules for SSL bumping. Again, for the
     sake of simplicity, we'll say that all traffic is getting bumped.
4. The proxy begins bumping traffic and individually processing the requests
     for that session.
5. Each request within the session has the http_access rules applied to them
     as if they were normal HTTP requests made through the proxy, until the
     session is terminated.

Is this understanding correct?

Thanks again,
-Shane

On 11/2/18, 12:26 PM, "Alex Rousskov" <rousskov at measurement-factory.com> wrote:

    On 11/2/18 9:54 AM, Shane Poage wrote:
    
    > my original squid.conf had an ACL directive corresponding to the
    > functionality in question:
    
    > 	acl CONNECT method CONNECT
    
    That CONNECT ACL declaration is OK, but what matters is how you _use_
    that declared ACL. The configuration you posted earlier did not use it
    at all.
    
    
    > http_access allow CONNECT artifactory_repo_filter
    
    This "CONNECT and artifactory_repo_filter" rule does not make sense. As
    I said earlier, your artifactory_repo_filter cannot match a CONNECT
    request. Thus, you are joining two conditions that can never be
    satisfied for the same request. For any request, you will get either
    (false and true) or (true and false), which is, of course, always false.
    
    
    > http_access allow CONNECT
    > http_access allow artifactory_repo_filter
    
    This "CONNECT or artifactory_repo_filter" combination makes sense, but
    the first part is dangerous -- you probably should not allow CONNECT
    request to arbitrary port numbers. If you look at how CONNECT requests
    are handled in squid.conf.default, then you will probably come up with
    something like this:
    
      http_access deny !Safe_ports
      http_access deny CONNECT !SSL_ports
      http_access allow CONNECT
      http_access allow artifactory_repo_filter
      http_access deny all
    
    or a bit shorter but arguably less safe (long-term) version:
    
      http_access deny !Safe_ports
      http_access allow CONNECT SSL_ports
      http_access allow artifactory_repo_filter
      http_access deny all
    
    or an even shorter but arguably even less safe (long-term) version:
    
      http_access allow SSL_ports CONNECT
      http_access allow Safe_ports artifactory_repo_filter
      http_access deny all
    
    
    N.B. The above configurations allow plain text traffic matching
    artifactory_repo_filter. I do not know whether that is what you want.
    
    
    > 	This resulted in all SSL traffic being permitted and passed through
    > 	the proxy.
    
    If you are still bumping all SSL traffic, and your
    artifactory_repo_filter ACL is working, then all of the above reasonable
    configurations should still block bumped GET requests that match
    artifactory_repo_filter.
    
    
    > This makes sense to me because the allow CONNECT
    > 	would whitelist all CONNECT traffic, which is what all SSL traffic is
    > 	by my understanding. 
    
    Your understanding is incorrect. Since you are bumping all CONNECT
    tunnels, your http_access traffic consists of:
    
    * CONNECT requests
    * decrypted requests (e.g., GET) inside bumped CONNECT tunnels
    * plain requests (e.g., GET) outside CONNECT tunnels
    
    
    HTH,
    
    Alex.
    
    
    > On 11/1/18, 6:21 PM, Alex Rousskov wrote:
    >     On 11/1/18 2:46 PM, Shane Poage wrote:
    >     
    >     > I have my proxy configured to bump all traffic so that the
    >     > urlpath_regex ACL can be applied, but it appears to not have any
    >     > effect post-bump.
    >     
    >     Your proxy will deny any first post-bump request and close the tunnel
    >     because you deny all CONNECT requests that initiate tunnels. CONNECT
    >     requests do not have a URL path so they will never match your
    >     "http_access allow" rule.
    >     
    >     When a CONNECT request is denied by a bumping Squid, that Squid bumps
    >     the tunnel and then denies the very first bumped request on that tunnel,
    >     whatever that request is. This delayed error return is done to deliver
    >     the "access denied" error page to the client -- browsers ignore CONNECT
    >     error responses.
    >     
    >     
    >     > http_port 3128 ssl-bump \
    >     >   cert=/etc/squid/ssl_certs/artifactory_mitm_ca.pem \
    >     >   generate-host-certificates=on \
    >     >   dynamic_cert_mem_cache_size=4MB
    >     
    >     > ssl_bump bump all
    >     
    >     > acl artifactory_repo_filter urlpath_regex ^/artifactory
    >     > http_access allow artifactory_repo_filter
    >     > 
    >     > # And finally deny all other access to this proxy
    >     > http_access deny all
    >     
    >     Insert an http_access rule to allow all safe CONNECT requests before you
    >     deny everything else. IIRC, squid.conf.default has an example of how to
    >     do that.
    >     
    >     Alex.
    >     _______________________________________________
    >     squid-users mailing list
    >     squid-users at lists.squid-cache.org
    >     http://lists.squid-cache.org/listinfo/squid-users
    >     
    >