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
