On 11/1/22 11:33 AM, squid3@xxxxxxxxxxxxx wrote:
That is not true as a blanket statement.
Please clarify which statement / who you are addressing. It seems as if you're addressing mingheng (copied below for convenience): On 10/31/22 7:32 PM, mingheng wang wrote:
I delved into the configuration the last few days, and found that Squid doesn't officially support cache_peer when ssl_bump is in use.
But you may be addressing my statement (...): On 11/1/22 10:44 AM, Grant Taylor wrote:
That surprises me. I wonder if it's a technical limitation or an oversight.
On 11/1/22 11:33 AM, squid3@xxxxxxxxxxxxx wrote:
What Squid officially *does not* support is decrypting traffic then sending the un-encrypted form to a HTTP-only cache_peer.
Please elaborate. I'm trying to develop a mental model of what is and is not supported with regard to client / proxy / server communications. I'm unclear on how this applies to the two potential HTTPS streams; client-to-proxy and proxy-to-server. Or if this is more applicable to TLS-Bump on implicit / network transparent / intercepting proxies where the client thinks that it's talking HTTPS to the origin server and the proxy would really be downgrading security by stripping TLS.
Here is my mental model based on my current understanding. Is the following diagram accurate?
+-------------+-----------+
| P2S-HTTP | P2S-HTTPS |
+-----------+-------------+-----------+
| C2P-HTTP | supported | supported |
+-----------+-------------+-----------+
| C2P-HTTPS | unsupported | supported |
+-----------+-------------+-----------+
C2P = Client to Proxy communication
P2S = Proxy to server communication
All other permutations of inbound TCP/TLS, http:// or https:// URL, and outbound TCP/TLS should currently work to some degree. The more recent your Squid version the better it is.
ACK -- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
