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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
