tis 2012-02-14 klockan 12:20 +0000 skrev Alex Crow: > Strangely s_client without any additional parameters seems to work: > OpenSSL> s_client -connect applyonline.abbeynational.co.uk:443 > CONNECTED(00000003) Do not work for me when testing this site. $ openssl s_client -connect applyonline.abbeynational.co.uk:443 CONNECTED(00000003) 140471392831296:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 113 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Which version of OpenSSL are you testing with? $ openssl version OpenSSL 1.0.0g-fips 18 Jan 2012 > New, TLSv1/SSLv3, Cipher is RC4-MD5 And I get here if I enable SSLv2 ciphers, making OpenSSL send an SSLv2 formatted hello handshake. $ openssl s_client -connect applyonline.abbeynational.co.uk:443 -cipher 'ALL:!COMPLEMENTOFDEFAULT' [...] New, TLSv1/SSLv3, Cipher is RC4-MD5 > Unless that verify return code is a problem? For me it's not. > I really don't know where to go from here... Fire up wireshark and stare at any difference in the SSL handshake presented by OpenSSL when called by Squid compared to when using the openssl s_client command. Just tried, and it's sending a SSLv3/TLSv1 handshake even with the sslproxy_ciphers set to the same that works with openssl_sclient. But seriously, the right action is to complain to the site owners to have the site fixed. A SSLv3/TLSv1 server requiring the initial client hello handshake to be SSLv2 with SSLv3/TLSv1 chiphers and failing if seeing an SSLv3/TLSv1 handshake is just broken. Regards Henrik
