On 11/4/22 7:05 AM, Amos Jeffries wrote:
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.
I will concede "differentiate", but I don't agree that it "clarifies".
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.
Okay....How would you describe the following in a green field discussion to someone without any prior context to suggest nomenclature?
Client uses an explicit proxy connection with TLS encryption to ask the proxy to request a TLS encrypted web page on the client's behalf.
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).
Eh.... This isn't a photon, it's can't be both a wave and a particle. I feel like it's really one thing and what Squid does with it may be different based on if Squid is SSL-Bumping or not. After all, it's both are exactly the same thing to the client, independent of if Squid is SSL-Bumping or not.
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.
Hum. So if I understand you correctly, this could be HTTP application layer protocol on top of an unencrypted TCP transport /or/ on top of an encrypted TCP+TLS transport?
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 don't consider client -> squid -> origin to be a chain of proxies.I do consider client -> squid -> $SOME_OTHER_PROXY -> origin to be a chain of proxies.
To me for it to be a chain of proxies, there must be multiple proxies involved.
N.B. maybe this is somewhat a problem of nomenclature. Hence why I have explicitly typed out "chain /of/ /proxies/" here.
By the very nature of how proxies work, even for the simplest method of an unencrypted TCP transport from client to proxy and then an unencrypted TCP transport from the proxy to the origin server, there are three parties involved; client, proxy, and origin server.
What's more is that this three party system is baked into many contemporary clients. Conversely, almost everything needs an extremely special configuration to add, or chain, an additional intermediate proxy in the middle. Hence why I think that "proxy chaining" is very special. -- After I type that, the nomenclature "/proxy/ chaining" even supports that there are multiple proxies.
N.B. "origin server" may be a misnomer as from the client's and Squid's point of view, it may not be an origin server and may in fact be an additional layer of reverse proxying unbeknownst to the client nor Squid.
Browsers are origin-client software. They deal with these layers:* HTTP (http:// to origin, or http:// to traditional plain-text forward-proxy), or
I believe that's really two different things in an explicitly configured proxy use case, because what the client will do is subtly, but distinctly different and that difference is important.
* 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.
Maybe it's just me, but I don't know that I could extract what is happening, without a lot of thought, from these descriptions.
- HTTP-over-TCP - HTTP-over-TLS - HTTP-over-TCP-over-HTTP-over-TCP - HTTP-over-TLS-over-HTTP-over-TCP - HTTP-over-TCP-over-HTTP-over-TLS - HTTP-over-TLS-over-HTTP-over-TLSI don't see a good clean / uniform cut / divide for determining what is what, client to origin, client to proxy, or proxy to origin.
There you are running into the ambiguity of "chain". Using both its meanings in one sentence.
I don't think so. See above.I'm fairly certain of what I think to be a proxy chain. It seems as if you are also fairly certain of what you think to be a proxy chain. But it seems like we may be using different definitions of what is a proxy chain.
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 server3) protocol Z actually being spoken between Squid and next-hop peer/server
Ah. You're introducing -- what I consider to be -- proxy chaining into the mix.
I thought you were instead going to introduce implicit vs explicit client configuration.
As indicated elsewhere, I consider proxy chaining to be largely out of scope as the (1st) proxy server can't really differentiate between the the target of it's traffic being an origin server vs another (2nd) proxy server. This is especially true when TLS encryption is in use and SSL-Bump is not in play.
-- Grant. . . . unix || die
<<attachment: smime.p7s>>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
