On 13/12/18 12:15 pm, sam.handley wrote: > I am not 100% confident what I am asking is possible but I'd love it to be > confirmed. > > Here is what our setup would look like, I’ve explained a bit below: > > DEVICE ---> PRX3 (HTTPS CACHE) ---> PRX2 ---> PRX1 ---> INTERNET > > Our current environment is a bit behind the times and inflexible. We have a > local squid proxy/cache (PRX2) that we do not fully control that only caches > HTTP content. This proxy is downstream from another proxy which is also HTTP > (PRX1). Both just TUNNEL HTTPS. PRX1 is the only way out of our WAN to the > internet. > > We would like to start caching HTTPS (PRX3) because these other proxies are > not and it is costing us bandwidth. With the config below and a direct > internet connection I can successfully connect and cache HTTP/S content. > However, this won’t work in our environment. We must go through a cache peer > either PRX1 or PRX2, adding either upstream proxy as a cache peer parent > results in either SSL errors or the request not being forwarded to the peer. > > I think what I need to do is TUNNEL the bumped request to PRX2 over HTTP. I > thought squid 4 could do this but can’t find any docs for it so it may have > been wishful thinking. No official version of Squid can do that directly for decrypted requests. Only for HTTPS which is being spliced or non-HTTP protocols that happen to get intercepted on port 443. There are several possibilities though: First is unofficial Factory code that implements this feature. Available for testing at <https://github.com/measurement-factory/squid/tree/SQUID-360-peering-for-SslBump>. Second is that if PRX1 or PRX2 can be configured as a regular TLS proxy - receiving proxy traffic to a https_port (or any non-Squid software' equivalent). Then it can be used as a cache_peer with 'ssl' option(s). This option restricts you to the dangerous client-first style bumping, but you are already using that. Third is that the DEVICE is set to pass https:// URLs to PRX2 using regular TCP connections and HTTP rather than TLS. That leaves the PRX3 able to relay the non-encrypted requests to a peer as-is. Whichever upstream PRX1 or PRX2 is used will need to do the encryption part before the traffic hits the Internet. Despite the use of TCP connections this is slightly better than the client-first bumping. At least each agent in the chain is clear and truthful about the security properties of its connections. Fourth is a workaround using NAT interception of port 443 and two proxies. If you setup a PRX-A doing the bump but acting as if it had a direct network connection. The PRX-B using a https_port with "intercept ssl-bump" options and doing splice on all traffic and passing the resulting CONNECT tunnels through to the PRX1 or PRX2. All these have actually been used by some installations at one point or another. So there is precedent, though YMMV which works for you. I expect #4 can also be done as a variant with SMP workers in PRX3 instead of separate proxies - that I am not aware of anyone doing though. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
