¿Cómo se ha solucionado la renegociación de TLS?

6

He leído RFC 5746 en la extensión de renegociación segura TLS. Sin embargo, no entiendo cómo soluciona el problema.

Se requiere que el cliente y el servidor incluyan los datos_controides del protocolo de enlace anterior en los mensajes de ClientHello y ServerHello. La solución protege contra un atacante que es un MITM activo. ¿No podría este atacante simplemente incluir su Verify_data en el ClientHello que intercepta del cliente (recuerde, todo esto está sin firmar, el intercambio de claves está en marcha) y quitar la verificación del servidor ServerHello con la que responde? De esta manera, el servidor pensará que se está realizando una renegociación segura, mientras que el cliente verá un campo vacío de conexión renegociada que se corresponde con el hecho de que está iniciando una nueva conexión.

Mi razonamiento debe ser incorrecto, ¿alguien puede señalarlo?

    
pregunta chris 09.12.2011 - 10:50
fuente

1 respuesta

10

En un protocolo de enlace TLS, los mensajes "Terminados" contienen un valor que es un hash de todos los mensajes intercambiados hasta el momento (para este protocolo de enlace). Si el atacante altera el ClientHello, el hash no coincidirá: cuando se complete el segundo saludo (el primer y único saludo en la vista del cliente, el segundo saludo desde el punto de vista del servidor), el cliente envía un 'Finalizado 'mensaje que el atacante no puede modificar (está encriptado & MAC con la clave recién negociada), y ese mensaje contiene una computadora hash sobre, entre otras cosas, el ClientHello que el cliente envió . Si el servidor vio un ClientHello distinto (uno sin la extensión de renegociación), calculará un hash distinto, el contenido "Finalizado" no coincidirá y la conexión se cancelará.

    
respondido por el Thomas Pornin 09.12.2011 - 14:40
fuente

Lea otras preguntas en las etiquetas