Re: [squid-users] Issues with SSLBumped high traffic forward caching

2021-06-10 Thread Matthias Saou
On Wed, 9 Jun 2021 10:45:40 -0400
Alex Rousskov  wrote:

> > assertion failed: Transients.cc:221: "old == e"
> 
> This is a Squid bug. Please consider creating a Bugzilla entry and
> posting the corresponding backtrace there:
> https://wiki.squid-cache.org/SquidFaq/BugReporting#crashes_and_core_dumps

Thanks a lot for the super quick and detailed reply! The cores were
dumped, the traces were backed and the bug report was filed! :-)

https://bugs.squid-cache.org/show_bug.cgi?id=5134

Let me know if you need any further details or for us to test any
patches.

Cheers,
Matthias
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


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

2021-06-10 Thread Andreas Weigel

Hi Alex,


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


don't know why I haven't yet had the idea, but indeed, if I force  
splicing at step 1 or even 2, the site loads without error. This is  
not exaclty a solution, but at least something to work with. Thanks!


I think I will have a look at the squid sources to see if I can put my  
finger on the reason for this behavior. Any pointers are very welcome,  
it has been some time since I meddled with squid.


Andreas

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


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

2021-06-10 Thread Alex Rousskov
On 6/10/21 11:00 AM, Andreas Weigel wrote:

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

> don't know why I haven't yet had the idea, but indeed, if I force
> splicing at step 1 or even 2, the site loads without error. This is not
> exaclty a solution, but at least something to work with.


If you tell Squid to proceed to step3, then Squid has a duty to validate
the TLS server. Failure to do so should result in an error. This is what
https://wiki.squid-cache.org/Features/SslPeekAndSplice promises to do
during step3:

i. Get TLS Server Hello info from the server, including the server
certificate.
ii. Validate the TLS server certificate.
iii. Evaluate again all ssl_bump rules and perform the first matching
action (splice, bump, or terminate) for the connection.

We probably should enhance Squid to better control its reaction to 3i
failures, but such adjustments may have to be guarded by some new
explicit configuration because they would allow splicing connections to
non-TLS servers or very insecure TLS servers (that were previously
reported as errors).


HTH,

Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users


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

2021-06-10 Thread 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 :


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