On 27/01/2017 9:31 p.m., Vieri wrote: > > > > > ----- 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. Let me pause you right there. What you describe is essentially how the TLS protocol handshake is actually performed. > 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. That is exactly what happens. > 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? Several reasons. Reason #1 is that the TLS protocol is a security protocol for securing a single 'hop' (just one TCP connection). So ideally TLS details would not be remembered at all, it's a dangerous thing in security to remember details in the middleware. Reason #2 is that Squid has passed on the 'terminate' signal to the client (curl). As far as Squid is concerned, there is no "again" connection. There is a connection, which fails. The end. There is a connection. Which fails. The end. There is a connection. Which fails. The end. ... and so on. These connections may be from the same client, or different ones. May be to same or different servers. They are independent of each other and only TCP at this point. The TLS setup/handshake parts never get far enough for there to be anything to remember. Except that TCP connection failed. Well, Squid does remember that and tries a different IP next time. Until it runs out of IPs, then it resets its bad-ID memory with a new DNS lookup and the cycle begins again. NP: if you are interested you can see the GOOD/BAD flags on IPs in the ipcache cache manager report (squidclient mgr:ipcache). > 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 > Which brings us to reason #3; downgrade attacks. You may have heard of the POODLE attack. It is basically a middleware (like Squid) forcing the other endpoint(s) to re-try with lower TLS versions until a version is reached and cipher selected that the attacker can decrypt or steal the keys from. Squid (mostly) avoids the whole class of vulnerabilities by leaving the fallback decisions to the client whenever it can. Since the curl command only did the one request, that is all that happened. No retry. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
