----- Original Message ----- From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> >> 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). I never tried telling Squid to use TLS 1.1 ONLY so I never got to see Squid's log when using that protocol. I'm supposing I would have seen the same thing in Squid as I've seen it with CURL. So I'm sure Squid would log useful information for the sys admin but... (see below). >> 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. Let me rephrase my point but please keep in mind that I have no idea how Squid actually behaves. Simply put, when Squid tries to connect for the first time, it will probably (I'm guessing here) try the most secure protcol known today (ie. TSL 1.2), or let OpenSSL decide by default which is probably the same. In my case, the server replies nothing. That would be like running: # curl -k -v https://10.215.144.21 or # openssl s_client -connect 10.215.144.21:443 They give me the same information as Squid's log... almost nothing. So my point is, if that first connection fails and gives me nothing for TLS 1.2 (or whatever the default is), two things can happen: either the remote site is failing or it isn't supporting the protocol. Why not "try again" but this time by being more specific? It would be like doing something like this: # openssl s_client -connect 10.215.144.21:443 || openssl s_client -connect 10.215.144.21:443 -tls1_1 || openssl s_client -connect 10.215.144.21:443 -tls1 Of course, this shouldn't be done each and every time it tries to connect because it would probably give performance issues. If Squid successfully connects with TSL 1.0 then it could "remember" that for later connections to the same peer. It could also forget it after a sensible timeout, in case the remote peer starts supporting a safer protocol. > Agreed in general, but the devil is in the details. Improving this is > difficult, and nobody is working on it at the moment AFAIK. I can imagine it must be difficult... Instead of improving the source code, maybe a FAQ or some doc related to "squid error negotiating SSL" which would describe what to try when the error message is a mere "handshake failure". In the end, it's as simple as setting ssloptions correctly (in my case, NO_SSLv3,NO_SSLv2,NO_TLSv1_2,NO_TLSv1_1). I know there could be many other reasons for such a failure but at least that would be a good starting point. Or even better... if Squid detects an SSL handshake failure with no extra info like in my case, can't it simply log an extra string that would look something like "Failed to negotiate SSL for unknown reason. Try setting ssloptions (cache_peer) or options (https_port) with a combination of NO_SSLv2 NO_SSLv3 NO_TLSv1 NO_TLSv1_1 NO_TLSv1_2. Find out which SSL protocol is supported by the remote peer. If the connection still fails then you will need to analyze traffic with the peer to find out the reason." In my case, that would have been enough info in Squid's log to fix the issue. Thanks again. Vieri _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
