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

[squid3 at treenet.co.nz]

On 2022-11-02 07:49, Grant Taylor wrote:
> On 11/1/22 11:33 AM, squid3 wrote:
>> That is not true as a blanket statement.
> 
> Please clarify which statement / who you are addressing.
> 
> It seems as if you're addressing mingheng (copied below for 
> convenience):
> 

Yes I was addressing mingheng's statement.


> On 10/31/22 7:32 PM, mingheng wang wrote:
>> I delved into the configuration the last few days, and found that 
>> Squid doesn't officially support cache_peer when ssl_bump is in use.
> 
> But you may be addressing my statement (...):
> 
> On 11/1/22 10:44 AM, Grant Taylor wrote:
>> That surprises me.  I wonder if it's a technical limitation or an 
>> oversight.
> 
> 
> On 11/1/22 11:33 AM, squid3 at treenet.co.nz wrote:
>> What Squid officially *does not* support is decrypting traffic then 
>> sending the un-encrypted form to a HTTP-only cache_peer.
> 
> Please elaborate.  I'm trying to develop a mental model of what is and 
> is not supported with regard to client / proxy / server communications. 
> I'm unclear on how this applies to the two potential HTTPS streams; 
> client-to-proxy and proxy-to-server.

Okay, some info that may help with that mental model...

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.

* 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.

* 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.


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.

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)

Each agent along the chain can add or remove any number of transfer 
layers to the protocol X-over-Y stack. Although for efficiency most 
prefer to minimize the layering depth.

A typical web request may flow across the Internet through a chain of 
proxies like this:

  client -(1)-> S1 =(4)=> S2 =(1)=> S3 -(2)-> O

  C = origin client
  S1 = forward-proxy
  S2 = insecure relay proxy
  S3 = TLS terminating reverse-proxy
  O = origin server


>  Or if this is more applicable to TLS-Bump on implicit / network 
> transparent / intercepting proxies where the client thinks that it's 
> talking HTTPS to the origin server and the proxy would really be 
> downgrading security by stripping TLS.
> 

It's *more* important with SSL-Bump 'bump' due to the interception 
nature of that operation. But also applies to other cases.

SSL-Bump implies interception of TLS
  * intercept may happen at network level (port 443 redirect or NAT)
  * intercept may be entirely within Squid (CONNECT tunnel unwrapped)

Decryption is independent of interception.
  a) SSL-Bump 'bump' action performs decrypt (the others do not)
  b) a TLS forward/explicit-proxy performs decrypt
  c) a TLS reverse-proxy performs decrypt

Traffic from (a) case requires re-encrypt before sending, even if its 
URL indicates insecure protocols.
Traffic from (b) MUST be re-encrypted when it is for a secure protocol 
eg https://, otherwise optional.
Traffic from (c) SHOULD be encrypted on sending, but always optional.

The "re-encrypt" may take the form of TLS to the secure peer, or a 
CONNECT tunnel through any peer with TLS to whatever is at the other end 
of the tunnel.


> Here is my mental model based on my current understanding.  Is the 
> following diagram accurate?
> 
>             +-------------+-----------+
>             |  P2S-HTTP   | P2S-HTTPS |
> +-----------+-------------+-----------+
> | C2P-HTTP  |  supported  | supported |
> +-----------+-------------+-----------+
> | C2P-HTTPS | unsupported | supported |
> +-----------+-------------+-----------+
>   C2P = Client to Proxy communication
>   P2S = Proxy to server communication
> 

Vaguely yes. There are three dimensions to the matrix, you only have two 
shown here.
The box showing "unsupported" has "supported" in its other dimension.


>> All other permutations of inbound TCP/TLS, http:// or https:// URL, 
>> and outbound TCP/TLS should currently work to some degree. The more 
>> recent your Squid version the better it is.
> 
> ACK
> 
>