Nos encontramos con problemas muy extraños al conectarnos 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 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 cuando se conecta con otras versiones de Openssl:
- Desde una Mac, OpenSSL 0.9.8zd 8 de enero de 2015, todo bien
- Desde 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 9 de julio de 2015, todo bien.
Desde el lado del servidor, no vemos nada extraño. El problema comenzó cuando deshabilitamos SSL3 en nuestras máquinas.
¿Podría haber un problema con la compilación en apt-get?
También probamos otras versiones, la propuesta por apt-cache showpkg, pero el problema continúa ...
curl --sslv3 https://ms.icometrix.com
?Respuestas:
Esto parece un problema con el soporte ECDH entre el cliente y el servidor. Si excluye todos los cifrados ECDH, funciona:
Supongo que el servidor no funciona en algunas de las 25 curvas ECC ofrecidas por el cliente. Los navegadores solo ofrecen pocas curvas. OpenSSL 0.9.8 todavía no es compatible con ECC y RedHat / CentOS tiene un historial de deshabilitación de ECC por defecto por razones de patentes. No sé por qué OpenSSL 1.0.2 funciona ya que no tengo acceso a esta versión.
Tenga en cuenta que dar la versión OpenSSL generalmente no es suficiente porque todas las distribuciones mantienen versiones anteriores pero agregan parches de seguridad. En su lugar, verifique con
dpkg -l openssl
cuál da 1.0.1f-1ubuntu2.15 en mi sistema.fuente