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

[Grant Taylor]

On 11/1/22 4:17 PM, squid3 at treenet.co.nz 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

-------------- 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/20221102/bb47b21a/attachment.bin>