On 11/1/22 4:17 PM, squid3@xxxxxxxxxxxxx wrote:
Yes I was addressing mingheng's statement.
Thank you for clarifying.
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.
Largely okay. However, a minor nitpick: TCP, TLS, and HTTP are three distinct things. TCP is the traditional transport. TLS is the optional presentation layer that rides on top of TCP.HTTP is the application layer protocol that's spoken between endpoints which rides on top of TLS if present or TCP if TLS is not present.
N.B. I'm eliding UDP / QUIC.
* 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.
Do you have any recommendation of clarifying / consistent terms for using to describe the connection between the client and the proxy with the goal of differentiating it from the connection between the proxy and the server?
I'll argue, but be open to arguments to the contrary, that both connections are using the HTTP application layer protocol on top of whatever transport is being used; TCP or TCP+TLS.
* 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.
Oy vey! I had forgotten about using HTTP's CONNECT to carry non-HTTP traffic.
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.
I'm avoiding -- what I've seen referenced as -- "chaining" for this discussion.
I'm focusing on the what traditional web browsers / clients support out of the box; client-to-proxy and proxy-to-server.
After all, even when chaining is in scope, the chained / down stream proxy is really functioning as the server that the first / upstream proxy connects to. Thus it's really higher layer traffic as far as the first / upstream proxy is concerned.
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)
Hence my question about nomenclature. ...really big snip...
Vaguely yes. There are three dimensions to the matrix, you only have two shown here.
Please elaborate. I'm not following what the 3rd dimension would be with the small amount of coffee that I've had.
The box showing "unsupported" has "supported" in its other dimension.
I'll wait for your elaboration and to finish my coffee before trying to understand that. Also, $WORK beckons.
-- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
