En el protocolo de enlace TLS 1.3, ¿se puede interpretar un error interno en el cliente como un error de descifrado en el servidor?

2

En el protocolo de protocolo de enlace TLS 1.3, el cliente envía el mensaje de ClientHello al servidor. Luego, el servidor devuelve el mensaje de ServerHello seguido de algunos mensajes cifrados. El cliente luego calcula las claves y envía algunos otros mensajes cifrados al servidor para completar el protocolo de enlace.

Ahora, ¿qué sucede si se produce un error mientras el cliente está calculando claves? Digamos que es un error interno. El cliente debe enviar una alerta fatal de "Error interno" al servidor y luego cerrar la conexión. El mensaje de alerta no está cifrado porque el cliente no computa las claves con éxito. Sin embargo, el servidor ya calculó las claves con éxito y cambió la especificación de cifrado, por lo que el servidor espera que todos los mensajes entrantes se cifren. Por lo tanto, se producirá un error de descifrado cuando intente descifrar el mensaje de alerta sin cifrar del cliente. Efectivamente, un error interno en el cliente se convierte en un error de descifrado cuando llega al servidor. ¿Es este un comportamiento aceptable?

    
pregunta Tu Le Hong 25.02.2018 - 04:47
fuente

1 respuesta

2

Está asumiendo que puede ocurrir algún error que hace imposible que el cliente calcule las claves correctamente. Suponiendo que el cliente y el servidor hayan completado el handshake hasta el momento de manera correcta, de modo que los datos de entrada para el cálculo de las claves estén disponibles en el cliente y sean correctos. Además, asumiendo que no hay errores de implementación. En este caso, es muy improbable que ocurra algún error durante el cálculo de las claves, es decir, probablemente solo una condición de memoria insuficiente o algunos problemas relacionados con el hardware. Incluso podría ser que el cliente no pueda enviar un mensaje al servidor en tal situación. Creo que está perfectamente bien si, en este caso raro, el servidor no puede distinguir entre un mensaje de "error interno" del cliente y un mensaje dañado del cliente o una conexión cerrada sin ningún mensaje, ya que la cantidad de información útil es sobre la Lo mismo: algo no especificado salió mal.

Aparte de eso, las alertas enviadas al interlocutor no contienen mucha información útil en primer lugar. Dado que no hay un mensaje de error real, pero solo un solo número de error, solo puede apuntar en la dirección de la posible causa de un error pero no describirlo en detalle. Y al observar cómo se usó este protocolo de alerta en TLS 1.2 y más bajo en las implementaciones reales, existe una gran probabilidad de que sea similar en su mayoría inútil en TLS 1.3: existen implementaciones importantes que simplemente cierran la conexión por error en lugar de enviar una alerta. atrás. Otras implementaciones simplemente envían un handshake_failure genérico en la mayoría de los casos, aunque hay más tipos de alerta exactos disponibles para el error en particular.

    
respondido por el Steffen Ullrich 25.02.2018 - 07:11
fuente

Lea otras preguntas en las etiquetas