On 7/4/20 5:33 PM, Eliezer Croitor wrote: > What about connections on intercepted port which are either non TLS/SSL
Non TLS/SSL connections intercepted on https_port are handled according to on_unsupported_protocol settings. > or when squid had some server or client negotiation issues? There are many nuances here, but "Squid negotiation" usually implies that the bump decision has been made, and Squid is sending its own TLS secrets instead of forwarding client ones. Bumping errors are, essentially, transport errors. The connection(s) will probably be closed. If Squid-server negotiation fails, then the client will be bumped, and a Squid error response will be sent to the client. > The first issue with TLS connections is that if for any reason the proxy > didn’t managed to negotiate and establish a TLS connection with the > server, the client is STUCK. I do not know what you mean by "stuck" exactly, but, bugs notwithstanding, Squid-server negotiation failures do not lead to stalled clients. In the worst case, Squid-server negotiation may timeout, but even that should not result in a client waiting forever. > - Proxy side “retries” toward the TLS server Retries usually make sense if something is changed for the next attempt. AFAICT, you propose that the second attempt will be done in splicing mode (despite the previous decision to bump), increasing the chances of "success" (for some definition of success). Please correct me if I misunderstood. > The sketch of such a function can be > - If TLS handshake exists, try to parse > - If parse is OK try to connect the remote server else throw > the connection into some ACL > - If the remote server responds well to a TLS handshare, bump > else spice All of the above is already supported except the very last bit -- Squid does not splice on Squid-server TLS negotiation failures. Moreover, splicing the client and the server after a TLS negotiation failure is technically impossible -- the server already expects Squid secrets, not client secrets. It would be possible to establish another TLS connection with the server and splice that new connection with the old client connection. One could add some kind of on_tls_connect_failure directive to enable and control that behavior. If that feature is needed to support some reasonable use case, I think its quality implementation should be welcomed. HTH, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
