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

[Andreas Weigel]

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 at measurement-factory.com>:

> 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_handshake_failure.patch
Type: text/x-diff
Size: 691 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20210610/1a3fb091/attachment.patch>