0

I have an old CentOS 5.11 system running OpenSSL 0.9.8e. I am able to connect most SSL sites with no problem. However with some sites like www.looklinux.com, if I try to connect I get this error:

openssl s_client -connect www.looklinux.com:443  
CONNECTED(00000003)  
27080:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure:s23_clnt.c:586:

Now, from doing

openssl s_client -connect www.google.com:443 | grep -i "protocol"  

I see Protocol : TLSv1 in the output. And from
https://www.ssllabs.com/ssltest/analyze.html?d=www.looklinux.com&latest
I know that www.looklinux.com supports TLS 1.0, 1.1 and 1.2. So it seems the client and server share at least one compatible protocol (TLS v1) and that's not the problem. Am I right so far?

Then, what's going wrong and how can I fix it?

When I run it with the -debug flag I get:

openssl s_client -connect www.looklinux.com:443 -debug
CONNECTED(00000003)
write to 0x872a198 [0x87665b8] (88 bytes => 88 (0x58))
0000 - 16 03 01 00 53 01 00 00-4f 03 01 5b 05 ff fc 97   ....S...O..[....
0010 - 78 87 a5 97 77 11 57 60-1b e0 ae 9f 81 8c c6 c6   x...w.W`........
0020 - 15 3c fb 0b ef 3e d7 20-8a 83 3b 00 00 28 00 39   .<...>. ..;..(.9
0030 - 00 38 00 35 00 16 00 13-00 0a 00 33 00 32 00 2f   .8.5.......3.2./
0040 - 00 05 00 04 00 15 00 12-00 09 00 14 00 11 00 08   ................
0050 - 00 06 00 03 00 ff 01                              .......
0058 - <SPACES/NULS>
read from 0x872a198 [0x876bb18] (7 bytes => 7 (0x7))
0000 - 15 03 01 00 02 02 28                              ......(
1678:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:586:

This post:
https://stackoverflow.com/questions/48983918/authorize-net-gem-tls-1-2-compatibility
suggests that sometimes an older version of OpenSSL is just not compatible. Is it easy to explain what it is that the older OpenSSL can't do? And is there really no workaround? I'm wary of "updating" it by building OpenSSL from source, because instructions to build from source usually have errors or omissions, where an expert reader knows what the instructions were supposed to say, but I follow the directions exactly and get hosed. So I'm hoping I can fix this by just installing an extra certificate, or something.

  • The error means the server could not choose from your supported suites. I'd like to see what cipher suites you are proposing to the server. So running it with the -debug flag and posting that output here would be a very, very good first move towards, you know, debugging the error. – J.A.K. May 23 '18 at 23:24
  • Thanks @J.A.K. I updated the question to include the output when I run the command with the -debug flag but I do not see anywhere where it indicates the list of cipher suites being sent. – Bennett May 24 '18 at 0:00
  • I can see the SSL3 error, nothing related to TLS. Seems like you have OpenSSL without TLS support. – Fis May 24 '18 at 1:03
  • @Fls: the function name and explanatory string in the error message do not reflect the actual protocol. All OpenSSL 0.9.8 (and 0.9.7 for that matter) support TLS1.0 (though not higher) and you can see in the message that it is used on this connection: 16 03 01 00 xx is a TLS1.0 handshake message (here ClientHello) and 15 03 01 00 02 is a TLS1.0 alert message. – dave_thompson_085 May 24 '18 at 3:39
2

This problem is not related to certificates in any way and cannot be fixed by a certificate.

The SSLLabs report shows that server supports only suites using ECDHE_ECDSA keyexchange, i.e. Elliptic Curve Cryptography. Upstream OpenSSL 0.9.8 did implement ECC, but disabled it by default and you had to read the source to find the magic word ECCdraft to enable it. However, RedHat and therefore CentOS removed (all) ECC from packages built before about two years ago, so that probably won't work for you. You can fairly easily see that the list of offered suites in your ClientHello (hex offset 2E to 56) does not contain any bytepairs in the range C0xx where all the ECC suites are.

In addition, as noted on the SSLLabs report, "This site works only in browsers with SNI support." and OpenSSL does not send SNI by default; you must specify the option -servername $hostname -- which does work in 0.9.8.

However, my 0.9.8zg with ECCdraft and -servername still gets alert 40. The only difference I can find between that and 1.0.0s (with -servername) which does work is that 1.0.0 sends the pointformats (0xB) and curves (0xA) extensions and 0.9.8 does not -- but according to rfc4492 they are supposed to be optional. So even if you had an un-nobbled 0.9.8 you might be out of luck.

I have never had any problem building OpenSSL itself from source on any decent Unix; it's actually one of the simplest packages to build I've experienced. However, you would also need to rebuild everything on your system you want to use the updated OpenSSL, and depending on what those things are that could be much more difficult, especially where source changes are required, as they were in some cases going from 0.9.8 to 1.0.x (and much more from 1.0.x to 1.1.0 if you wanted to move up that radically).

Depending on what you are doing, you might be able to route your traffic through an external SSL/TLS proxy, like squid+bump, that accepts the grimy faded old TLS (or even SSL) you can do, and relays your data to and from other systems using shiny glittery newfangled TLS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.