[squid-users] squid reverse proxy (accelerator) for MS Exchange OWA

Alex Rousskov rousskov at measurement-factory.com
Tue Jan 24 18:41:54 UTC 2017


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.



More information about the squid-users mailing list