TLS Handshake se derriba

9

Estoy intentando depurar un protocolo de enlace TLS entre dos puntos finales de troncales SIP: .75 y .82. Se está utilizando la autenticación mutua.

.75 envía:

  
  • Cliente Hola
  •   
  • Certificado, intercambio de claves de cliente
  •   
  • Verificación de certificado, cambio de especificaciones de cifrado, mensaje de reconocimiento cifrado
  •   
  • Alerta cifrada
  •   

.82 envía:

  
  • Servidor Hello, Certificado, Solicitud de certificado, Servidor Hello Done
  •   
  • Cambiar la especificación de cifrado, el mensaje de protocolo de enlace cifrado
  •   
  • [FIN, ACK]
  •   

De la traza de wireshark en .75, los detalles de la Alerta encriptada son: Content Type: Alert (21)

¿Cómo sé qué causa la falla de 82?

    
pregunta Yusuf 16.07.2013 - 12:04
fuente

1 respuesta

8

Su máquina .75 (el cliente) envía un mensaje de "alerta cifrada". Si lo hace, entonces esta máquina, en ese momento, cree que la conexión todavía está en funcionamiento, y el servidor podrá recibir el mensaje de alerta y, en particular, descifrarlo. De lo contrario, ¿cuál sería el punto de enviar ese mensaje? Por lo tanto, es probable que el mensaje FIN del servidor se haya enviado después de recibir esta alerta. Posiblemente, el cliente envía una alerta que activa el cierre de la conexión, y el servidor reacciona cerrando el medio de transporte (el paquete FIN).

Tenga en cuenta que en un protocolo de enlace normal, el servidor esperará la recepción del mensaje Finished del cliente (el "mensaje de enlace cifrado" después del Change Cipher Spec ) antes de enviar sus propios Change Cipher Spec y Finished . Lo vemos aquí, por lo que el servidor pudo procesar el mensaje Finished del cliente, incluido el descifrado, la verificación de MAC y el contenido del mensaje.

Suponiendo que ambas implementaciones se ajustan a el estándar , el mensaje "alerta cifrada" es no es una advertencia close_notify . Un close_notify es un mensaje de alerta que advierte al destinatario de la intención del remitente de terminar la conexión con gracia. El destinatario debe responder con un close_notify propio, marcando su aceptación de ese hecho. Aquí, el cliente envía un mensaje de alerta, pero el servidor no responde a ningún mensaje de alerta, por lo que podemos suponer que no estamos presenciando una terminación elegante con un par de close_notify . Lo más plausible es que la alerta del cliente es una alerta fatal , que le dice al servidor que algo anda mal, y que la conexión está condenada. El servidor solo puede cerrar el medio de transporte porque no hay nada más que pueda hacer en ese momento.

No hay ninguna indicación en cuanto a qué molestó al cliente lo suficiente como para que envíe una alerta; sin embargo, hay indicios bastante decisivos de que todas las operaciones criptográficas fueron bien.

Es posible que desee ejecutar dos capturas de red en ambos sistemas, de modo que pueda obtener tiempos precisos para todos los paquetes; Ayuda a reconstruir la secuencia real de eventos.

    
respondido por el Thomas Pornin 16.07.2013 - 14:31
fuente

Lea otras preguntas en las etiquetas