[squid-users] Squid spliced TLS handshake failing with chrome/ium fallback for certain servers

[Alex Rousskov]

On 6/9/21 3:29 PM, Andreas Weigel wrote:
> I stumbled upon a case of someone complaining about a site not being
> reachable via squid. Squid was running as transparent proxy and splicing
> TLS connections.


> Squid reported a TLS handshake error to the client
> (SQUID_ERR_SSL_HANDSHAKE; Handshake with SSL server failed:
> error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure).

If you are _splicing_ connections, then Squid should not be a part of
the TLS handshake at all. If Squid is a part of the TLS handshake in an
ssl_bump peek+splice configuration, then this is a Squid bug or limitation.


> After some wireshark-digging, I found that the site in question (for
> reference: www.klebl.net) aborted the handshake, if the Client Hello's
> "Extension: signature_algorithms" did not contain
> 
>   Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
>       Signature Hash Algorithm Hash: SHA1 (2)
>       Signature Hash Algorithm Signature: RSA (1)
> 
> though it was perfectly capable of using SHA384 (which was negotiated
> with clients that did include sha1 to their signature algorithms). The
> point is, that chrome seems to have adopted a "fallback" approach since
> version 82 (see
> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/yaJcs4p9LNI/m/haZWzX-UBwAJ?pli=1),
> that first tries to connect without said signature algorithm in its
> extension and only if that fails does a second handshake with SHA1
> included. However, squid see and reports the error on the first attempt
> back to the client, so that the TLS-connection setup fails.
> 
> While this seems to be something that probably should be fixed at the
> server side, it does lead users to be believe Squid is at fault.
> 
> I tried bypassing TLS-handshake errors using
> 
> acl handshake_failure ssl_error SQUID_ERR_SSL_HANDSHAKE
> sslproxy_cert_error allow handshake_failure
> 
> but this did not change anything (maybe sslproxy_cert_error only works
> for certificate verification, but not for the handshake?)

Yes, sslproxy_cert_error is about certificates, not TLS handshakes.


> Any suggestions on how to allow the first TLS-connection failure of
> chrome to be passed directly back to client instead of erroeing out, or
> any other ways to fix this problem?

I can only suggest to either fix the Squid bug/limitation or decide to
splice during step1 (based on client SNI, etc., before Squid talks to
the origin server).


HTH,

Alex.