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

[Amos Jeffries]

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