A principios de la década de 1990, Netscape comenzó a desarrollar SSL; por lo tanto, se presentó un borrador inicial para su revisión. SSL La versión 2.0 de SSL se lanzó en 1995. Esta versión presentaba importantes fallos de seguridad que llevaron a la creación de la versión 3.0. El borrador de la versión 3.0 se presentó al IETF en 1996. Según Netscape, la versión 3.0 podría ser un protocolo de seguridad que impidiera la interceptación, la manipulación o la falsificación de mensajes en Internet. El IETF publicó el RFC 61012 (Solicitud de Comentarios) como especificación para la versión 3.0.
SSL comenzó a conocerse como TLS, y la siguiente versión de TLS llegó en 1999 con el RFC 22463. En resumen, SSL v3.0 y TLS 1.0 no presentan variaciones que deban preocupar a un desarrollador; sin embargo, es preferible usar TLS 1.0. La siguiente versión de TLS, TLS 1.1, se lanzó en 2006 y se describe en el RFC 43464. TLS 1.1 incluye mejoras con respecto a TLS 1.0. La siguiente versión, TLS 1.2, se publicó en 2008 y se define en el RFC 52465.
TLS 1.2 ha tenido cambios importantes desde TLS 1.1 e incluye compatibilidad con protocolos más nuevos y seguros. criptográfico Algoritmos. En agosto de 2018, se lanzó TLS 1.3. Las diferencias entre TLS 1.2 y 1.3 son amplias y significativas, mejorando el rendimiento y la seguridad de ambas. Al mismo tiempo, TLS 1.2 sigue siendo ampliamente utilizado gracias a la ausencia de vulnerabilidades conocidas y a su uso continuo en entornos empresariales.
Versiones obsoletas de TLS
Los datos confidenciales siempre requieren una protección robusta. Los protocolos TLS proporcionan confidencialidad, integridad y, a menudo, protección de autenticidad a la información durante su transmisión por una red. Esto se logra estableciendo un canal seguro entre un servidor y un cliente para la comunicación durante una sesión. Con el tiempo, se desarrollan nuevas versiones de TLS y algunas de las anteriores quedan obsoletas debido a vulnerabilidades o razones técnicas; por lo tanto, ya no deben utilizarse para proteger los datos.
Se debe utilizar TLS 1.2 o TLS 1.3, y ninguna organización debe utilizar SSL 2.0, SSL 3.0, TLS 1.0 o TLS 1.1.
Conjuntos de cifrado obsoletos
En TLS 1.2, el término "conjuntos de cifrado" se refiere al conjunto negociado y acordado de algoritmos criptográficos para la transmisión TLS. El cliente TLS ofrece una lista de conjuntos de cifrado y el servidor selecciona los conjuntos de cifrado negociados de la lista. Los conjuntos de cifrado en TLS 1.2 consisten en... cifrado algoritmo, un algoritmo de intercambio de claves, un mecanismo de autenticación y un mecanismo de derivación de claves.
Los conjuntos de cifrado se consideran obsoletos cuando uno o más de sus mecanismos son débiles. Los algoritmos de cifrado frágiles en TLS 1.2 se definen como NULL, RC2, RC4, DES, IDEA y TDES/3DES; las organizaciones no deben usar conjuntos de cifrado con estos algoritmos. TLS 1.3 elimina estos conjuntos de cifrado, pero las implementaciones compatibles con TLS 1.3 y las organizaciones deben comprobar si TLS 1.2 contiene conjuntos de cifrado obsoletos.
Mecanismos de intercambio de claves obsoletos
Los mecanismos de intercambio de claves más débiles, indicados por el conjunto de cifrado, incluyen los designados como EXPORT o ANON. No se deben utilizar conjuntos de cifrado que utilicen estos mecanismos de intercambio de claves. En sesiones TLS, incluso si el conjunto de cifrado es aceptable, los mecanismos de intercambio de claves pueden usar claves débiles que permitan su explotación. Los métodos de intercambio de claves TLS incluyen el transporte de claves RSA y el establecimiento de claves DH o ECDH.
La DH y la ECDH tienen mecanismos estáticos y efímeros. La NSA recomienda RSA Transporte de claves y mecanismos efímeros DH (DHE) o ECDH (ECDHE), con intercambio de claves RSA o DHE utilizando claves de al menos 3072 bits y ECDHE utilizando la curva elíptica secp384r1. Para el transporte de claves RSA y el intercambio de claves DH/DHE, no se deben utilizar claves inferiores a 2048 bits, ni ECDH/ECDHE con curvas personalizadas.
Riesgo de protocolos TLS obsoletos
Los protocolos TLS obsoletos utilizan conjuntos de cifrado que no son compatibles ni recomendados, y usar versiones anteriores de TLS requeriría un esfuerzo para mantener las bibliotecas y aumentaría el coste de mantenimiento del producto. Además del escenario mencionado anteriormente, existen otros posibles:
- El uso de versiones obsoletas de TLS obligaría a las organizaciones a utilizar conjuntos de cifrado obsoletos y vulnerables, en lugar de admitir conjuntos de cifrado más recientes y recomendados.
- TLS 1.0 y 1.1 son vulnerables a ataques de degradación, ya que dependen del hash SHA-1 para la integridad de los mensajes intercambiados. Incluso la autenticación de los protocolos de enlace se basa en SHA-1, lo que facilita que un atacante suplante la identidad de un servidor para realizar ataques de intermediario (MITM). TLS 1.1 y versiones anteriores no ofrecen la opción de seleccionar algoritmos de hash más robustos, a diferencia de los protocolos más recientes.
- El soporte para protocolos antiguos aumenta los costes, ya que es necesario corregir todas las vulnerabilidades, dar soporte a las bibliotecas y aumentar la superficie de ataque.
Identificación y análisis de protocolos TLS obsoletos
Dado que existen diversas maneras de que las configuraciones TLS obsoletas se muestren en el tráfico, se recomienda la siguiente estrategia de detección. Las firmas se pueden simplificar con esta estrategia:
- Primero, identifique la oferta del cliente y los servidores que negocian versiones obsoletas de TLS. Si un cliente ofrece o un servidor negocia SSL 2.0, SSL 3.0 o una versión obsoleta de TLS, no se requiere un análisis de tráfico adicional y se deben implementar estrategias de remediación.
- A continuación, para las sesiones que utilizan TLS 1.2, las organizaciones deben identificar y remediar los dispositivos que utilizan conjuntos de cifrado TLS obsoletos. Identifique únicamente a los clientes que ofrecen y a los servidores que negocian conjuntos de cifrado TLS obsoletos, y actualice sus configuraciones para que cumplan con la normativa.
- Por último, las organizaciones deben identificar y remediar los dispositivos que utilizan métodos de intercambio de claves débiles para sesiones que utilizan TLS 1.2 o TLS 1.3 y conjuntos de cifrado recomendados.
Beneficios de la actualización a protocolos más recientes
Además de eliminar vulnerabilidades y mejorar la seguridad del entorno, las organizaciones suelen obtener algunos beneficios al actualizarse a protocolos más recientes:
- Aumentar el rendimiento en el entorno general.
- Seguridad mejorada.
- Mejor soporte y parches para las vulnerabilidades encontradas, junto con investigación de nuevas vulnerabilidades.
- Mejores algoritmos de hash para la comprobación de integridad y la autenticación de apretones de manos.
Conclusión
Las organizaciones cifran el tráfico de red para proteger los datos en tránsito. Sin embargo, el uso de configuraciones TLS obsoletas ofrece una falsa sensación de seguridad, ya que parece que los datos están protegidos, aunque no lo estén. Las organizaciones deben planificar la eliminación de las configuraciones TLS obsoletas en el entorno mediante la detección, la corrección y el bloqueo de versiones TLS, conjuntos de cifrado y métodos de intercambio de claves obsoletos.
Recursos
- SP 800-52 Rev. 2, Directrices para la implementación de TLS | CSRC (nist.gov)
- La NSA publica el documento "Eliminación de configuraciones obsoletas del protocolo de seguridad de la capa de transporte (TLS)" Información sobre ciberseguridad > Agencia de Seguridad Nacional (NSA) Servicio Central de Seguridad > Vista del artículo
