No hay ningún problema de seguridad "real" en TLS 1.1 que TLS 1.2 correcciones. Sin embargo, hay cambios y mejoras, que se pueden argumentar para calificar como "reparación". Principalmente:
-
El PRF en TLS 1.1 se basa en una combinación de MD5 y SHA-1. Tanto MD5 como SHA-1 están, como funciones hash criptográficas, rotas. Sin embargo, la forma en que se rompen no rompe el PRF de TLS 1.1. No hay debilidad conocida en la PRF de TLS 1.1 (ni, en realidad, en la PRF de SSL 3.0 y TLS 1.0). Sin embargo, MD5 y SHA-1 son "mala prensa". TLS 1.2 reemplaza a ambos con SHA-256 (bueno, en realidad podría ser cualquier otra función hash, pero en la práctica es SHA-256).
-
TLS 1.2 permite el uso de modos de cifrado autenticados como GCM. Esto puede reemplazar el modo de cifrado CBC más tradicional, que históricamente ha sido una fuente de muchos defectos. Implementado correctamente El cifrado CBC aún está bien; sin embargo, parece que implementar correctamente el cifrado CBC es más fácil decirlo que hacerlo. Hacer que GCM funcione correctamente es un objetivo más fácil de alcanzar.
-
TLS 1.2 exige el soporte para TLS_RSA_WITH_AES_128_CBC_SHA
mientras que TLS 1.1 solo requiere TLS_RSA_WITH_3DES_EDE_CBC_SHA
. Por lo tanto, si usa TLS 1.2, tiene una "garantía" de que el cifrado AES estará disponible. (De hecho, esto no es completamente cierto: la garantía se mantiene solo mientras no exija lo contrario el "perfil específico de la aplicación". Además, obtendrá AES solo si el cliente y el servidor lo admiten, y si ambos lo admiten, entonces es disponible, independientemente de si se usa TLS 1.1 o 1.2)
Para resumir , no es una mala idea parchear sus servidores para que sean compatibles con TLS 1.2 y configurarlos para que lo prefieran sobre TLS 1.1, pero no hay una falla real en TLS 1.1 que deba solucionarse y Hacer un cambio a TLS 1.2 obligatorio o incluso recomendado. El impulso principal para la adopción de TLS 1.2 es el antojo pavloviano habitual de todo lo nuevo y brillante.