¿Por qué es necesario el mensaje CertificateVerify? (¿Por qué no se realiza la autenticación del cliente a través del KeyExchange)

Question

¿Por qué es necesario el mensaje CertificateVerify? (¿Por qué no se realiza la autenticación del cliente a través del KeyExchange)

#1 de ytf (0 votos)

1

¿Por qué no se realiza la autenticación del cliente a través de KeyExchange como con el servidor, sino a través de un mensaje CertificateVerify ?

EDITAR: Para ser más claros:
Cuando se utiliza el intercambio de claves RSA, el cliente cifra el material de la clave con la clave pública del servidor para que solo el servidor real (que tiene la clave privada) pueda descifrarla. [ RFC5246: 7.4.7.1 ] ¿Por qué el cliente tampoco firma la clave? ¿Material con su clave privada al usar la autenticación de cliente?

Cuando se utiliza el intercambio de claves Diffie-Hellman, el servidor firma sus parámetros clave utilizando su clave privada para probar que tiene la clave privada (y, por lo tanto, es el servidor real). [ RFC5246: 7.4.7.2 ] ¿Por qué el cliente no firma sus parámetros también? ¿Cuándo se usa la autenticación de cliente?

En lugar de estos métodos (creo que más lógicos), el cliente envía un mensaje de CertificateVerify con una firma en todos los mensajes de intercambio. ¿Por qué se elige este método?

EDITAR: Esto solo se aplica a los certificados con capacidad de firma, porque con por ejemplo. la autenticación de cliente de certificados DH estáticos se realiza durante KeyExchange. [ RFC5246: 7.4.8 ]

authentication tls certificates

pregunta SWdV 08.01.2016 - 22:22

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication tls certificates

¿Cuál es el propósito de incluir el desove del proceso? ¿Riesgos de informar al usuario si el nombre de usuario no es válido? [duplicar]

score 0 · Accepted Answer

Tu idea no funciona. El hecho de poder firmar el material clave no prueba que el cliente tenga la clave privada correspondiente al certificado.

La autenticación generalmente se realiza mediante un protocolo de desafío-respuesta en el que una parte presenta una pregunta y la otra parte proporciona una respuesta válida para demostrar que conoce la regla de transformar preguntas en respuestas. El material clave (aquí actúa como la pregunta) en el ClientKeyExchange está determinado únicamente por el cliente, mientras que el servidor no tiene ningún control sobre él. Así que es como hacer que el cliente responda a su propia pregunta. Sin conocer la "regla" (la clave privada), el cliente todavía puede proporcionar una respuesta válida (material de clave firmado). Por ejemplo, un atacante puede tomar el certificado y el material de clave firmado de otro cliente y luego hacerse pasar por ese cliente cuando se comunica con el servidor. Para obtener el certificado y el material clave firmado de la víctima, el atacante puede establecer su propio servidor y hacer que alguien se conecte con él.

En realidad, el hash firmado en el mensaje CertificateVerify incluye información tanto del cliente como del servidor (es decir, la "pregunta" está determinada por ambos lados). Así que el cliente no está respondiendo a su propia pregunta.
La autenticación del cliente es opcional en una transacción SSL / TLS. Teniendo en cuenta la claridad y la facilidad de implementación, no es una buena idea tener un mensaje de dos formas.

El mensaje CertificateVerify no es estrictamente necesario. Está bien combinarlo en ClientKeyExchange siempre que los materiales a firmar se seleccionen cuidadosamente. Sin embargo, es mejor tener un mensaje separado, ya que juega un papel independiente. Por cierto, un mensaje separado no necesariamente cuesta un segmento TCP adicional. Es muy común incrustar varios mensajes en un segmento, por lo que un mensaje separado no introducirá costos adicionales.