Alex,
Great, it sounds like I'm pretty much on-track in terms of understanding how bumping
works under the hood. Thanks for taking the time to step through that and confirm my
understanding.
So here's the problem: the initial solution you gave for my urlpath_regex ACL not
permitting the traffic I expected was that I needed to permit the initial CONNECT request.
That made sense, but did not appear to behave exactly as I expected. Adding the
'method CONNECT' ACL as an allow http_accept directive appears to let ALL HTTPS
traffic through the proxy and ignore the other ACLs that should apply to the subsequent
requests in the CONNECT tunnel. This doesn't make sense to me based on how I thought
I understood the way bumping functions.
So, here's the question: if I'm not misunderstanding how bumping works, have I uncovered
a bug in Squid? Either in the form of the CONNECT ACL not being applied as expected, or
in the form of the urlpath_regex not being applied... Or is there something additional that
I'm fundamentally missing?
Thanks for your continued assistance,
-Shane
On 11/2/18, 3:15 PM, "Alex Rousskov" <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
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@xxxxxxxxxxxxxxxxxxxxx
> > http://lists.squid-cache.org/listinfo/squid-users
> >
> >
>
>
>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
