Comprensión de TLS 1.2 y TLS 1.3 

Como sabe, datos confidenciales como información personal, transacciones financieras y comunicaciones comerciales se transmiten por internet, y es necesario protegerlos. Garantizar que estos datos estén protegidos contra escuchas, manipulaciones o accesos no autorizados es un desafío que el protocolo de Seguridad de la Capa de Transporte (TLS) se diseñó para abordar. TLS Fue creado en 1999 por el Grupo de Trabajo de Ingeniería de Internet (IETF). TLS se refiere a un protocolo criptográfico creado para proporcionar comunicación segura a través de una red informática.

Garantiza el cifrado de los datos transmitidos entre un cliente y un servidor, lo que dificulta que terceros no autorizados lean o alteren la información. TLS se basa en SSL, abordando sus vulnerabilidades y mejorando la seguridad mediante algoritmos de cifrado más robustos, una mejor validación de certificados y protección contra ataques como POODLE y BEAST. También introduce funciones como la confidencialidad directa y la reanudación de sesión. Su objetivo era proporcionar una forma más segura de proteger la comunicación en línea. 

versiones anteriores Los protocolos TLS, como TLS 1.0 y TLS 1.1, presentaban fallos de seguridad que los hacían vulnerables a ataques. Estos fallos podían permitir a los atacantes robar datos confidenciales, como datos de tarjetas de crédito, contraseñas u otra información personal. Por ejemplo, los proveedores de atención médica que utilizaban estos protocolos obsoletos podían hacer que los registros de los pacientes fueran vulnerables al acceso no autorizado y poner en riesgo los historiales médicos privados. Por ello, TLS necesitaba mejoras constantes para hacerlo más robusto, seguro y fiable para proteger las comunicaciones en línea. Posteriormente, se introdujeron TLS 1.2 y TLS 1.3, que mejoraron la seguridad mediante el uso de protocolos más robustos. cifrado, corrigiendo vulnerabilidades y mejorando el rendimiento para una experiencia en línea más segura. 

El Instituto Nacional de Estándares y Tecnología (NIST) exige que todos los servidores y clientes TLS gubernamentales sean compatibles con TLS 1.2 configurado con conjuntos de cifrado compatibles con FIPS. Además, se requiere compatibilidad con TLS 1.3 a partir del 1 de enero de 2024. Esta directiva se detalla en el NIST. Publicación especial 800-52 Revisión 2. 

TLS 1.2 y su protocolo de enlace 

TLS 1.2 es una versión del protocolo TLS que proporciona comunicación segura a través de Internet. Se introdujo en agosto de 2008 como parte de la iniciativa del IETF. RFC 5246Se diseñó para abordar las limitaciones y vulnerabilidades de versiones anteriores, como TLS 1.0 y TLS 1.1. Este protocolo se utiliza comúnmente para proteger actividades como la banca en línea, el correo electrónico y la transferencia de archivos. En comparación con versiones anteriores, introdujo algoritmos de cifrado más robustos, mejor rendimiento y funciones de seguridad mejoradas. 

El protocolo de enlace TLS 1.2 establece una conexión segura entre un cliente y un servidor a través de dos intercambios de mensajes o viajes de ida y vuelta (2-RTT).  

• Comienza con el cliente enviando un mensaje de “Cliente Hola”, que incluye sus versiones de TLS compatibles, conjuntos de cifrado, un número aleatorio para la generación de clave de cifrado y un ID de sesión opcional para reanudar una sesión anterior.  
• El servidor responde con un "Server Hello" seleccionando una versión de TLS y conjunto de cifrado De la lista proporcionada en el mensaje "Hola del cliente", proporciona su propio número aleatorio e incluye un certificado firmado con su clave pública. Si el cliente incluyó un ID de sesión, el servidor busca una sesión en caché. De lo contrario, genera un nuevo ID de sesión. Tras enviar un mensaje "Hola del servidor", el servidor espera a que el cliente proceda. 
• A continuación, el cliente valida el certificado del servidor para garantizar que una autoridad de certificación lo confíe. Si se requiere autenticación mutua, como en entornos empresariales, el servidor solicita un cliente. certificadoEl cliente envía su certificado, que es validado por el servidor mediante una CA de confianza. Esto confirma la identidad del cliente. 
• Criptografía de clave pública Se utiliza en el proceso de protocolo de enlace para intercambiar de forma segura la clave de sesión, lo que garantiza la confidencialidad. Una vez realizada la autenticación, el cliente envía un mensaje de "Intercambio de claves" con una clave premaestra cifrada con la clave pública del servidor. Incluso si un atacante intercepta el mensaje, no podrá descifrar la clave premaestra sin la clave privada del servidor. Solo el servidor puede descifrar esta clave, ya que la clave privada correspondiente a la clave pública se almacena de forma segura en el servidor y en dispositivos criptográficos como... Módulo de seguridad de hardware (HSM) y bóvedas de claves, y nunca se transmite. Tanto el cliente como el servidor utilizan esta clave premaestra y sus números aleatorios para generar un secreto maestro compartido. Posteriormente, este secreto maestro compartido se utiliza para generar claves de sesión. 
• Finalmente, el cliente y el servidor intercambian los mensajes "Cambiar especificación de cifrado" y "Finalizado". Esto confirma que están listos para cambiar al cifrado simétrico usando la clave de sesión. A partir de este momento, toda la comunicación se cifra de forma segura y las claves de sesión solo duran lo que dura la sesión.

