Comprensión de TLS 1.2 y TLS 1.3

TLS (Transport Layer Security) es el protocolo criptográfico que cifra y autentica los datos transmitidos entre clientes y servidores a través de una red. Protege la información personal, las transacciones financieras, el tráfico de API y las comunicaciones comerciales contra la interceptación, la manipulación y la suplantación de identidad. TLS 1.3 es la versión recomendada actualmente. Reduce los viajes de ida y vuelta del protocolo de enlace de 2-RTT a 1-RTT, exige el secreto directo mediante ECDHE para todas las conexiones, elimina todos los conjuntos de cifrado débiles heredados y cifra más partes del protocolo de enlace que TLS 1.2. La acción recomendada es: habilitar TLS 1.3 en todos los servidores de inmediato, deshabilitar TLS 1.0 y 1.1, restringir TLS 1.2 a los conjuntos de cifrado ECDHE-AEAD únicamente durante el período de transición y mantener ambas versiones en paralelo hasta que el análisis de los clientes heredados confirme que se puede retirar TLS 1.2.

Respuesta rápida: TLS 1.2 vs TLS 1.3: ¿Cuál usar y por qué?

TLS 1.3 es la opción correcta para todas las nuevas implementaciones. Es más rápido (intercambio de claves 1-RTT frente a 2-RTT), más seguro (secreto directo obligatorio, intercambio de claves cifrado, eliminación de todos los algoritmos heredados) y más simple (5 conjuntos de cifrado en lugar de cientos). TLS 1.2 sigue siendo necesario solo para la compatibilidad con versiones anteriores de clientes y sistemas que aún no admiten TLS 1.3. El NIST exige que todos los servidores TLS del gobierno federal de EE. UU. admitan tanto TLS 1.2 (con conjuntos de cifrado compatibles con FIPS) como TLS 1.3 según NIST SP 800-52 Revisión 2 , siendo TLS 1.3 obligatorio a partir del 1 de enero de 2024. No se debe utilizar TLS 1.0 ni TLS 1.1; tienen vulnerabilidades explotables conocidas y no tienen ningún uso legítimo en la actualidad.

¿Qué es TLS?

Transport Layer Security (TLS) es un protocolo criptográfico estandarizado por la IETF en 1999. TLS se basa en SSL (Secure Sockets Layer) al abordar sus vulnerabilidades y mejorar la seguridad mediante algoritmos de cifrado más robustos, una validación de certificados mejorada y protección contra los ataques presentes en las versiones SSL. Las versiones anteriores de TLS (1.0 y 1.1) presentaban fallos de seguridad que permitían a los atacantes robar datos confidenciales. TLS protege los datos mediante tres mecanismos que trabajan conjuntamente:

• Autenticación: Durante el protocolo de enlace, el servidor presenta un certificado TLS emitido por una Autoridad de Certificación (CA) de confianza. El cliente verifica este certificado para confirmar que se está comunicando con el servidor legítimo y no con un impostor.
• Encriptación: Una vez que el protocolo de enlace establece una clave de sesión compartida, todos los datos transmitidos se cifran con un algoritmo de cifrado simétrico (AES-GCM o ChaCha20-Poly1305 en TLS 1.3), lo que impide que terceros intercepten la comunicación y lean el contenido.
• Integridad: Los conjuntos de cifrado AEAD incluyen etiquetas de autenticación que detectan cualquier modificación de los datos cifrados, lo que garantiza que un atacante no pueda alterar los datos en tránsito sin ser detectado.

TLS 1.2 y su protocolo de enlace

TLS 1.2, introducido en agosto de 2008 (IETF RFC 5246), abordó las limitaciones de TLS 1.0 y 1.1 mediante algoritmos de cifrado más robustos, una validación de certificados mejorada y compatibilidad con conjuntos de cifrado AEAD. Su protocolo de enlace requiere dos viajes de ida y vuelta (2-RTT):

