On 01/26/2017 03:16 AM, Vieri wrote: > 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. Your are correct, but, in most cases, it is a lot easier to dump and analyze traffic than to ask OpenSSL inside Squid to report what it actually said. This is, in part, Squid's own fault, but OpenSSL does not make it easy either. More on that below at (**). > 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. Please note that the information you see above details what Curl did, not what OpenSSL did. (**) Squid prints many similar details as well, but because Squid generally deals with many concurrent transactions over a long time, and does a lot more than Curl does, those details are not as easy to find/isolate in Squid debugging logs. You found some of them. Again, Squid could do a lot better in this area, but nobody is working on that right now AFAIK, and even my attempts to form consensus on how this should be done have failed so far. > It's interesting to note that the following actually DOES give more information (unsupported protocol): * If the server sent nothing, then Curl gave you potentially incorrect information (i.e., Curl is just _guessing_ what went wrong). * If the server sent something, then either Squid situation was different or I did not see that additional info in the logs you have posted. Based on everything I have seen so far, it is probably the former -- the server sent nothing. > I haven't looked at the source code but I guess Squid uses the OpenSSL library. Yes, in your case, it does. > However, I haven't found any hint of what the client (cache_peer) tried to offer. Cache_peer is not the client here, but yes, see (**) above. > 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. Sorry, I do not know what "retry connecting by being more explicit" means. AFAICT, neither Curl nor s_client tried reconnecting in your examples. Also, an appropriate default for a command-line client is often a bad default for a proxy. It is complicated. > I would have understood earlier the reason of the connection failure > if Squid/OpenSSL had logged how they were actually hitting on the > server. Agreed. > 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). Agreed in general, but the devil is in the details. Improving this is difficult, and nobody is working on it at the moment AFAIK. http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F Cheers, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
