On 3/11/2022 4:13 am, Grant Taylor wrote:
On 11/1/22 4:17 PM, squid3 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.
Aye, that is the terminology definitions of them. Which does not clearly
convey the recursive layer/nesting properties. They way I suggested to
think of TLS and HTTP as transfer layers helps clarify that property.
* 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?
The best I have found is the rule-of-thumb to avoid abbreviations that
have multiple meanings and use simple nouns that the reader understands
already to build a compound noun that they can comprehend. As such you
will find my wording varies between discussions, and can adjust as I
learn what terms the others understand already.
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.
To Squid the transport is (almost) always TCP. Whether TLS is treated as
transport layer or application layer depends on the Squid features (eg
SSL-Bump).
So for your purpose of understanding the possibilities it is best to
think of it as just another transfer protocol that Squid can receive
like HTTP. Which can either transfer opaque client information, or
another type of transfer protocols "nested" inside it.
* 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.
Oh, I see (I think). I use nesting or layering (from OSI model
terminology) because "chain" is used by HTTP in the definition of how
traffic is routed between multiple agents. For example;
client->squid->server is a chain.
I'm focusing on the what traditional web browsers / clients support
out of the box; client-to-proxy and proxy-to-server.
Browsers are origin-client software. They deal with these layers:
* HTTP (http:// to origin, or http:// to traditional plain-text
forward-proxy), or
* HTTP-over-TLS (https:// to origin), or
* HTTP-over-TLS-over-HTTP (traditional https:// to plain-text
forward-proxy).
Recently some started handling HTTP-over-TLS-over-HTTP-over-TLS - which
is traditional https:// to an secure/encrypted forward-proxy.
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.
There you are running into the ambiguity of "chain". Using both its
meanings in one sentence.
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 three dimensions in play are:
1) protocol X being spoken between client and Squid
2) protocol Y the client is requesting to use with the origin server
3) protocol Z actually being spoken between Squid and next-hop peer/server
protocol Z *could* be the same protocol the client requested, OR it
could be a CONNECT tunnel (plain-text HTTP) to the origin server.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
