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