¿Qué tan bien está protegido / protegido el protocolo SSL / TLS contra modificaciones?

Question

¿Qué tan bien está protegido / protegido el protocolo SSL / TLS contra modificaciones?

#1 de Thomas Pornin (12 votos)

12

El protocolo de enlace SSL / TLS está protegido contra intentos de degradación por el mensaje finalizado, un hash autenticado y firmado del secreto principal y todos los mensajes de protocolo de enlace anteriores.

Considere un cliente que usa una combinación de conjuntos de cifrado fuerte y débil que se conecta a un servidor que admite el mismo conjunto de cifrados. Por lo general, una o ambas partes preferirán un cifrado sólido y la conexión se establecerá de forma segura.

¿Qué capacidades necesitaría tener un atacante para degradar activamente el protocolo de enlace a uno de los conjuntos de cifrado débiles? Supongo que el atacante no puede romper el establecimiento de la clave maestra a través de RSA o (EC) DH.

Creo que deben poder hacer al menos lo siguiente:

Calcule un valor de hash válido para el protocolo de enlace modificado (p. ej., con algunos conjuntos de cifrado eliminados o modificados por valores no válidos), sin conocer el secreto maestro, y posiblemente también sin conocer el valor de hash original (según el esquema de cifrado utilizado)
Realice esas modificaciones de hash en ciphertexts (con texto desconocido), ya que el mensaje finalizado está encriptado
Modifique la etiqueta de autenticación cifrada para el mensaje finalizado (ya que SSL / TLS usa autenticar y luego cifrar) para que sea válida para el hash de handshake modificado, nuevamente sin saber el valor original.

"Cómo está roto" hace una función hash, "¿qué tan maleable" tiene que ser un cifrado para habilitar tal ataque? ¿Existe alguna posibilidad hoy o en un futuro previsible (considerando los ataques existentes en MD5, SHA1, RC4, etc.) de que un ataque sea posible para una de las suites de cifrado heredadas existentes, excepto quizás las versiones de exportación donde podría estar la clave maestra? ¿Bruto forzado por el atacante?

¿O es seguro dejar esas suites de cifrado "moderadamente seguras" habilitadas en el cliente y confiar en la protección de intercambio?

tls man-in-the-middle

pregunta lxgr 30.10.2014 - 11:36

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls man-in-the-middle

¿Los intentos de XSS dejan algún rastro en el servidor? ¿Necesito el token CSRF si estoy usando Bearer JWT?

score 12 · Accepted Answer

En "hash" de los mensajes de intercambio, como se usa en los mensajes Finished , se calcula con el PRF , que utiliza el secreto maestro como parámetro adicional (en SSL 3.0 el cálculo es diferente, pero el secreto maestro todavía se usa; los valores de 36 bytes son una especie de HMAC con MD5 y SHA-1). Si el atacante altera uno de los mensajes de intercambio anteriores, entonces debe ser capaz de corregir el primer mensaje Finished en consecuencia. Ese mensaje es el primero que se encripta.

La consecuencia es que incluso si el sistema de cifrado es muy débil, el atacante debe ser capaz de romperlo sin ningún tipo de texto sin formato conocido si simplemente quiere conocer el contenido del mensaje Finished . Esto debe ser un descanso en línea , lo que significa que cualquier falla de su parte implica la imposibilidad de completar el apretón de manos. Como tal, incluso el cifrado de 40 bits sería altamente efectivo para frustrar tales ataques.

Sin embargo, supongamos que, por alguna razón, la capa de cifrado es completamente transparente para el atacante (por ejemplo, el conjunto de cifrado es TLS_RSA_WITH_NULL_SHA , sin ningún cifrado). Nuestro atacante aún enfrenta dos desafíos formidables:

El MAC es HMAC (o una especie de HMAC en el caso de SSL 3.0), para el cual no hay un ataque conocido, incluso cuando se usa MD5 como función base (consulte this , y luego que ). Para hacer una línea de base, existe un conocido ataque de falsificación en HMAC con MD4, pero incluso ese es aún muy caro y, por lo tanto, solo teórico.
El PRF en sí está basado en una gran cantidad de HMAC, por lo que el atacante tendrá dificultades para calcular su Finished modificado. Los simples ataques de falsificación en HMAC no serían suficientes; tendría que poder recuperar la clave (el secreto principal).

Notablemente, en TLS, los mensajes Finished tienen una longitud de 12 bytes (36 bytes para SSL 3.0), mientras que el secreto maestro tiene una longitud de 48 bytes. Esto significa que es matemáticamente imposible recuperar el secreto maestro completo del primer mensaje Finished , por muy débil que sea el PRF.

Para poder romper la integridad del protocolo de enlace, debemos asumir una interacción muy extraña del PRF consigo mismo, ya que el PRF se utiliza para calcular tanto el cifrado como las claves MAC que se aplican al Finished generado por PRF contenido. Esto parece inverosímil. Alternativamente, romper el mecanismo de intercambio de claves en sí. El intercambio de claves (RSA, DH ...) parece ser el único camino de ataque no ridículo (hasta donde sabemos).