¿Por qué es TLS_FALLBACK_SCSV seguro contra un ataque MITM?

18

Se recomienda, para mitigar POODLE, si SSLv3 no se puede desactivar por completo, para utilizar TLS_FALLBACK_SCSV, un valor de conjunto de cifrado de señalización que indica que se ha producido un repliegue. El borrador de la norma para él dice:

  

Si TLS_FALLBACK_SCSV aparece en ClientHello.cipher_suites y el         La versión de protocolo más alta admitida por el servidor es más alta que         La versión indicada en ClientHello.client_version, el servidor.         DEBE responder con una alerta de caída inadecuada.

La idea, como la entiendo, es que si el cliente ha intentado y fracasado en la negociación de una conexión con, por ejemplo, TLS 1.2 (posiblemente porque un MITM ha forzado esta situación en un ataque de degradación de protocolo), el servidor será capaz de detectar la situación porque este valor de señalización estará presente en la lista de conjuntos de cifrado.

No estoy muy familiarizado con la negociación de TLS, y no entiendo por qué no sería posible que el atacante también manipule la lista de conjuntos de cifrado para eliminar este valor de señalización.

Por ejemplo, el cliente intenta conectarse al servidor con TLS 1.1, pero Mallory el MITM intercepta y falsifica una falla. Y lo hace de nuevo cuando el cliente intenta conectarse con TLS 1.0. Cuando el cliente intenta conectarse con SSL 3.0, Mallory elimina TLS_FALLBACK_SCSV de las suites de cifrado, pasa la solicitud al servidor y luego devuelve la respuesta del servidor, lo que permite que la conexión se negocie sin que el servidor vea el indicador FALLBACK.

¿Qué características de TLS previenen tal ataque? ¿La lista de suites de cifrado está cifrada de alguna manera, incluso antes de que se haya negociado la sesión?

    
pregunta David Conrad 20.10.2014 - 19:57
fuente

2 respuestas

16

Al final del protocolo de enlace, se intercambian los mensajes Finished , bajo la protección de los algoritmos y claves recién negociados; en particular, el contenido de estos mensajes está protegido por un MAC . El contenido de los mensajes Finished es un hash de todos los mensajes de intercambio anteriores. Cualquier manipulación externa del mensaje ClientHello a medida que pasa del cliente al servidor se detectará en ese momento: el cliente y el servidor no funcionarán exactamente sobre los mismos contenidos de ClientHello , por lo que no obtendrán el mismo valor hash para los mensajes Finished .

Esto protege el apretón de manos contra la alteración, siempre y cuando cualquier alteración que realice el atacante no le permita inmediatamente romper toda la capa criptográfica. En el caso del Caniche, incluso si el atacante logra forzar el uso de SSL 3.0, no puede destruir el cripto de inmediato y, por lo tanto, no puede "arreglar" los mensajes Finished .

    
respondido por el Tom Leek 20.10.2014 - 20:02
fuente
6

Aunque no es estrictamente un duplicado de ¿Cómo funciona SSL / TLS? , la respuesta está ahí:

  

El mensaje finalizado es una suma de comprobación criptográfica calculada sobre todos   Mensajes anteriores de handshake (tanto del cliente como del servidor). Ya que   se emite después del ChangeCipherSpec, también está cubierto por el   Verificación de integridad y el cifrado.

Si modifica alguna parte del apretón de manos en el medio, invalidará todo el apretón de manos y la conexión se interrumpirá.

    
respondido por el gowenfawr 20.10.2014 - 20:02
fuente

Lea otras preguntas en las etiquetas