Forma correcta de solicitar la renegociación de los parámetros con SSL

Question

Forma correcta de solicitar la renegociación de los parámetros con SSL

#1 de Thomas Pornin (2 votos)

4

Dada una conexión SSL / TLS específica, me gustaría saber cuál es la forma correcta de iniciar una renegociación de parámetros, solicitada desde el lado del cliente.

1) ¿Son requisitos del acuerdo anterior en los parámetros establecidos?

2) ¿Cuál es la estructura exacta del primer mensaje enviado por el cliente que solicita la renegociación?

3) ¿Cuáles son los siguientes mensajes intercambiados por el servidor y el cliente? Si son diferentes de un apretón de manos habitual, ¿de qué manera?

Gracias de antemano por sus respuestas

Preguntas adicionales después de la respuesta de Thomas Pornin:

A. Respecto a la RFC 5746

Ahora entiendo un poco mejor cómo funciona, sin embargo, todavía no entiendo por qué los parámetros de renegociación son un problema cuando un MITM lo lanza, de acuerdo con su enlace rfc5746 # section-1 . ¿Qué intereses tiene un MITM para solicitar una renegociación, ya que no sabrá de ninguna manera los secretos intercambiados (en particular, el secreto pre-maestro [PMS] enviado durante el ClientKeyExchanged).

Una vez que se realiza la renegociación, el MITM no tiene forma de descifrar los mensajes entrantes enviados desde el cliente / servidor.

Solo veo 2 posibilidades durante la renegociación para intercambiar el PMS:

o bien el MITM proporciona su certificado al cliente, de modo que el cliente encripte el PMS con el certificado MITM. En ese caso, el cliente lo detecta fácilmente, ya que no es el certificado que está esperando;
O bien, el MITM envía el certificado del servidor, pero en ese caso, el MITM no tendrá ninguna forma de descifrarlo y descifrar los siguientes mensajes intercambiados, ya que no habrá recuperado el PMS.

Entonces, ¿dónde está el problema de seguridad que permite cierta renegociación por el protocolo?

B. Respecto a la estructura

Usted subrayó que no había una estructura definida y precisa dada por el RFC. ¿Cómo el equipo de OpenSSL descubrió esto entonces? ¿Qué estructura eligieron?

tls openssl

pregunta Janie 21.07.2014 - 10:19

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls openssl

Autofirmar certificados de clientes y distribuirlos, ¿es el siguiente un buen procedimiento? ¿Podría Google Mail o Google Drive funcionar como una ruta de acceso a la red de una empresa?

score 2 · Accepted Answer

Consulte el estándar :

El cliente también puede enviar un ClientHello en respuesta a un HelloRequest o por iniciativa propia Con el fin de renegociar los parámetros de seguridad en una existente conexión.

(el énfasis es mío)

Entonces, el cliente envía un mensaje ClientHello cuando quiere realizar un nuevo protocolo de enlace. Este es el mismo mensaje que el cliente enviaría al abrir la conexión por primera vez, con el mismo contenido (excepto el punto que se detalla a continuación). No existe relación con el contenido del protocolo de enlace anterior, excepto que el ClientHello , y los mensajes subsiguientes hasta (e incluyendo) el siguiente ChangeCipherSpec , se envían dentro del contexto criptográfico actual. Esto significa que estos mensajes de intercambio se cifran y se envían a MAC con los algoritmos y claves que se han negociado durante el primer intercambio. Cuando el segundo protocolo de enlace llega a la etapa ChangeCipherSpec , los algoritmos y claves recientemente negociados reemplazan los que están en vigor hasta ese momento.

La ligera diferencia en ClientHello y ServerHello para un reavivamiento es la Extensión de indicación de renegociación : es un método por el cual un cliente puede (y debe) indicar si, desde su punto de vista, el saludo es el primero o un nuevo saludo dentro del contexto del actual. La introducción de RFC 5746 explica el problema que RIE pretende solucionar. Sin embargo, el problema estructural es que no existe una definición clara en ninguna de las propiedades de seguridad que se supone que debe proporcionar un nuevo intercambio de información; los implementadores han recurrido a adivinar , y el ataque para el que RFC 5746 es una contramedida demuestra que tales adivinanzas, como de costumbre, han salido mal.

(Una forma de verlo es que la seguridad del handshake forward : las garantías de seguridad de un TLS se transportan a handshakes subsiguientes. RIE intenta hacer que vayan también hacia atrás: cualquier autenticación que resulte del segundo Se considerará que un apretón de manos es lo suficientemente bueno para el intercambio de datos antes de ese segundo. Sin embargo, RFC 5746 no hace ninguna promesa real a ese efecto y no tengo conocimiento de ningún análisis coherente, coherente y completo del problema.)