[squid-dev] Non TLS connections to HTTP and SSL_BUMP ports

[Alex Rousskov]

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.