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

Alex Rousskov rousskov at measurement-factory.com
Fri Nov 2 20:15:07 UTC 2018 

On 11/2/18 12:22 PM, Shane Poage wrote:

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

To simplify, I will interpret the statements below in SslBump context.
That is, I will interpret them as they are applied to traffic received
on an http_port with ssl-bump configured.

I will also assume a bug-free implementation. In other words, the entire
text below is under the "Bugs notwithstanding..." precondition.


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

Correct. This decision is a part of SslBump step1.

[ The decision to allow or deny CONNECT is done again during SslBump
step2 if a peek or stare action matches during step1. IIRC, those
additional checks do not happen in your configuration because your
ssl_bump rules match a bump action at step1. Thus, this additional
caveat does not apply to you. ]


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

OK. This processing is a part of SslBump step1.


> 4. The proxy begins bumping traffic and individually processing the requests
>      for that session.

OK. This processing is a part of SslBump step1.

[ Again, there could be more SslBump steps in general, but, in your
specific case, the client connection is bumped here. ]


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

These bumped requests have "https" scheme and some special properties
specific to bumped requests but, overall, they are indeed processed as
usual, including application of http_access rules to each of the bumped
request.


To make progress, I recommend identifying a specific Squid action that
contradicts either your understanding of how things should work or my
remarks and then posting the relevant details of that action along with
a clear explanation of where you see a contradiction.

Alex.


> On 11/2/18, 12:26 PM, "Alex Rousskov" 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
>     >     
>     > 
>     
>     
>

More information about the squid-users mailing list