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