On 01/24/2017 01:02 AM, Vieri wrote: > 2017/01/24 07:58:57.076 kid1| 83,5| bio.cc(139) read: FD 18 read 0 <= 65535 The peer at 10.215.144.21:443 accepted Squid connection and then closed it, probably before sending anything to Squid (you did not show enough FD 18 history to confirm that with certainty, but it is likely). > 2017/01/24 07:58:57.076 kid1| 83,5| NegotiationHistory.cc(83) retrieveNegotiatedInfo: SSL connection info on FD 18 SSL version NONE/0.0 negotiated cipher Nothing was negotiated. > 2017/01/24 07:58:57.076 kid1| Error negotiating SSL on FD 18: error:00000000:lib(0):func(0):reason(0) (5/0/0) More-or-less confirms the above -- an SSL-violating end of TCP connection. > 2017/01/24 07:58:57.076 kid1| TCP connection to 10.215.144.21/443 failed > 2017/01/24 07:58:57.077 kid1| 15,2| neighbors.cc(1246) peerConnectFailedSilent: TCP connection to 10.215.144.21/443 dead More echoes of the same error. > Also, I'm not sure why the SSL version isn't picked up (NONE/0.0) Probably because the server did not send its SSL version to Squid. > What else can I try? I would start by capturing TCP packets between Squid and the server in question to confirm that the server (a) receives SSL ClientHello from Squid and (b) closes the connection before sending SSL ServerHello to Squid. If that is confirmed, you could interrogate the server about its decision to close the connection. For example, it may not like the ciphers offered by Squid. Establishing similar SSL connections from Squid IP address to the server using OpenSSL command-line client may help triage this further. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
