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

[Vieri]

----- Original Message -----
From: Alex Rousskov <rousskov at measurement-factory.com>
> If my reconstruction of the events was correct, then OpenSSL supplied as
> much information as it could -- the "unsupported TLS/SSL versions" is
> _your_ conclusion based on the information that neither Squid nor
> OpenSSL had access to.
>
> 
>> I'm only supposing that
>> without the ssloptions I posted above, openssl will try TLS 1.2 and
>> silently fail if that doesn't succeed.
>
> It takes two to tango. How silent that failure is depends, in part, on
> the server. AFAICT, your server was 100% silent about the reason behind
> its abrupt connection closure, and OpenSSL correctly declined to
> speculate about those reasons due to lack of info. From OpenSSL/client
> point of view, it could have been anything from an unsupported TLS
> version to a crashed server.


Thanks for taking the time to explain. I understand the point you make but I'm still a bit scepticle, probably due to my lack of knowledge in this domain.

I haven't read the RFCs for TLSv1*, SSLv*, etc. However, let's try to give a simple and straightforward example, just to clear things up. Suppose you (the client) meet someone (the server) and ask her/him out. That person can turn away and refuse your proposal without saying a word so you'll never know the reason. That's what you explained and I get that. However, you must "obviously" know what you told that person. Maybe it's not that "obvious" in the case of Squid & OpenSSL, but I'm guessing that it should be possible for Squid to tell OpenSSL to report what it actually said to the server without the need for an admin to do a traffic dump and analysis.

Let's take this simple example into consideration where I use cURL to connect to the same MS Exchange server:

# curl -k -v https://10.215.144.21
* Rebuilt URL to: https://10.215.144.21/
*   Trying 10.215.144.21...
* Connected to 10.215.144.21 (10.215.144.21) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to 10.215.144.21:443 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to 10.215.144.21:443

Now that's clear. cURL tried to use TLS1.2 and failed. The nasty server didn't even say hello.

It's interesting to note that the following actually DOES give more information (unsupported protocol):

# curl --tlsv1.1 -k -v https://10.215.144.21/
*   Trying 10.215.144.21...
* Connected to 10.215.144.21 (10.215.144.21) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.1 (OUT), TLS header, Certificate Status (22):
* TLSv1.1 (OUT), TLS handshake, Client hello (1):
* error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol
* Closing connection 0
curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol


Of course, the following test succeeds:

# curl --tlsv1.0 -k -v https://10.215.144.21/
*   Trying 10.215.144.21...
* Connected to 10.215.144.21 (10.215.144.21) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.0 (OUT), TLS handshake, Client hello (1):
* TLSv1.0 (IN), TLS handshake, Server hello (2):
* TLSv1.0 (IN), TLS handshake, Certificate (11):
* TLSv1.0 (IN), TLS handshake, Server finished (14):
* TLSv1.0 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.0 (OUT), TLS change cipher, Client hello (1):
* TLSv1.0 (OUT), TLS handshake, Finished (20):
* TLSv1.0 (IN), TLS change cipher, Client hello (1):
* TLSv1.0 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / DES-CBC3-SHA


Now with the openssl command-line client:

#  openssl s_client -connect 10.215.144.21:443 -tls1_2
CONNECTED(00000003)
3072153276:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:


#  openssl s_client -connect 10.215.144.21:443 -tls1_1
CONNECTED(00000003)
3072530108:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362:


...and it obviously works with -tls1.

I haven't looked at the source code but I guess Squid uses the OpenSSL library.

I searched the Squid log above and below these lines:

2017/01/24 17:20:28.997 kid1| 83,5| NegotiationHistory.cc(83) retrieveNegotiatedInfo: SSL connection info on FD 18 SSL version NONE/0.0 negotiated cipher 
2017/01/24 17:20:28.997 kid1| Error negotiating SSL on FD 18: error:00000000:lib(0):func(0):reason(0) (5/0/0)
2017/01/24 17:20:28.997 kid1| TCP connection to 10.215.144.21/443 failed


However, I haven't found any hint of what the client (cache_peer) tried to offer.

Maybe if Squid gets an SSL negotiation error with no apparent reason then it might need to retry connecting by being more explicit, just like in my cURL and openssl binary examples above.


I used the latest Squid 4 beta by the way.

I would have understood earlier the reason of the connection failure if Squid/OpenSSL had logged how they were actually hitting on the server.

Anyway, it's not a big deal now that I know what to do if this kind of connection issue comes back up. It could be useful to others though if the logging could be a tad more verbose or if Squid could retry connections by explictly specifying protocols (and logging them).

Thanks,

Vieri