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@xxxxxxxxxxxxxxxxxxxxx
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.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
