Alex, I have attached a gzipped tarball that includes three items: 1. The squid.conf for the configuration that is not behaving as I expected 2. The access.log for two requests (which I will describe in a moment) 3. The cache.log for startup, those same two requests, and shutdown of the squid instance.
The two requests made through the proxy were made using wget on another machine configured to route traffic through the proxy: 1) https://www.google.com/ - Squid permitted the traffic through. According to my understanding, it should have denied it due to the urlpath_regex ACL in the config. 2) https://sottartifactory.corporate.datacard.com:8443/artifactory/some/path/to/artifact.jar - This one was allowed through, which is expected in this case. Please let me know if there's any more information I can provide that would be helpful, and thanks again for sticking with me on this. -Shane On 11/5/18, 1:23 PM, "Alex Rousskov" <rouss...@measurement-factory.com> 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/5/18 12:02 PM, Shane Poage wrote: > 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? It is difficult for me to say why a correct configuration does not work in your environment because you have not supplied any relevant details (yet). You have supplied details for some other configurations IIRC, but not the one you should be using. As a starting point, I recommend posting your current/correct configuration and the corresponding compressed ALL,3 cache.log while reproducing a problem on an isolated Squid handling a single problematic transaction. If possible, please use curl, wget, or another single-request HTTP client to drive that transaction, not a browser. Please also post the corresponding access.log lines. Thank you, Alex. > On 11/2/18, 3:15 PM, "Alex Rousskov" <rouss...@measurement-factory.com> 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@lists.squid-cache.org > > > http://lists.squid-cache.org/listinfo/squid-users > > > > > > > > > > > > > > >
squid_debug.tar.gz
Description: squid_debug.tar.gz
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
