On 2022-11-02 07:49, Grant Taylor wrote:
On 11/1/22 11:33 AM, squid3 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):
Yes I was addressing mingheng's statement.
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.
Okay, some info that may help with that mental model...
The first thing you need to do is avoid that "HTTPS" term. It has
multiple meanings and they cause confusion. Instead decompose it into
its TLS and HTTP layers.
* A client can use TCP or TLS to connect to a proxy.
- this is configured with http_port vs https_port
* Independently of the connection type the client can request http:// or
https:// URLs or CONNECT tunnels.
* Independent of what the client is doing/requesting, a cache_peer may
be connected to using TCP or TLS.
- this is configured with cache_peer tls options (or their absence)
* Independent of anything else, a cache_peer MAY be asked to open a
CONNECT tunnel for opaque uses.
- this is automatically decided by Squid based on various criteria.
TCP is the foundation layer. On top of that can be HTTP transfer or TLS
transfer. Transfer layers can be nested infinitely deep in any order.
So "HTTPS" can mean any one of things like:
1) HTTP-over-TLS (how Browsers handle https:// URLs)
2) HTTP-over-TLS (sending http:// URLs over a secure connection)
3) HTTP-over-TLS-over-TLS (relay (1) through a secure cache_peer)
4) HTTP-over-TLS-over-HTTP (relay (1), (2) or (3) through an insecure
cache_peer via CONNECT tunnel)
Each agent along the chain can add or remove any number of transfer
layers to the protocol X-over-Y stack. Although for efficiency most
prefer to minimize the layering depth.
A typical web request may flow across the Internet through a chain of
proxies like this:
client -(1)-> S1 =(4)=> S2 =(1)=> S3 -(2)-> O
C = origin client
S1 = forward-proxy
S2 = insecure relay proxy
S3 = TLS terminating reverse-proxy
O = origin 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.
It's *more* important with SSL-Bump 'bump' due to the interception
nature of that operation. But also applies to other cases.
SSL-Bump implies interception of TLS
* intercept may happen at network level (port 443 redirect or NAT)
* intercept may be entirely within Squid (CONNECT tunnel unwrapped)
Decryption is independent of interception.
a) SSL-Bump 'bump' action performs decrypt (the others do not)
b) a TLS forward/explicit-proxy performs decrypt
c) a TLS reverse-proxy performs decrypt
Traffic from (a) case requires re-encrypt before sending, even if its
URL indicates insecure protocols.
Traffic from (b) MUST be re-encrypted when it is for a secure protocol
eg https://, otherwise optional.
Traffic from (c) SHOULD be encrypted on sending, but always optional.
The "re-encrypt" may take the form of TLS to the secure peer, or a
CONNECT tunnel through any peer with TLS to whatever is at the other end
of the tunnel.
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
Vaguely yes. There are three dimensions to the matrix, you only have two
shown here.
The box showing "unsupported" has "supported" in its other dimension.
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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
