Hi again,
I can only suggest to either fix the Squid bug/limitation
I found Ssl::PeekingPeerConnector::noteNegotiationError in
src/PeekingPeerConnector.cc. There are some checks for the case that
srvBio->bumpMode() == Ssl::bumpPeek. If I apply the attached patch,
matching on the ssl_lib_error for failed handshakes (just for testing,
not an actual suggestion!) and setting bypassValidator = true in that
case, the connection from Chrome to the problematic site goes through
after the initial failure (configured with peeking at step2, splicing
at step 3).
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.
I agree. Said function produces an error page, if none of the checks
make it return early. Maybe the logic here should be inverted to
rather enumerate error cases that actually justify an error page
(maybe only local errors like failed syscalls, OOM?). I am far from
understanding all possible paths of execution this may take and
therefore I may easily miss an important point here, though.
Andreas
Zitat von Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>:
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
diff --git a/src/ssl/PeekingPeerConnector.cc b/src/ssl/PeekingPeerConnector.cc
index 0d680d88e..d6fc13063 100644
--- a/src/ssl/PeekingPeerConnector.cc
+++ b/src/ssl/PeekingPeerConnector.cc
@@ -295,6 +295,9 @@ Ssl::PeekingPeerConnector::noteNegotiationError(const int result, const int ssl_
// if (const auto spliceResumed = true) {
bypassValidator = true;
// } // else fall through to find a matching ssl_bump action (with limited info)
+ } else if (ssl_lib_error == 0x14094410) {
+ bypassValidator = true;
+ debugs(83, 3, "Error " << ssl_lib_error << " detected; bypassing");
}
if (bypassValidator) {
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
