[squid-users] Does Squid support client ssl termination?

[Grant Taylor]

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-TLS

I 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 server
>   3) 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20221104/186df1cf/attachment-0001.bin>