[ please keep the traffic on-list. If you want private assistance I do consult for a small fee. ] On 13/12/18 2:51 pm, Sam Handley wrote: > On 13/12/18 12:00 pm, Amos Jeffries wrote: > > Thank you for your reply, it seems adding in an extra step could solve it, even if not ideal. > Just a few questions about your suggestions./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). /Would both PRX1 and PRX2 require https_port to be configured? It would yes. That config setting on the receiving proxy is what makes it a "TLS proxy" instead of just a proxy. > We have a limited ability to edit PRX2 and it does not have https_port enabled. /This option restricts you to the dangerous client-first style bumping, > but you are already using that. /My experience so far is that performing any kind of bump action after step1 results in the connection being TUNNELLED and not cached by PRX1. The only thing which would result in https:// traffic being cached in PRX1 is for PRX1 to be doing the decrypt SSL-Bump itself, or acting at a TLS proxy. Traffic which has https:// URL scheme should only ever leave Squid over an encrypted connection. Especially when "bump" is happening. > For example, > 1. > ssl_bump bump step2 all #results in the connection TUNNELLING and no caching. > Your description earlier was the SSL-Bump and cache happening in PRX3. PRX1 and PRX2 being regular proxies will see tunnels ... or nothing at all. > 2. > ssl_bump peek step2 all > ssl_bump bump step3 all #results in the connection TUNNELLING and no caching. IIRC, your lack of a Step-1 action implies tunneling. The "peek" at Step-2 prohibits "bump" being used at Step-3. So even if my recollection was incorrect above you get a tunnel from this step-3. To decrypt and cache the traffic needs to be going through one of these SSL-Bump sequences: bump, terminate, terminate peek, bump, terminate stare, bump, terminate peek, stare, bump stare, stare, bump The terminate are just there as a catch-all for traffic which bump fails for any reason. You could try splice instead of you want, but that will also fail sometimes - terminate is the reliable one. > > It would be preferred to use server-first if it did indeed cache the content, can you provide a more ideal bump configuration that will still allow us to cache HTTPS. > For that set of requirements you are limited to the possibility #1, #3 or #4 from the set I wrote up earlier. To always bump, and with server-first style you need to start with these ssl_bump rules in PRX3: ssl_bump peek step1 ssl_bump stare ssl_bump bump ... adding terminate or splice actions as needed for non-caching of traffic which has issues with the bumping or you are prohibited from decrypting. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
