[squid-users] SSL Bump with HTTP Cache Peer Parent

[Sam Handley]

On 13/12/18 2:12 pm, Amos Jeffries wrote:
> [ 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users


Sorry, still figuring out how to use the mailing list. I will contact you directly about consultation.

I also may have mixed up the order of my proxies. You are absolutely right.

This seems like it might be the best approach.

   ssl_bump peek step1
   ssl_bump stare step2
   ssl_bump bump step3
   ssl_bump splice spliceACL

Re-reading your options 4 sounds like it may work the best for us. It is certainly the one I understand the most.