Características principales de TLS 1.2 

TLS 1.2 introdujo varias mejoras para proteger las comunicaciones en redes informáticas. Entre sus características principales se incluyen: 

• Algoritmo hash mejorado

  La combinación de MD5 y SHA-1 utilizada en el hash del mensaje final se sustituyó por opciones más seguras como SHA-256 y SHA-384. Sin embargo, el hash del mensaje final debe seguir teniendo un tamaño mínimo de 96 bits.

• Suites de cifrado AES

  Se introdujo TLS 1.2 Advanced Encryption Standard (AES) Conjuntos de cifrado que ofrecen opciones de cifrado más robustas al admitir claves de 128 y 256 bits. Además, protegen los datos en tránsito y contribuyen a una mayor seguridad general.

• Compatibilidad con cifrado autenticado

  TLS 1.2 amplió la compatibilidad con cifrados de cifrado autenticado, en particular los modos Galois/Counter (GCM) y Counter with CBC-MAC (CCM) del AES. Proporciona mayor integridad y confidencialidad de los datos. 

• Negociación mejorada entre cliente y servidor

  Tanto los clientes como los servidores pueden especificar algoritmos hash y de firma aceptables durante el proceso de protocolo de enlace, lo que mejora la flexibilidad y la seguridad. Esto garantiza la compatibilidad y mitiga las vulnerabilidades asociadas con algoritmos obsoletos o débiles. Por ejemplo, si un algoritmo específico deja de ser seguro (p. ej., SHA-1), los clientes y servidores pueden optar por opciones más robustas como SHA-256 o SHA-384.

TLS 1.3 y su protocolo de enlace 

TLS 1.3 es la versión más reciente del protocolo TLS y está diseñada para mejorar la seguridad y el rendimiento con respecto a su predecesora. TLS 1.3 se presentó oficialmente en agosto de 2018 con la publicación de RFC 8446 por la IETF. El protocolo surge de la creciente necesidad de un cifrado más robusto, configuraciones de conexión más rápidas y funciones de privacidad mejoradas. TLS 1.3 introdujo importantes mejoras en seguridad, velocidad y privacidad. Agilizó el proceso de enlace, eliminó algoritmos criptográficos más débiles y mejoró los métodos de cifrado. Estos cambios proporcionan un marco de comunicación más seguro y eficiente para los protocolos de Internet modernos. 

El proceso de protocolo de enlace TLS 1.3 se realiza en un solo viaje de ida y vuelta (1-RTT), lo que lo hace más rápido que las versiones anteriores. La latencia reducida de 1-RTT en TLS 1.3 es importante para las industrias que requieren comunicación en tiempo real. En los juegos en línea, proporciona una experiencia de juego fluida con menos retrasos. Las plataformas de transmisión en vivo dependen de conexiones rápidas para ofrecer contenido sin interrupciones. Las aplicaciones financieras, como la banca y el comercio en línea, se benefician de velocidades de transacción más rápidas. Además, las plataformas de comunicación de voz y video, como VoIP y las videoconferencias, requieren baja latencia para interacciones fluidas. 

