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

[squid3 at treenet.co.nz]

On 2022-11-02 13:58, mingheng wang wrote:
> On Wed, Nov 2, 2022 at 6:17 AM squid3 wrote:
>> 
>> 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.
>> 
>   I don't understand. According to the wiki on Squid that I read, there 
> are
> several
> steps involving "peek", "bump" or "slice" etc, we can already choose to
> bump or
> slice through SNI at step2. So why does HTTP have to be encrypted too?

Those "steps" are points along the TLS handshake sequence, the actions 
are things Squid can be asked to do at each step.
The peek/splice/stare/terminate actions do not decrypt, so do not 
matter.

The 'bump' action uses details from origin TLS server certificate and 
maybe initiates a TLS session between client and server. That means a) 
there needs be a TLS server to fetch those details from, and b) the 
decrypted traffic can only be sent to that TLS server. Thus delivery of 
traffic to the server requires re-encryption with the security keys 
'bump' negotiated with the server already (so your split-in-half idea 
breaks).


These limits are all specific to SSL-Bump decrypted traffic. Different 
details/restrictions apply to Squid operating as TLS reverse-proxy or 
TLS explicit forward-proxy. I assume that you have already considered 
those setups before settling on SSL-Bump intercepting TLS.


HTH
Amos