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

[Amos Jeffries]

[ 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