depurando por qué TLS falla entre openssl y algunos sitios SSL

Navega tus respuestas
0

Tengo un sistema CentOS 5.11 antiguo que ejecuta OpenSSL 0.9.8e. Soy capaz de conectar la mayoría de los sitios SSL sin ningún problema. Sin embargo, con algunos sitios como www.looklinux.com, si intento conectarme recibo este 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:

Ahora, de hacer 

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

Veo Protocol : TLSv1 en la salida. Y de
enlace
Sé que www.looklinux.com es compatible con TLS 1.0, 1.1 y 1.2. Así que parece que el cliente y el servidor comparten al menos un protocolo compatible (TLS v1) y ese no es el problema. Estoy en lo cierto hasta ahora?

Entonces, ¿qué está mal y cómo puedo solucionarlo?

Cuando lo ejecuto con el indicador -debug , obtengo: 

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:

Esta publicación:
enlace
sugiere que a veces una versión anterior de OpenSSL simplemente no es compatible. ¿Es fácil explicar qué es lo que OpenSSL no puede hacer? ¿Y realmente no hay solución? Desconfío de "actualizarlo" construyendo OpenSSL desde la fuente, porque las instrucciones para compilar desde la fuente generalmente tienen errores u omisiones, donde un lector experto sabe lo que se supone que las instrucciones supuestamente dicen, pero sigo Exactamente las direcciones y la manguera. Así que espero poder solucionar este problema simplemente instalando un certificado adicional, o algo así.

    
pregunta Bennett 24.05.2018 - 01:10
fuente

1 respuesta

2

Este problema no está relacionado con los certificados de ninguna manera y no se puede solucionar con un certificado.

El informe de SSLLabs muestra que el servidor solo admite suites que usan el intercambio de claves ECDHE_ECDSA, es decir, Criptografía de curva elíptica . Upstream OpenSSL 0.9.8 implementó ECC, pero lo deshabilitó de forma predeterminada y tuvo que leer la fuente para encontrar la palabra mágica ECCdraft para habilitarla. Sin embargo, RedHat y, por lo tanto, CentOS eliminó (todos) ECC de paquetes creados hace unos dos años, por lo que probablemente no funcionará para usted. Puede ver con bastante facilidad que la lista de suites ofrecidas en su ClientHello (desplazamiento hexadecimal 2E a 56) no contiene ningún par de bytes en el rango C0xx donde se encuentran todas las suites de ECC.

Además, como se indica en el informe de SSLLabs, "Este sitio solo funciona en los navegadores que admiten SNI". y OpenSSL no envía SNI por defecto; debe especificar la opción -servername $hostname , que funciona en 0.9.8.

Sin embargo, mi 0.9.8zg con ECCdraft y -servername todavía recibe alerta 40. La única diferencia que puedo encontrar entre eso y 1.0.0s (con -servername ) que funciona es que 1.0.0 envía las extensiones pointformats (0xB) y curvas (0xA) y 0.9.8 no, pero según rfc4492 se supone que son opcionales. Por lo tanto, incluso si tuvieras un 0.9.8 sin canjear, es posible que no tengas suerte.

Nunca he tenido ningún problema al crear OpenSSL desde la fuente en cualquier Unix decente; En realidad, es uno de los paquetes más simples de compilación que he experimentado. Sin embargo, también necesitaría reconstruir todo lo que en su sistema quiera usar el OpenSSL actualizado, y dependiendo de qué cosas sean mucho más difíciles, especialmente cuando se requieren cambios en la fuente, ya que en algunos casos, pasamos de 0.9.8 a 1.0.x (y mucho más de 1.0.x a 1.1.0 si quisieras subir radicalmente).

Dependiendo de lo que esté haciendo, podría ser capaz de enrutar su tráfico a través de un proxy SSL / TLS externo, como squid + bump, que acepta el TLS antiguo (o incluso SSL) descolorido y sucio puede hacerlo, y transmite sus datos hacia y desde otros sistemas mediante el uso de TLS.     

respondido por el dave_thompson_085 24.05.2018 - 05:38
fuente

Lea otras preguntas en las etiquetas

Correo electrónico sin metadatos: ¿Cómo puede SENDER enviar de forma directa, anónima y segura al proveedor de correo del RECIPIENT para que envíe un correo electrónico sin metadatos? ¿Es seguro abrir archivos pdf "sospechosos" en una máquina virtual? [duplicar]