SSL Handshake falló

5

Estoy trabajando en la aplicación de escritorio de Windows que se crea utilizando C ++ (IDE: creador de Qt). Tiene un panel de inicio de sesión, donde hago la validación del usuario a través de la conexión https usando la biblioteca openssl 1.0. La aplicación funciona en la mayoría de las máquinas, pero también estoy experimentando el error "SSL Handshake failed" al hacer la conexión https desde pocas máquinas.

Intenté depurar el error usando wireshark. Mi observación es la siguiente:

1) El cliente envía [SYN] al servidor.
2) El servidor envía [SYN, ACK] al cliente.
3) El cliente envía [ACK] al servidor.
4) El cliente envía el mensaje "Cliente Hola" al servidor.
5) El servidor envía su clave pública con el mensaje "Servidor Hola, Certificado, Servidor Hola Hecho"
6) El cliente envía su clave pública con el mensaje "Intercambio de claves del cliente, Cambiar espec. De cifrado, Mensaje cifrado de reconocimiento"
7) El servidor envía un mensaje de protocolo de enlace cifrado con el mensaje "Cambiar espec. De cifrado, mensaje de protocolo de enlace cifrado"
8) El cliente envía [FIN, ACK]
9) El servidor envía [FIN, ACK]
10) El cliente envía [FIN]

En el séptimo paso, tan pronto como el cliente recibe un mensaje cifrado del servidor, el cliente inicia la terminación del protocolo de enlace mediante la señal FIN. ¿Alguna idea, por qué el cliente desmonta la conexión ssl con "SSL handshake failure" después de que ambas partes intercambian las claves?

    
pregunta ram 05.02.2014 - 08:42
fuente

2 respuestas

7

Su descripción del protocolo de enlace parece indicar que el cliente y el servidor realizaron el protocolo de enlace completamente, y luego el cliente abandonó la conexión. Esto significa que "algo" no era correcto desde el punto de vista del cliente. En su mayoría hay dos posibles candidatos:

  1. El certificado enviado por el servidor no es "correcto"; El cliente decidió que es necesaria alguna validación de usuario. El cliente completó el protocolo de enlace para que pueda volver a abrir la sesión SSL con un "protocolo de enlace abreviado" más rápido (reutilizando el "secreto maestro" negociado sin tener que recurrir al cripto asimétrico de nuevo), pero cerró la conexión para no mantener los recursos abiertos. el servidor mientras que el usuario humano se decide (la bolsa de carne es slow ).

  2. El mensaje Finished enviado por el servidor (que es el "mensaje de saludo cifrado") contiene un valor incorrecto (desde el punto de vista del cliente) debido a algún error (probablemente en el cliente). Esto no es una ocurrencia muy probable.

Mi conjetura es que usted está en el primer caso: el servidor utiliza una cadena de certificados que "no es buena" para el cliente. Culpables habituales:

  • La cadena de certificados del servidor no se enlaza con una de las "raíces confiables" del cliente (según la biblioteca utilizada en el cliente, la lista de raíces puede estar en varios lugares).
  • El servidor nombre , como lo esperaba el cliente (el que está en su URL) no coincide con los nombres en el certificado del servidor.
  • El reloj del cliente está totalmente apagado, por lo que rechaza algunos certificados que, desde su punto de vista, se emiten "en el futuro" o caducan por mucho tiempo.
respondido por el Tom Leek 05.02.2014 - 15:30
fuente
4

exportar el certificado del servidor a la máquina cliente a un archivo como servercert.crt. En la ejecución del cliente: certutil -verify -urlfetch servercert.crt

Es casi seguro que le dirá por qué la cadena de certificados del servidor no se consideró válida. Saludos

    
respondido por el lsousa 24.04.2014 - 16:48
fuente

Lea otras preguntas en las etiquetas