• El cliente envía un ClientHello con las versiones TLS compatibles, los conjuntos de cifrado, un número aleatorio del cliente y un ID de sesión opcional.
• El servidor responde con un ServerHello, seleccionando la versión TLS y el conjunto de cifrado, un número aleatorio propio y su certificado firmado con clave pública. Si se requiere autenticación mutua, el servidor solicita un certificado de cliente.
• El cliente valida el certificado del servidor con autoridades de certificación de confianza. En TLS mutuo (mTLS), el servidor también valida el certificado del cliente.
• Criptografía de clave pública asegura el intercambio de claves: el cliente envía un secreto pre-maestro cifrado con la clave pública del servidor. Solo el servidor puede descifrarlo con su clave privada, que se guarda de forma segura en un HSM o bóveda de claves. Ambas partes derivan las claves de sesión del secreto maestro previo y sus valores aleatorios.
• El cliente y el servidor intercambian mensajes ChangeCipherSpec y Finished que confirman que están listos para el cifrado simétrico. Toda la comunicación posterior utiliza las claves de sesión derivadas.

Características principales de TLS 1.2

• Hashing mejorado: Se sustituyó la combinación MD5+SHA-1 utilizada en versiones anteriores por algoritmos hash configurables, incluidos SHA-256 y SHA-384.
• Compatibilidad con el conjunto de cifrado AES: Introducido AES Conjuntos de cifrado con claves de 128 y 256 bits, que ofrecen un cifrado simétrico significativamente más robusto que los conjuntos basados ​​en DES a los que sustituyeron.
• Compatibilidad con cifrado autenticado (AEAD): Se ha ampliado la compatibilidad con los modos AEAD, incluidos AES-GCM y AES-CCM, que proporcionan verificación de confidencialidad e integridad en una sola operación.
• Algoritmos de hash y firma negociables: Tanto el cliente como el servidor pueden especificar los algoritmos de hash y firma que admiten durante el protocolo de enlace, lo que permite seleccionar la combinación más robusta compatible entre ambas partes y facilita una migración fluida desde algoritmos débiles como SHA-1.

TLS 1.3 y su protocolo de enlace

TLS 1.3, publicado en agosto de 2018 (RFC 8446), representa un rediseño significativo del protocolo. Prioriza la seguridad eliminando opciones heredadas vulnerables en lugar de añadir medidas de mitigación. El protocolo de enlace TLS 1.3 se completa en un solo viaje de ida y vuelta (1-RTT):

• El cliente envía un ClientHello que incluye la versión TLS compatible, los conjuntos de cifrado, el generador de claves aleatorio del cliente y las claves compartidas para sus grupos ECDHE preferidos. Si la autenticación del cliente está habilitada, el cliente también incluye información del certificado.
• El servidor selecciona el conjunto de cifrado y el grupo ECDHE, genera la clave maestra a partir del mensaje aleatorio ClientHello y el mensaje aleatorio generado por el servidor, combinados con las claves compartidas seleccionadas, y envía un mensaje ServerHello con los parámetros seleccionados, además de un mensaje ServerFinished. El certificado del servidor y todos los mensajes de establecimiento de conexión posteriores se cifran.
• El cliente verifica el certificado del servidor, genera la misma clave maestra utilizando su propia clave compartida y la respuesta del servidor, envía un mensaje ClientFinished y ambas partes comienzan el intercambio cifrado de datos de la aplicación. Todo el proceso de establecimiento de la conexión se completa en una sola comunicación.

Características principales de TLS 1.3

• Secreto obligatorio hacia adelante: TLS 1.3 requiere ECDHE para todos los intercambios de claves, lo que hace que el secreto directo sea obligatorio para cada conexión. Incluso si la clave privada TLS a largo plazo de un servidor se ve comprometida posteriormente, las sesiones anteriores no se pueden descifrar porque las claves de sesión efímeras se pierden.
• Solo se permiten conjuntos de cifrado AEAD: TLS 1.3 solo admite cinco conjuntos de cifrado, todos AEAD: AES-128-GCM-SHA256, AES-256-GCM-SHA384, ChaCha20-Poly1305-SHA256, AES-128-CCM-SHA256 y AES-128-CCM-8-SHA256. Todos proporcionan cifrado autenticado que detecta manipulaciones.
• Intercambio de claves cifrado: TLS 1.3 cifra una mayor parte del protocolo de enlace que TLS 1.2, incluido el certificado del servidor. Los observadores pasivos no pueden ver qué certificado presenta un servidor.
• Reanudación de 0-RTT: Los clientes que se reconectan a un servidor al que ya se han conectado pueden enviar datos de la aplicación con el primer mensaje (0-RTT), lo que reduce la latencia en las conexiones recurrentes. Nota: Los datos 0-RTT son vulnerables a ataques de repetición y no deben utilizarse para operaciones no idempotentes (solicitudes que modifican el estado, como las transacciones financieras).
• Eliminación del algoritmo: TLS 1.3 elimina RC4, DES, 3DES, MD5, SHA-1, el intercambio de claves RSA, DH estático, los conjuntos de cifrado CBC y la compresión TLS, todos los cuales eran vectores de ataque en las implementaciones de TLS 1.2.

