9

We encounter very strange problems connecting with openssl or curl to one of our servers, from Ubuntu 14.04

Executing:

openssl s_client -connect ms.icometrix.com:443

gives:

CONNECTED(00000003)
140557262718624:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error:s23_clnt.c:770:

A similar error when executing:

curl https://ms.icometrix.com
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error

Output of openssl version (on client/server): 

OpenSSL 1.0.1f 6 Jan 2014

Output of openssl from dpkg -l openssl:

1.0.1f-1ubuntu2

The funny thing is, the problem vanishes when connecting with other versions of Openssl:

  • From a mac, OpenSSL 0.9.8zd 8 Jan 2015, all ok
  • From centos, OpenSSL 1.0.1e-fips 11 Feb 2013, all ok
  • Latest stable release on Ubuntu 14.04, OpenSSL 1.0.2d 9 Jul 2015, all ok.

From server side, we do not see anything strange. The problem started when we disabled SSL3 on our machines.

Might there be a problem with the build in the apt-get?

We also test other versions, the one proposed by apt-cache showpkg, but the problem remains...

cecemel
  • 193

1 Answers1

4

This looks like a problem with ECDH support between client and server. If you exclude all ECDH ciphers it works:

openssl s_client -connect ms.icometrix.com:443 -cipher 'DEFAULT:!ECDH'

My guess is that the server croaks on some of the 25 ECC curves offered by the client. Browsers only offer few curves. OpenSSL 0.9.8 does not support any ECC yet and RedHat/CentOS has a history of disabling ECC by default for patent reasons. I don't know why OpenSSL 1.0.2 works since I don't have access to this version.

Please note that giving the OpenSSL version is usually not enough because all the distributions keep older versions but add security patches. Instead check with dpkg -l openssl which gives 1.0.1f-1ubuntu2.15 on my system.

Steffen Ullrich
  • 1,626