Re: [squid-users] SSLBump SSL error (FAO Henrik)

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