• Comienza con el cliente enviando un mensaje de "Hola". Este mensaje incluye información importante como la versión de TLS compatible con el cliente (en este caso, TLS 1.3), la lista de conjuntos de cifrado y métodos de intercambio de claves compatibles, un número aleatorio generado por el cliente y cualquier extensión adicional que desee incluir. El cliente envía su certificado si la autenticación está habilitada. El servidor puede validar este certificado con la lista de CA de confianza. Esto demuestra la legitimidad del cliente. 
• En respuesta, el servidor genera el secreto maestro utilizando el número aleatorio "ClientHello", su propio número aleatorio generado, los parámetros del cliente y los conjuntos de cifrado seleccionados. A continuación, el servidor envía un mensaje "Server Hello" junto con un mensaje "Server Finished". Esto incluye la versión del protocolo seleccionada por el servidor, los conjuntos de cifrado, el método de intercambio de claves, el número aleatorio generado por el servidor y la Certificado SSL / TLS, y cualquier parámetro opcional. 
• Una vez que el cliente recibe la respuesta del servidor, verifica el certificado del servidor con su lista de servidores de confianza. CA Para garantizar la comunicación con el servidor legítimo, el cliente genera una clave maestra usando su número aleatorio y la información del servidor. Posteriormente, tanto el cliente como el servidor envían un mensaje de "Finalizado" para confirmar que están listos para una comunicación segura. En este punto, tanto el cliente como el servidor comparten la misma clave y pueden comenzar a intercambiar datos de forma segura, utilizando cifrado para proteger su comunicación. 

Características principales de TLS 1.3 

TLS 1.3 introduce varias características clave que mejoran la seguridad, la velocidad y la eficiencia en comparación con versiones anteriores. 

• Datos 0-RTT

  La función de datos 0-RTT (tiempo de ida y vuelta cero) de TLS 1.3 permite a los clientes enviar datos durante el protocolo de enlace, lo que reduce la latencia de configuración de la conexión. Esto resulta beneficioso para aplicaciones en tiempo real como la transmisión de vídeo y los videojuegos. En estas aplicaciones, el establecimiento rápido de la conexión es fundamental para una experiencia de usuario fluida. También puede ser útil en situaciones donde se producen conexiones repetidas al mismo servidor, como en dispositivos IoT que se reconectan frecuentemente a un servidor central. Sin embargo, es vulnerable a ataques de repetición y debe utilizarse con precaución en situaciones sensibles donde estos ataques se pueden prevenir eficazmente. Esto es preocupante porque los datos 0-RTT no están protegidos por las mismas claves de sesión que el resto de la comunicación.

• Elimina el intercambio de claves RSA

  En TLS 1.3, el protocolo basado en RSA intercambio de llaves Se ha eliminado este método en favor de métodos más fuertes como ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), que proporciona mejor seguridad y rendimiento.

• Reenviar secreto

  Es una característica de seguridad clave de TLS 1.3 que garantiza que las claves de sesión nunca se transmitan ni almacenen en la red y se descarten al finalizar la sesión. Incluso si la clave privada de un servidor se ve comprometida en el futuro, las comunicaciones anteriores permanecen seguras y no se pueden descifrar. Esta característica protege la comunicación a largo plazo al garantizar que cada sesión se cifre de forma independiente mediante claves de sesión únicas generadas para esa sesión específica, lo que evita que la vulneración de una clave afecte la confidencialidad de los datos anteriores.

Comparación entre TLS 1.2 y TLS 1.3 

La transición de TLS 1.2 a TLS 1.3 representa un avance significativo en términos de seguridad, rendimiento y eficiencia del protocolo. A continuación, se presenta una tabla comparativa que presenta las diferencias clave entre TLS 1.2 y TLS 1.3. 

