SSL ¿está negociando un protocolo demasiado bajo?

Question

SSL ¿está negociando un protocolo demasiado bajo?

#1 de Tom Leek (5 votos)

3

Estoy tratando de diagnosticar un problema potencial de SSL / TLS entre un cliente Mac y un servidor Windows. He generado mi propio certificado raíz y he firmado un certificado para el servidor, e instalé el certificado raíz en el cliente Mac. Cuando intento conectarme al servidor desde el mac como este

echo quit | openssl s_client -connect newmail.example.com:443 -CAfile ~/Downloads/myroot.cer

Veo estos resultados

---
SSL handshake has read 1365 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: DE2800000D2050CAB6CEE9136CD377998559C46C7AD57A1062907EE417457DE0
    Session-ID-ctx: 
    Master-Key: 24E2BE661880D703B7033E0F723323296C26ECEDA0BA79493AE134C7F03EEBD765692C9DF10933BE213FF4E0F89771AC
    Key-Arg   : None
    Start Time: 1458249776
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE

¿Estos resultados significan que el nivel MÁS ALTO de protocolo negociado es TLSv1? (Lo que sospecho está causando mi problema de aplicación)? ¿No debería ser esto TLS 1.2?

tls certificates certificate-authority

pregunta TSG 17.03.2016 - 22:29

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls certificates certificate-authority

¿Qué tan difícil es forzar la encriptación de Windows EFS? ¿Hay dispositivos de borrado rápido con una pequeña memoria disponible para almacenar información clave?

score 5 · Accepted Answer

La versión del protocolo es el resultado de una negociación entre el cliente y el servidor. El cliente envía, en ClientHello , la versión máxima que admite; entonces el servidor responde con la versión que será utilizada. Normalmente, el servidor seleccionará la versión de protocolo más alta que admita y no es superior a la versión máxima anunciada por el cliente.

Aquí, con la herramienta de línea de comandos openssl como cliente, tienes TLS 1.0. Por lo tanto, el cliente (aquí, OpenSSL) o el servidor solo conocen TLS 1.0 y no 1.2.

La herramienta /usr/bin/openssl enviada con OS X es bastante antigua; en una instalación actualizada de OS X (El Capitán), es OpenSSL-0.9.8zg - este es un antiguo OpenSSL con correcciones de errores, pero no admite funciones agregadas en las versiones OpenSSL-1. *. En particular, no hay TLS 1.1 o 1.2. Lo que explica que, con OpenSSL, solo obtienes 1.0.

(OS X no actualiza OpenSSL a las versiones más nuevas porque los desarrolladores de OpenSSL rompieron la compatibilidad hacia atrás en la API, por lo que cambiar la versión de la biblioteca puede romper aplicaciones existentes de terceros que lo utilizan).

Para investigar más a fondo su problema , sugiero lo siguiente:

Prueba con un cliente openssl más nuevo. Puede usar MacPorts (por ejemplo) para instalar dicho software de fuente abierta de manera razonablemente fácil.
Es posible que desee probar su servidor con una de las herramientas que están dedicadas a tal propósito. Si puede acceder a su servidor desde Internet, Qualys SSL Labs es el método habitual. Para servidores en redes privadas, también hay herramientas de línea de comandos como testssl.sh o TestSSLServer que puede proporcionarle información.
Debe observar un intento de protocolo de enlace SSL con una aplicación de monitoreo de red (por ejemplo, Network Monitor en el servidor de Windows, o Wireshark ). Esto revelará si el cliente intenta iniciar un apretón de manos, qué versiones / conjuntos de cifrado envía y qué responde el servidor.

Tal rastro también puede revelar otras cosas, como intentos fallidos de descargar CRL como parte como validación de certificado en el lado del cliente.