Comparación: TLS 1.2 vs TLS 1.3

Elemento	TLS 1.2	TLS 1.3	Generar impacto
Viajes de ida y vuelta con apretón de manos	2-RTT	1-RTT (0-RTT para reanudar la sesión)	TLS 1.3 establece una conexión más rápida; 0-RTT tiene riesgo de ataque de repetición.
Conjuntos de cifrado permitidos	Cientos, incluyendo algunos débiles (RC4, DES, CBC)	Solo cinco suites AEAD	TLS 1.2 requiere una configuración cuidadosa para evitar vulnerabilidades; TLS 1.3 es seguro por diseño.
Intercambio de llaves	RSA, DHE, ECDHE (todos compatibles)	Solo ECDHE	TLS 1.3 proporciona confidencialidad directa para cada conexión; el intercambio de claves RSA de TLS 1.2 no tiene confidencialidad directa.
Reenviar secreto	Opcional (depende del conjunto de cifrado)	Obligatorio	TLS 1.3 protege las sesiones pasadas incluso si la clave a largo plazo se ve comprometida.
Cifrado mediante protocolo de enlace	El certificado quedó expuesto en texto plano durante el protocolo de enlace.	Certificado cifrado en el protocolo de enlace.	TLS 1.3 oculta la identidad del servidor a los observadores pasivos.
Eliminación de algoritmos	Admite RC4, MD5, SHA-1, 3DES (debe deshabilitarse explícitamente).	Estos algoritmos eliminaron por completo	TLS 1.3 elimina clases de ataques completas (POODLE, BEAST, CRIME) al eliminar las primitivas vulnerables.
Reanudación de la sesión	Identificadores de sesión y tickets de sesión	Opción PSK con 0-RTT	Los tickets de sesión TLS 1.3 proporcionan confidencialidad directa; los tickets de sesión TLS 1.2 pueden no
Validación de certificado	Se revelan algunos detalles del apretón de manos	El protocolo de enlace completo se cifra después de ServerHello.	TLS 1.3 proporciona mejoras de privacidad para el contenido de los certificados.
Rendimiento	Más lento (apretón de manos 2-RTT)	Más rápido (1-RTT; 0-RTT para reanudación)	TLS 1.3 reduce la latencia, especialmente para redes de alta latencia y clientes móviles.
mandato del NIST	Obligatorio; solo se admiten conjuntos de cifrado compatibles con FIPS.	Obligatorio a partir del 1 de enero de 2024 (NIST SP 800-52 Rev. 2)	Ambos son necesarios para los sistemas federales; TLS 1.3 es el estándar actual.

Selección de conjunto de cifrado para TLS 1.2

TLS 1.3 tiene una lista fija de cinco conjuntos de cifrado AEAD; no hay opción de elegir. TLS 1.2 admite una gama mucho más amplia, incluyendo opciones inseguras que deben deshabilitarse explícitamente. Conjuntos de cifrado TLS 1.2 recomendados según NIST SP 800-52 Rev. 2 (en orden de preferencia):

• TLS_ECDHE_ECDSA_CON_AES_256_GCM_SHA384 (mejor opción: secreto directo ECDHE, certificado ECDSA, AES-256-GCM AEAD)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Secreto directo ECDHE, certificado RSA, AES-256-GCM AEAD)
• TLS_ECDHE_ECDSA_CON_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_CON_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_CON_CHACHA20_POLY1305_SHA256

