[ 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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