Característica	TLS 1.2	TLS 1.3	Desafíos
Proceso de apretón de manos	Dos tiempos de ida y vuelta (2-RTT).	Un tiempo de ida y vuelta (1-RTT).	La alta latencia en los datos 0-RTT de TLS 1.2 y TLS 1.3 aumenta el riesgo de ataques de repetición si no se implementa de forma segura.
Suites de cifrado	Admite una amplia gama de conjuntos de cifrados, incluidos los más débiles.	Sólo se permiten conjuntos de cifrado AEAD (cifrado autenticado con datos asociados), lo que garantiza una mayor seguridad.	Los sistemas heredados que dependen de conjuntos de cifrado más débiles requieren actualizaciones para la compatibilidad con TLS 1.3.
Intercambio de claves	Compatible con RSA, DHE y ECDHE.	Solo compatible con ECDHE.	La eliminación de RSA y DHE en TLS 1.3 complica la integración de los sistemas que dependen de estos métodos.
Secreto hacia adelante	Opcional.	El secreto obligatorio y directo se aplica de forma predeterminada.	Los sistemas heredados que no están configurados para el secreto hacia adelante necesitan una reconfiguración, lo que potencialmente aumenta los esfuerzos de migración.
Algoritmos de encriptación	Incluye algoritmos obsoletos como RC4 y CBC.	Requiere algoritmos más fuertes como AES-GCM y ChaCha20-Poly1305.	La transición desde algoritmos obsoletos requiere actualizar bibliotecas y aplicaciones.
Reanudación de la sesión	Utiliza identificadores de sesión o tickets de sesión para la reanudación.	Admite la reanudación de sesión con datos 0-RTT, lo que reduce la latencia.	Los datos 0-RTT de TLS 1.3 corren el riesgo de sufrir ataques de repetición, mientras que los tickets de sesión en TLS 1.2 pueden no gestionarse de forma segura.
Mejoras de seguridad	Vulnerable a ataques como BEAST, POODLE y Heartbleed.	Seguridad mejorada con mensajes de protocolo de enlace cifrados y eliminación de protocolos inseguros.	Para migrar de forma segura es necesario identificar y mitigar vulnerabilidades en versiones anteriores de TLS.
Validación de certificado	Admite la validación de certificados, pero puede exponer ciertos detalles del protocolo de enlace.	Más seguro, ya que los mensajes de protocolo de enlace están cifrados.	Es esencial actualizar la infraestructura existente para gestionar protocolos de enlace cifrados sin problemas de compatibilidad.
Datos 0-RTT	No soportado.	Se admite y permite el envío de datos durante el protocolo de enlace (pero es susceptible a ataques de repetición).	Los datos 0-RTT presentan riesgo de ataques de repetición y requieren una validación cuidadosa y un uso limitado únicamente en escenarios sensibles.
Rendimiento	Más lento debido al protocolo de enlace 2-RTT y pasos de procesamiento adicionales.	Más rápido gracias a un protocolo de enlace simplificado y un intercambio de claves optimizado.	Las redes de alta latencia se benefician más de TLS 1.3, pero la implementación debe garantizar un soporte adecuado para el flujo optimizado.

TLS 1.3 se considera ampliamente un mejor protocolo en comparación con TLS 1.2 debido a varias mejoras clave en seguridad, rendimiento y eficiencia. En primer lugar, TLS 1.3 mejora la seguridad al eliminar algoritmos obsoletos y vulnerables (RC4, DES, MD5 y SHA1) y aplicar... secreto hacia adelantePermite que las comunicaciones anteriores se mantengan seguras incluso si la clave privada de un servidor se ve comprometida posteriormente. Por otro lado, TLS 1.2 admite métodos criptográficos más débiles y no exige confidencialidad directa. En términos de rendimiento, TLS 1.3 ofrece una configuración de conexión más rápida al reducir el proceso de protocolo de enlace a un solo tiempo de ida y vuelta (1-RTT), en comparación con los dos o más RTT requeridos por TLS 1.2. Este protocolo de enlace más rápido mejora significativamente la latencia, especialmente para aplicaciones como los juegos en línea.

Además, TLS 1.3 reduce la sobrecarga computacional al simplificar el protocolo, ya que optimiza el proceso de intercambio de claves mediante el uso de Diffie-Hellman efímero y elimina la necesidad de mecanismos de intercambio de claves independientes como RSA, que se utilizaban en TLS 1.2. Esta reducción de la complejidad no solo mejora la eficiencia, sino que también reduce la probabilidad de errores de implementación. Las versiones de TLS anteriores a la 1.3 admitían la compresión, pero esta función era vulnerable a ataques. En TLS 1.3, la compresión se elimina enviando un byte nulo en el campo legacy_compression_methods. Estos factores convierten a TLS 1.3 en la opción preferida para comunicaciones web modernas, seguras y eficientes. 

A partir de mayo de 2024, un escaneo realizado por Laboratorios SSL de Qualys Esto demuestra que TLS 1.2 sigue gozando de una amplia aceptación. El 99.9 % de los sitios web son compatibles con la versión 1.2, mientras que el 70.1 % utiliza TLS 1.3, frente al 67.5 % en enero de 2024. El constante aumento en la adopción de TLS 1.3 refleja su mayor seguridad y menor latencia, lo que lo convierte en la opción preferida para las aplicaciones modernas.  

