Nos encontramos con problemas muy extraños al conectar con openssl o curl a uno de nuestros servidores, desde Ubuntu 14.04
Ejecutando:
openssl s_client -connect ms.icometrix.com:443
da:
CONNECTED(00000003)
140557262718624:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error:s23_clnt.c:770:
Un error similar al ejecutar:
curl https://ms.icometrix.com
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error
Salida de la versión de openssl (en cliente/servidor):
OpenSSL 1.0.1f 6 Jan 2014
Salida de openssl desde dpkg -l openssl:
1.0.1f-1ubuntu2
Lo curioso es que el problema desaparece al conectarse con otras versiones de Openssl:
- Desde Mac, OpenSSL 0.9.8zd 8 de enero de 2015, todo bien
- De centos, OpenSSL 1.0.1e-fips 11 de febrero de 2013, todo bien
- Última versión estable en Ubuntu 14.04, OpenSSL 1.0.2d del 9 de julio de 2015, todo bien.
Desde el lado del servidor, no vemos nada extraño. El problema comenzó cuando desactivamos SSL3 en nuestras máquinas.
¿Podría haber algún problema con la compilación en apt-get?
También probamos otras versiones, la propuesta por apt-cache showpkg, pero el problema persiste...
Respuesta1
Esto parece un problema con el soporte ECDH entre el cliente y el servidor. Si excluye todos los cifrados ECDH, funciona:
openssl s_client -connect ms.icometrix.com:443 -cipher 'DEFAULT:!ECDH'
Supongo que el servidor croa en algunas de las 25 curvas ECC ofrecidas por el cliente. Los navegadores sólo ofrecen algunas curvas. OpenSSL 0.9.8 aún no admite ningún ECC y RedHat/CentOS tiene un historial de deshabilitar ECC de forma predeterminada por motivos de patentes. No sé por qué funciona OpenSSL 1.0.2 ya que no tengo acceso a esta versión.
Tenga en cuenta que proporcionar la versión OpenSSL generalmente no es suficiente porque todas las distribuciones mantienen versiones anteriores pero agregan parches de seguridad. En su lugar, verifique dpkg -l opensslcuál proporciona 1.0.1f-1ubuntu2.15 en mi sistema.