Desactive explícitamente en TLS 1.2: cualquier conjunto de claves que contenga RC4, DES, 3DES, cifrado nulo, EXPORT, MD5 o intercambio de claves anónimo (anon). Desactive todos los conjuntos de claves RSA (TLS_RSA_*): no proporcionan confidencialidad directa. Evite los conjuntos de claves CBC siempre que sea posible debido a su susceptibilidad a ataques de oráculo de relleno (POODLE, BEAST).

Vulnerabilidades: TLS 1.2 y TLS 1.3

TLS 1.2 ha sido objeto de varios ataques de gran repercusión, la mayoría de los cuales explotan su compatibilidad con algoritmos antiguos:

• BESTIA (2011): Se explotó la predictibilidad de CBC IV en TLS 1.0; parcialmente mitigada en TLS 1.2 a través de los conjuntos de cifrado AES-GCM y AEAD.
• CANICHE (2014): Se explotó una vulnerabilidad de relleno SSL 3.0 mediante ataques de degradación de protocolo; se solucionó deshabilitando SSL 3.0 y TLS 1.0/1.1.
• Heartbleed (2014): Vulnerabilidad de divulgación de memoria en OpenSSL; no se encuentra en la especificación TLS en sí, pero afecta a las implementaciones de TLS 1.2.
• Ataque de mapache (2020): Ataque de canal lateral basado en el tiempo en el intercambio de claves DHE; el uso de ECDHE por parte de TLS 1.3 elimina por completo el DH estático.
• DELITOS E INCUMPLIMIENTOS: Se aprovechó la compresión TLS para extraer información confidencial; TLS 1.3 elimina la compresión por completo.

TLS 1.3 elimina la mayoría de estas vulnerabilidades al suprimir las primitivas vulnerables (modos CBC, DH, compresión, intercambio de claves RSA) en lugar de parchearlas. Sin embargo, TLS 1.3 no es inmune a las vulnerabilidades de implementación: configuraciones incorrectas como nonces predecibles en AES-GCM, protección inadecuada contra repetición 0-RTT y generación débil de claves aún pueden crear vulnerabilidades. La base de datos CVE del NIST ha documentado fallos de implementación de TLS 1.3 en productos específicos. Las actualizaciones periódicas, las auditorías de seguridad y la revisión de la configuración de TLS siguen siendo esenciales incluso con TLS 1.3.

Ejemplo de implementación: Migración TLS empresarial

Una organización de servicios financieros con 200 servicios de cara al público implementa una migración TLS estructurada:

1. Auditoría e inventario: El análisis de la configuración TLS en los 200 puntos finales identifica: 12 servicios que aún utilizan TLS 1.0 o 1.1; 85 servicios que utilizan TLS 1.2 con conjuntos de cifrado de intercambio de claves RSA (sin confidencialidad directa); 40 servicios que utilizan conjuntos de cifrado CBC débiles; 63 servicios que ya utilizan TLS 1.2 con conjuntos ECDHE-AEAD. Certificados TLS: 140 RSA-2048, 60 ECDSA P-256.
2. Deshabilitar inmediatamente TLS 1.0/1.1: Los 12 servicios que utilizan TLS 1.0/1.1 se actualizan para deshabilitar estas versiones en un plazo de 30 días, lo que representa el máximo riesgo en el entorno.
3. Habilitación de TLS 1.3 en todos los servidores: TLS 1.3 está habilitado junto con TLS 1.2 en todos los servidores. Los navegadores modernos y los clientes de API comienzan a usar TLS 1.3 de inmediato; los clientes antiguos continúan usando TLS 1.2.
4. Refuerzo del conjunto de cifrado TLS 1.2: En las configuraciones TLS 1.2, todos los conjuntos de cifrado RSA y CBC están deshabilitados. Solo los conjuntos ECDHE-AEAD permanecen habilitados, lo que proporciona confidencialidad directa para las conexiones TLS 1.2 durante el período de transición.
5. Migración de certificados: Los certificados RSA-2048 se migran a ECDSA P-256 en la renovación del certificado, utilizando Administrador de CertSecure Para automatizar la renovación y el seguimiento del inventario, ECDSA P-256 reduce el tamaño del protocolo de enlace TLS y el volumen de datos del certificado.
6. TLS 1.2 Planificación de la jubilación: El análisis de los registros de acceso muestra que el uso de TLS 1.2 disminuye mes a mes a medida que los clientes actualizan sus sistemas. Se ha previsto desactivar TLS 1.2 una vez que su uso caiga por debajo del 1 % de las conexiones, lo que se espera que ocurra en un plazo de 12 meses.