La migración de TLS 1.2 a TLS 1.3 implica varios desafíos importantes. Muchos sistemas y dispositivos heredados son incompatibles con TLS 1.3 y pueden requerir costosas actualizaciones o reemplazos para dar soporte al nuevo protocolo. Esto puede ser especialmente difícil para industrias que dependen en gran medida de infraestructuras antiguas. TLS 1.3 elimina ciertas funciones criptográficas, como el intercambio de claves RSA, lo que obliga a las organizaciones a reconfigurar sus sistemas para adoptar métodos más seguros, como el intercambio de claves efímeras Diffie-Hellman de curva elíptica. Esto puede interrumpir las aplicaciones que dependen de algoritmos que ya no son compatibles con el nuevo protocolo. 

TLS 1.3 introduce cambios en el proceso de protocolo de enlace y los mecanismos de reanudación de sesión. Estos cambios requieren actualizaciones de la lógica de la aplicación, especialmente en sistemas con flujos de autenticación o conexión complejos. Las pruebas y la validación son cruciales para garantizar que la migración no interrumpa los flujos de trabajo existentes ni genere problemas de rendimiento. Estos desafíos exigen una inversión considerable de tiempo, esfuerzo y coordinación entre los equipos de TI para garantizar la compatibilidad y una integración fluida. 

Vulnerabilidades  

Aunque TLS 1.2 y TLS 1.3 mitigan muchos de los riesgos asociados a su predecesor, ningún protocolo es perfecto y ambos presentan vulnerabilidades. TLS 1.2 no exige el uso de MD5 ni SHA-1, pero los admite para garantizar la retrocompatibilidad. El protocolo permite su uso si un servidor o cliente los selecciona explícitamente. Sin embargo, TLS 1.2, a pesar de su amplia adopción, es vulnerable debido a su compatibilidad con algoritmos criptográficos más débiles como MD5 y SHA-1, propensos a colisiones y ataques de fuerza bruta. ataques.  

TLS 1.2 ha sido explotado mediante varios ataques de alto perfil que se centran en sus vulnerabilidades. El ataque BEAST (Browser Exploit Against SSL/TLS) explotó debilidades en el modo Cipher Block Chaining y permitió a los atacantes descifrar fragmentos de tráfico cifrado interceptado. De igual forma, la vulnerabilidad Heartbleed en la implementación de TLS en OpenSSL permitió a los atacantes extraer información confidencial, como claves privadas y datos de sesión, de la memoria del servidor mediante solicitudes de latido maliciosas. El ataque POODLE (Padding Oracle on Downgraded Legacy Encryption) aprovechó fallas en el relleno del modo CBC y explotó escenarios en los que los servidores admitían protocolos de respaldo menos seguros como SSL 3.0. 

Además, el ataque Raccoon ataca el proceso de intercambio de claves Diffie-Hellman mediante técnicas de canal lateral basadas en tiempo para medir pequeñas variaciones en los tiempos de cálculo del intercambio de claves. Esto puede permitir a los atacantes recuperar partes de la clave de sesión y comprometer la confidencialidad de la comunicación. Mantener la retrocompatibilidad y una seguridad sólida es difícil. 

TLS 1.3 soluciona muchas de estas debilidades eliminando algoritmos criptográficos obsoletos y simplificando el proceso de protocolo de enlace, pero no es totalmente inmune a vulnerabilidades específicas de la implementación. Estas vulnerabilidades suelen surgir de la forma en que diversas bibliotecas, servidores o aplicaciones implementan el protocolo. Por ejemplo, pueden producirse fallos si se utilizan nonces (números aleatorios o vectores de inicialización [IV]) para inicializar ciertos... algoritmos de encriptación Como CBC o AES-GCM, no se aleatorizan correctamente. Esto puede generar patrones de cifrado predecibles que podrían explotarse. El manejo inadecuado de los mecanismos de intercambio de claves puede exponer las claves privadas si los parámetros son débiles o se reutilizan. Las configuraciones incorrectas, como la elección de conjuntos de cifrado débiles o la configuración incorrecta de la confidencialidad directa, también pueden reducir la seguridad. 

