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

[Andreas Weigel]

Hi everyone,

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).

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?)

For the records, other clients, like firefox or openssl s_client  
(Version 1.1.1k) do not have any issues, because their Client Hello  
contains said signature algorithm. Please also note that sites like  
ssllabs do not hint that there is too much wrong with the site (apart  
from still allowing TLS 1.0, and TLS1.2 while disallowing TLS1.1).

The only other client that did not work (squid or no squid) for me was  
openssl s_client Version 1.1.1f (Ubuntu 20.04), I could not even force  
it to include SHA1 into the extensions via --sigalgs  
"RSA+SHA1:RSA+SHA256".

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?

Andreas

PS: Some further reading on why this may cause the server to abort the  
handshake at all:  
https://github.com/openssl/openssl/issues/11438#issuecomment-606927855