Dependencias de gestión clave para TLS

• Protección de clave privada TLS: La clave privada del servidor TLS es el componente más sensible en una implementación TLS. La vulneración de esta clave permite el descifrado de sesiones anteriores sin confidencialidad directa (intercambio de claves RSA de TLS 1.2) y posibilita la suplantación de identidad del servidor. Almacene las claves privadas TLS en HSM o almacenes de claves de hardware con certificación FIPS 140-2 Nivel 2 o superior, siempre que sea posible. Consulte HSM como servicio.
• Automatización del ciclo de vida de los certificados: Los certificados TLS son identidades de máquina con fechas de caducidad. La gestión manual de certificados a gran escala resulta ineficaz: el Foro CA/Browser ha exigido que la duración de los certificados se reduzca a 47 días para 2029. Administrador de CertSecure Automatiza la detección, renovación y aplicación de políticas en todo el inventario de certificados TLS.
• Moneda del algoritmo del certificado: Según la norma NIST IR 8547, se propone que los certificados RSA-2048 dejen de utilizarse después de 2030. Las organizaciones deberían emitir certificados ECDSA P-256 para todas las nuevas implementaciones y migrar los certificados RSA al renovarlos.

Desafíos Migratorios

• Incompatibilidad con sistemas heredados: Los sistemas más antiguos, los dispositivos integrados y algunos programas intermedios empresariales pueden no ser compatibles con TLS 1.3. Esto requiere actualizaciones o reemplazos, lo que puede resultar costoso para las industrias con una infraestructura heredada compleja.
• Eliminación del intercambio de claves RSA: La eliminación del intercambio de claves RSA en TLS 1.3 provoca fallos en los sistemas que dependen de él. Los dispositivos de inspección de red que realizan la inspección TLS interceptando y volviendo a firmar las conexiones podrían necesitar una reconfiguración para funcionar con el intercambio de claves efímeras de TLS 1.3.
• Cambios en el protocolo de enlace que requieren actualizaciones de la aplicación: Los mecanismos modificados de establecimiento de conexión y reanudación de sesión de TLS 1.3 requieren actualizaciones de la lógica de la aplicación en sistemas con flujos de autenticación o conexión complejos.
• Equilibrar la compatibilidad con versiones anteriores durante la transición: Mantener TLS 1.2 junto con TLS 1.3 durante el período de migración es necesario, pero temporal. TLS 1.2 con los paquetes ECDHE-AEAD proporciona una seguridad aceptable durante la transición; TLS 1.2 simple con intercambio de claves RSA no la proporciona y debería deshabilitarse incluso mientras se mantenga TLS 1.2.

Cómo puede ayudar la consultoría de cifrado

En Encryption Consulting, ayudamos a las organizaciones a afrontar los retos de la migración a TLS con soluciones personalizadas adaptadas a su infraestructura específica. Nuestros servicios abarcan la evaluación y auditoría de la configuración de TLS (identificando conjuntos de cifrado débiles, versiones de protocolo obsoletas y brechas de certificados en su entorno), la planificación e implementación de la migración (un enfoque estructurado para habilitar TLS 1.3 y retirar configuraciones más débiles con una mínima interrupción del servicio) y la gestión del ciclo de vida de los certificados mediante CertSecure Manager (automatizando la detección, renovación y aplicación de políticas para certificados TLS, incluido el próximo requisito de validez de 47 días). Nuestros servicios de PKI también cubren la infraestructura de la autoridad de certificación que emite certificados TLS, garantizando que la cadena de confianza esté correctamente diseñada y gestionada.

Conclusión