Para mitigar los riesgos asociados con las vulnerabilidades específicas de la implementación de TLS 1.3, es importante garantizar el uso de parámetros criptográficos robustos. Configuraciones como la selección de curvas elípticas de alta calidad, el uso de rotación segura de claves, la generación adecuada de números aleatorios y el evitar conjuntos de cifrado débiles u obsoletos como RC4 y DES son vitales. También es crucial deshabilitar la opción de respaldo a protocolos antiguos como TLS 1.2 o SSL, que podrían exponer vulnerabilidades. Se debe priorizar la aplicación regular de parches y actualizaciones de las bibliotecas TLS para corregir las fallas recién descubiertas. Las auditorías de seguridad detalladas y el análisis continuo de vulnerabilidades son esenciales para detectar configuraciones incorrectas, claves débiles o componentes obsoletos, y garantizar que las implementaciones de TLS 1.3 se mantengan seguras y actualizadas. 

El NIST Se ha detectado una vulnerabilidad en la política TLS 1.3 del software Cisco Firepower Threat Defense (FTD) con funcionalidad de categoría de URL. Esta vulnerabilidad podría permitir a atacantes remotos no autenticados eludir las políticas de bloqueo de URL configuradas. Esta situación se debe a un error lógico en la gestión de conexiones TLS 1.3 por parte de Snort y puede explotarse mediante solicitudes TLS 1.3 especialmente diseñadas. Permite el acceso a URL restringidas que normalmente estarían bloqueadas.  

¿Cómo puede ayudar la consultoría de cifrado?

En Encryption Consulting, ayudamos a las organizaciones a afrontar los retos de la transición de TLS 1.2 a TLS 1.3 mediante soluciones de cifrado personalizadas. Estas soluciones satisfacen las necesidades de seguridad específicas de nuestros clientes. Nuestro equipo de expertos altamente cualificados ofrece una amplia gama de servicios, que incluyen evaluaciones exhaustivas, auditorías, planificación estratégica e implementación de un proceso de migración sin complicaciones. Ayudamos a los clientes a identificar problemas de compatibilidad, configurar la compatibilidad con protocolos duales y optimizar la configuración de cifrado para mejorar la seguridad. Al ofrecer asesoramiento personalizado durante la transición, garantizamos que la migración a TLS 1.3 se ajuste a los objetivos de seguridad específicos del cliente, minimizando al mismo tiempo los riesgos y las interrupciones. 

Conclusión 

TLS es importante para mantener la seguridad de los datos cuando viajan a través de redes. Utiliza cifrado de clave pública y un apretón de manos Proceso para proteger la comunicación entre clientes y servidores. Si bien TLS 1.2 sigue siendo ampliamente utilizado debido a su compatibilidad con numerosos sistemas, TLS 1.3 está ganando popularidad. Esto se debe a que TLS 1.3 ofrece conexiones más rápidas, mayor seguridad y un diseño más simple. Reduce los retrasos, optimiza la velocidad de los sitios web y mejora la experiencia del usuario. Además, elimina funciones débiles y corrige vulnerabilidades de versiones anteriores, lo que dificulta su explotación por parte de los hackers.

Las organizaciones que realizan la transición de TLS 1.2 a TLS 1.3 deben evaluar primero la compatibilidad de su infraestructura y asegurarse de que los sistemas críticos sean compatibles con el nuevo protocolo. Se debe adoptar un enfoque gradual, habilitando inicialmente TLS 1.3 en un entorno de prueba y eliminando los protocolos obsoletos. Los equipos de seguridad deben recibir capacitación sobre las mejores prácticas de TLS 1.3, y la retrocompatibilidad con TLS 1.2 debe mantenerse temporalmente hasta que se complete la migración. La retrocompatibilidad es necesaria durante el período de migración, ya que garantiza que los sistemas y clientes que aún no son compatibles con TLS 1.3 puedan comunicarse de forma segura mediante TLS 1.2. Esto garantiza que los usuarios y los servicios sigan funcionando sin problemas durante la transición, a la vez que reduce las interrupciones. 

Sin compatibilidad con versiones anteriores, las organizaciones pueden correr el riesgo de interrumpir las conexiones con sistemas, dispositivos o clientes antiguos que utilizan protocolos heredados, lo que podría provocar interrupciones del servicio o problemas de seguridad. Además, es fundamental realizar pruebas y evaluaciones de vulnerabilidades periódicas durante todo el proceso. TLS 1.3 no es directamente compatible con versiones anteriores de TLS 1.2, lo que significa que no puede utilizarse directamente con sistemas que utilizan versiones anteriores de TLS. Por ello, se recomienda a las empresas que admitan ambas versiones durante la transición. Este enfoque garantiza la seguridad de las transacciones de datos en sistemas antiguos, a la vez que permite la adopción del protocolo TLS 1.3, mejorado y más seguro, para aplicaciones y sitios web más recientes.