----- Original Message ----- From: Amos Jeffries <squid3@xxxxxxxxxxxxx> > > 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. > >> # 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. > > Squid (mostly) avoids the whole class of vulnerabilities by leaving the > fallback decisions to the client whenever it can. Thank you very much for explaining all this. It's quite clear now. There's just one little thing that may be useful in the log, though. I might be wrong or maybe everyone already knows what to try when they get a non-informative SSL handshake error but it would have helped me to get a "hint" from Squid telling me to try fiddling with the ssloptions and options flags. I realize now it's great if Squid follows the secure logic of "There is a connection, which fails. The end.", but whenever that happens (and the info is 0, only "handshake error") wouldn't it be safe to just print a hint line in the server's log? Anyway, as I said before, I know what to do from now on so it's not a big deal. ;-) Thanks again, Vieri _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