TLS es el protocolo fundamental que protege los datos en tránsito a través de Internet. TLS 1.3 es el estándar actual: más rápido que TLS 1.2, con confidencialidad directa obligatoria, intercambio de claves cifrado y sin algoritmos heredados. Las organizaciones deben habilitar TLS 1.3 en todos los servidores de inmediato, deshabilitar TLS 1.0 y 1.1 sin demora, reforzar TLS 1.2 para que solo sea compatible con los conjuntos de protocolos ECDHE-AEAD durante el período de transición y planificar la retirada de TLS 1.2 una vez que el análisis de los clientes heredados confirme que ya no es necesario.

La gestión de certificados TLS se está intensificando: para 2029, la vigencia de los certificados a 47 días exige una gestión automatizada del ciclo de vida en lugar del seguimiento manual. El algoritmo también está evolucionando: se prevé que los certificados RSA-2048 dejen de ser compatibles después de 2030, lo que convierte a ECDSA P-256 en la opción más adecuada para la emisión de todos los nuevos certificados TLS. Para obtener información relacionada, consulte nuestras guías sobre cómo entender los certificados ECC y SSL/TLS.

Preguntas frecuentes

¿Qué es TLS y qué protege?

TLS es un protocolo criptográfico que proporciona confidencialidad, integridad y autenticación para los datos de red. Protege los datos contra la interceptación (cifrado), la manipulación (integridad mediante AEAD) y la suplantación de identidad (autenticación de certificados de servidor mediante CA). Se utiliza en protocolos HTTPS, SMTP, IMAP, tráfico de API, conexiones a bases de datos y VPN.

¿Cuál es la diferencia entre TLS 1.2 y TLS 1.3?

TLS 1.3 es más rápido (1-RTT frente a 2-RTT), exige confidencialidad directa mediante ECDHE, permite solo 5 conjuntos de cifrado AEAD (frente a cientos en TLS 1.2, incluidos los débiles), cifra una mayor parte del protocolo de enlace y elimina todos los algoritmos heredados (RC4, 3DES, intercambio de claves RSA, CBC, compresión) que eran vectores de ataque en TLS 1.2.

¿Qué conjuntos de cifrado se deben utilizar con TLS 1.2?

La norma NIST SP 800-52 Rev. 2 recomienda los conjuntos de claves ECDHE-AEAD: se prefieren TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 y TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Deshabilite todos los conjuntos de intercambio de claves RSA (sin confidencialidad directa), todos los conjuntos RC4/DES/3DES, los conjuntos MD5/SHA-1 y los conjuntos CBC siempre que sea posible.

¿Qué es el secreto directo y por qué lo requiere TLS 1.3?

El secreto hacia adelante implica que, al comprometer la clave privada TLS a largo plazo, no se pueden descifrar las sesiones pasadas, ya que las claves de sesión eran efímeras. TLS 1.3 exige esto mediante ECDHE para todas las conexiones. Sin el secreto hacia adelante (intercambio de claves RSA de TLS 1.2), un atacante que registre el tráfico actual puede descifrarlo retroactivamente si posteriormente obtiene la clave privada.

¿Cómo deberían las organizaciones migrar de TLS 1.2 a TLS 1.3?

Habilite TLS 1.3 en todos los servidores junto con TLS 1.2 (no en lugar de este). Desactive inmediatamente TLS 1.0 y 1.1. Refuerce la seguridad de TLS 1.2 únicamente para las suites ECDHE-AEAD. Supervise la distribución del protocolo TLS en los registros de acceso. Planifique la retirada de TLS 1.2 una vez que la supervisión muestre un uso mínimo por parte de los clientes activos.

¿Qué ataques afectan a TLS 1.2 y se han solucionado en TLS 1.3?

Los ataques BEAST, POODLE y otros similares explotaron la compatibilidad de TLS 1.2 con los conjuntos de cifrado CBC y algoritmos débiles. TLS 1.3 elimina por completo los conjuntos de cifrado CBC, eliminando así estas clases de ataques. Raccoon se dirigía a DHE; TLS 1.3 utiliza únicamente ECDHE. CRIME explotaba la compresión; TLS 1.3 elimina la compresión. TLS 1.3 no es inmune a fallos de implementación, pero elimina las primitivas vulnerables que permitieron la mayoría de los ataques conocidos a nivel de protocolo.