Henrik,
19/02/12 09:47, Henrik Nordström wrote:
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
openssl version
OpenSSL 0.9.8o 01 Jun 2010
Interestingly if I specify a servername I get the same (or similar) as you:
root@webproxy2:~# openssl s_client -connect
applyonline.abbeynational.co.uk:443 -cipher 'ALL:!COMPLEMENTOFDEFAULT'
-servername applyonline.abbeynational.co.uk
CONNECTED(00000003)
31274:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:188:
root@webproxy2:~#
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
Running the same as above seems for me exactly the same as without the
cipher options:
root@webproxy2:~# openssl s_client -connect
applyonline.abbeynational.co.uk:443 -cipher 'ALL:!COMPLEMENTOFDEFAULT'
CONNECTED(00000003)
depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=GB/ST=Buckinghamshire/L=Milton Keynes/O=GRUPO SANTANDER/OU=IT
Security Operations/CN=applyonline.abbeynational.co.uk
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International
Server CA - G3
1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International
Server CA - G3
i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFoDCCBIigAwIBAgIQTjHebyXhySJF0PmYv7PGHTANBgkqhkiG9w0BAQUFADCB
vDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDE2MDQGA1UEAxMt
VmVyaVNpZ24gQ2xhc3MgMyBJbnRlcm5hdGlvbmFsIFNlcnZlciBDQSAtIEczMB4X
DTExMDIxODAwMDAwMFoXDTEyMDIyNTIzNTk1OVowgaQxCzAJBgNVBAYTAkdCMRgw
FgYDVQQIEw9CdWNraW5naGFtc2hpcmUxFjAUBgNVBAcUDU1pbHRvbiBLZXluZXMx
GDAWBgNVBAoUD0dSVVBPIFNBTlRBTkRFUjEfMB0GA1UECxQWSVQgU2VjdXJpdHkg
T3BlcmF0aW9uczEoMCYGA1UEAxQfYXBwbHlvbmxpbmUuYWJiZXluYXRpb25hbC5j
by51azCCASEwDQYJKoZIhvcNAQEBBQADggEOADCCAQkCggEAaUp4WbQ0wQ2w0vAV
rSCIeH7e+C3TN9Fx2BLlndEYvDRYWyt44hSkYidrkppqiGMC9WCfRFd7HVqlKxey
6yZzNIV4vEHnvs62NPQcN9Fq3+FVONd6eBl83nY7GG2OUpYQoDkiVYu9XbdHy75Z
C5YAvnJqE+b1eHCeIu06kGdE0fK9j+FUsbyeS/MaP77M/ymPsKhr9N4LWlQdtlnn
g0/U32jq8IwZ73XcLLTtRe7ScpkOkgYyhwFrfSdaCM/kygrfJahUzur1rq438J8b
FwakDBH/p4opnCCCP3UCjSw7drtIlKi7Z3lQ+xkYmSICKiPhLtchsyWFRBrVe36r
72po1QIDAQABo4IBszCCAa8wCQYDVR0TBAIwADALBgNVHQ8EBAMCBaAwQQYDVR0f
BDowODA2oDSgMoYwaHR0cDovL1NWUkludGwtRzMtY3JsLnZlcmlzaWduLmNvbS9T
VlJJbnRsRzMuY3JsMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwMwKjAoBggrBgEF
BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAoBgNVHSUEITAfBglg
hkgBhvhCBAEGCCsGAQUFBwMBBggrBgEFBQcDAjByBggrBgEFBQcBAQRmMGQwJAYI
KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlzaWduLmNvbTA8BggrBgEFBQcwAoYw
aHR0cDovL1NWUkludGwtRzMtYWlhLnZlcmlzaWduLmNvbS9TVlJJbnRsRzMuY2Vy
MG4GCCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4D
AhoEFEtruSiWBgy70FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWdu
LmNvbS92c2xvZ28xLmdpZjANBgkqhkiG9w0BAQUFAAOCAQEAVTT7cczhZ0mVVRHn
4pLe4780UCOIlXDyABI23B1XdZBm6fUcVB+JKPKpD6J31iSXnWuHdb6sjMLfzq45
1XFZ/v6wB2cvK2KMeAvedDp+1/R2HoCjrPPOFS42HEFks7kQ2/xaV2gHYOVnoG/V
RwvT94vtI1xUZAs87QxLUtvGcedcQnHyCmt3Wp5xTll7/czrYSLZFuELfPeckQ4v
ZI0XuWn1uwVURn7pfpK62044Zg6Zwz9gsicHbHavgUZds+dKSLKPPzV4ElJT9kzJ
E1lWAUgpMppmYJdJxJUJ5nOAi5P355Mp/TAsj2BU/QSzxodwvE0vW7+TBb5b9nrj
gZCdzQ==
-----END CERTIFICATE-----
subject=/C=GB/ST=Buckinghamshire/L=Milton Keynes/O=GRUPO SANTANDER/OU=IT
Security Operations/CN=applyonline.abbeynational.co.uk
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International
Server CA - G3
---
No client certificate CA names sent
---
SSL handshake has read 4982 bytes and written 431 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2047 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID:
0000B79232B42C2298F70DA4D4A45E0EA4410490585858584F41469200000030
Session-ID-ctx:
Master-Key:
81A71B010B49871DE1DD86782FBBA28834C12D78363C4DB1E8DD116D17D5A447E196C2B5F89AC49AFC3A8C0FF0663CC0
Key-Arg : None
Start Time: 1329677743
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
^C
root@webproxy2:~#
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.
OK, so squid *is* behaving differently from OpenSSL s_client.
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.
Hmm, I can try, but I can't imaging someone like Santander giving two
hoots about an organisation of our size... and we have about 15 more
"big" corporate sites we contact that behave in a similar fashion.
Regards
Henrik
Many thanks
Alex
