Protocolo TLS 1.3 vs TLS 1.2

Continuando con la pequeña serie de publicaciones dedicadas a SSL y TLS, creo que a estas alturas tenemos todos una idea clara de la importancia sobre el uso de esta tecnología. Tanto si somos meros consumidores de la información, como si participamos en la creación y/o su manipulación, hoy por hoy, en un mudo donde la información (sea del tipo que sea), es el nuevo oro, es de vital importancia mantener el nivel mas alto de seguridad que nos podamos permitir.

Pero en este articulo lo que quiero enseñaros son las diferencias entre las dos ultimas versiones del protocolo TLS, pero ¿porque las dos ultimas?, bueno pues primero porque al ser las ultimas versiones, son las mas utilizadas y segundo porque las diferencias de funcionamiento entre ellas son grandes y muy relevantes.

Esta claro que TLS 1.2 es el predecesor natural de TLS 1.3 y que este último introduce varias mejoras con respecto al primero. Pero sabemos veamos cuales son los puntos clave de sus diferencias:

La velocidad

El TLS 1.2 necesita al menos 4 mensajes (2-RTT) antes de iniciar la comunicación cifrada.

1. ClientHello: El cliente envía un mensaje ClientHello al servidor, incluyendo las versiones de TLS soportadas, las suites de cifrado admitidas, opciones para compresión, así como información para la negociación de claves (si aplica).

2. ServerHello: El servidor responde con un mensaje ServerHello, indicando la versión de TLS seleccionada, la suite de cifrado elegida, certificados digitales para autenticación y también la claves públicas si se usa intercambio de claves asimétrico (como RSA o Diffie-Hellman).

3. ClientKeyExchange: El cliente genera y envía información para la clave compartida (en función del método de intercambio acordado) y opcionalmente, también el cliente puede autenticar al servidor en este mismo paso.

4. Handshake final: Ambas partes generan las claves de sesión y envían un mensaje de confirmación (Finished), desde aquí la sesión segura comienza a ser usada.

Por su parte con TLS 1.3 se necesita solo 2 mensajes (1-RTT) o incluso 1 mensaje (0-RTT) para re-conexiones, lo que reduce la latencia significativamente.

1. ClientHello: El cliente envía ClientHello, incluyendo las suites de cifrado preferidas, información para la negociación de claves mediante Diffie-Hellman (en modo Ephemeral). Opcionalmente, datos previos si se busca una reconexión (0-RTT).

2. ServerHello + Handshake combinado: El servidor responde con ServerHello, seleccionando la suite de cifrado, la clave pública para establecer la clave compartida, el servidor incluye en este mensaje los datos necesarios para la clave de sesión y un mensaje de confirmación.

3. Handshake final (opcional): El cliente y el servidor confirman la clave compartida y verifican la autenticidad mutuamente, pero si se trata de una reconexión (0-RTT), este paso puede omitirse.

Seguridad

TLS 1.2 ofrece mucha flexibilidad, pero esto introduce riesgos debido al soporte de algoritmos obsoletos.

1. Selección del algoritmo de intercambio de claves: El cliente y el servidor acuerdan el método de intercambio de claves durante el handshake, soportando:

Cifrado

Con TLS 1.2 el cifrado depende de una negociación durante el handshake, y los pasos para esto incluyen:

1. Negociación de la suite de cifrado: El cliente envía una lista de suites de cifrado soportadas en el mensaje ClientHello, el servidor selecciona una suite de cifrado compatible y la notifica en ServerHello. Entre las suites de cifrado podemos encontrar el RC4, AES-CBC o el AES-GCM, siendo este ultimo el mas seguro y eficiente de los tres.

2. Intercambio de claves: Dependiendo de la suite elegida, el intercambio puede usar RSA para cifrar una clave compartida, sin Perfect Forward Secrecy (PFS), Diffie-Hellman (DH), que podra ser estático o efímero (con PFS solo si es efímero) y también Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), que siempre proporciona PFS.

3. Cifrado del tráfico: Una vez completado el handshake, se usa la clave compartida para cifrar los datos con el algoritmo acordado, pudiendo realizarse este con AES-CBC o AES-GCM.

4. Autenticación y verificación: Se utilizan funciones hash como SHA-1 o SHA-256 para generar códigos de autenticación.

Con todo lo comentado, nos encontramos con que por ejemplo RC4 esta desaconsejado por inseguro, el AES-CBC es vulnerable a ataques de tipo BEAST y para rematar la faena, tenemos al SHA-1 que es considerado inseguro pero aún sigue siendo soportado.

Por su parte TLS 1.3 simplifica el cifrado eliminando opciones inseguras y mejorando la eficiencia, estando compuesto por los siguientes pasos:

1. Negociación de la suite de cifrado: El cliente y el servidor acuerdan una suite de cifrado desde una lista más limitada y moderna de suites que es enviada en ClientHello, estando solo soportadas AES-GCM y AES-CCM para un cifrado rápido y seguro, o ChaCha20-Poly1305 que esta optimizado para dispositivos con hardware limitado.

2. Intercambio de claves: Solo utiliza métodos con Perfect Forward Secrecy (PFS) como Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) y Finite Field Diffie-Hellman Ephemeral (DHE). Siendo las claves compartidas generadas de manera efímera, garantizando así que incluso si se comprometen las claves privadas, el tráfico pasado permanecerá seguro.

3. Cifrado del tráfico: El tráfico se cifra inmediatamente después de completar el handshake inicial, ademas todas las suites incluyen Autenticación y Cifrado Asociados (AEAD), combinando cifrado y autenticidad en un único paso.

4. Autenticación y verificación: Solo se utilizan funciones hash modernas y seguras como SHA-256 o SHA-384.

5. Eliminación de cifrados obsoletos: se han elimina los métodos inseguros como RC4, AES-CBC y cualquier cifrado que no soporte AEAD.

Notas y aclaraciones:

• El RTT representa la suma del tiempo de ida y el de vuelta de un paquete o mensaje.

• Perfect Forward Secrecy (PFS) es una característica de los protocolos de cifrado que garantiza que las claves de sesión utilizadas para cifrar una comunicación no puedan ser comprometidas incluso si la clave privada a largo plazo del servidor o del cliente es robada en el futuro.

• Un ataque BEAST consiste en una vulnerabilidad en el protocolo SSL/TLS que afecta principalmente a TLS 1.0 y SSL 3.0. Este ataque permite a un atacante interceptar y descifrar datos cifrados, como cookies de sesión o información sensible, utilizando un ataque de man-in-the-middle (MITM) combinado con técnicas de inyección maliciosa

• Un ataque POODLE es una vulnerabilidad que afecta al protocolo SSL 3.0 y ciertos modos de implementación incorrecta de TLS, específicamente el cifrado en modo CBC (Cipher Block Chaining). Este ataque permite a un atacante descifrar información sensible, como cookies de sesión o datos cifrados, mediante un ataque de man-in-the-middle (MITM).

• RSA: Utilizado para cifrar y enviar una clave compartida.

• Diffie-Hellman estático (DH): Permite generar claves compartidas pero no ofrece Perfect Forward Secrecy (PFS).

• Elliptic Curve Diffie-Hellman Ephemeral (ECDHE): Proporciona PFS, pero no es obligatorio.

2. Autenticación del servidor: El servidor envía un certificado digital firmado por una autoridad certificadora (CA) para probar su identidad, aqui puede usarse SHA-1 o SHA-256 como algoritmo hash, aunque SHA-1 tiene vulnerabilidades conocidas.

3. Cifrado de datos: TLS 1.2 soporta una amplia gama de suites de cifrado, incluyendo opciones inseguras como RC4, CBC ambos vulnerables a diferentes ataques. Anque tambien usa métodos modernos como AES-GCM, pero su uso depende de la configuración del servicio.

4. Renegociación: TLS 1.2 permite renegociar las claves y parámetros de la conexión durante una sesión activa, lo que puede ser explotado por los malos.

TLS 1.3 Se centra exclusivamente en métodos modernos y elimina características y algoritmos inseguros.

1. Selección del algoritmo de intercambio de claves: Solo soporta Diffie-Hellman Ephemeral (DHE) y Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), garantizando Perfect Forward Secrecy (PFS). Esto asegura que las claves de sesión no puedan ser recuperadas incluso si el secreto a largo plazo se compromete.

2. Autenticación del servidor: El servidor envía su certificado digital durante el ServerHello, pero solo permite el uso de SHA-256 y SHA-384 como algoritmos hash, eliminando opciones obsoletas.

3. Cifrado de datos: se reducen las opciones a métodos robustos como AES-GCM y AES-CCM, incluyendo ademas ChaCha20-Poly1305 para dispositivos con hardware limitado y eliminando el modo CBC y el cifrado RC4.

4. Eliminación de renegociación: La renegociación se elimina completamente, reduciendo asi la superficie de ataque.

5. Cero intercambio inseguro: TLS 1.3 asegura que ningún dato no cifrado (como certificados y claves públicas) sea enviado hasta que se haya establecido una clave compartida y cifrada.

Retrocompatibilidad

TLS 1.2 prioriza permitir conexiones con clientes o servidores que utilicen versiones previas del protocolo. Esto introduce una mayor flexibilidad, pero también riesgos de seguridad.

• Negociación de la versión del protocolo: El cliente incluye un rango de versiones de TLS soportadas (ej., 1.0, 1.1, 1.2) en el mensaje ClientHello. Por su parte el servidor selecciona la versión más alta que ambos soporten y la comunica en el mensaje ServerHello.

• Soporte de algoritmos obsoletos: Para ser compatible con sistemas más antiguos, permite algoritmos como RC4, SHA-1, RSA, que ya no son recomendados, pero su soporte persiste para evitar fallos en la conexión.

• Compatibilidad con configuraciones débiles: TLS 1.2 admite el modo de cifrado CBC (Cipher Block Chaining), que es vulnerable a ataques como BEAST y POODLE si no se configura correctamente. Esto permite conexiones con sistemas que no soportan modos más modernos como GCM (Galois Counter Mode).

• Posibilidad de downgrade (reducción de versión): Si el cliente y el servidor no acuerdan TLS 1.2, pueden "reducir" la versión utilizada a una anterior, como TLS 1.1 o 1.0, lo cual puede exponer la conexión a ataques como POODLE (en TLS 1.0).

TLS 1.3 fue diseñado para eliminar algoritmos y características inseguros, lo que significa que no es compatible con versiones anteriores, a cambio se mejora significativamente la seguridad.

• Negociación estricta de la versión del protocolo: El cliente y el servidor acuerdan usar exclusivamente TLS 1.3., si alguna de las partes lo no soporta, la conexión fallara en lugar de intentar hacer un downgrade de la misma.

• Eliminación de algoritmos obsoletos: no se admiten RC4, SHA-1, o el intercambio de claves sin PFS como RSA estático, así se asegura que solo se usen algoritmos seguros y modernos.

• Simplificación de las suites de cifrado: no se permite la negociación de suites de cifrado antiguas, eliminando la posibilidad de configuraciones inseguras, por tanto solo permite suites modernas con cifrado AEAD, como AES-GCM y ChaCha20-Poly1305.

• Protección contra ataques de downgrade: se implementan mecanismos como el "downgrade prevention", que evita que un atacante fuerce a las partes a usar versiones anteriores de TLS. Si el servidor recibe un ClientHello con indicios de compatibilidad con versiones previas, puede rechazar la conexión.

Handshake

TLS 1.2 puede requerir 2 viajes de ida y vuelta (2-RTT) antes de que se establezca una conexión cifrada. Por lo que los pasos requeridos son:

1. ClientHello, el cliente envía las versiones de TLS soportadas (e.g., TLS 1.0, 1.1, 1.2), las suites de cifrado disponibles, opciones de compresión (ya obsoletas pero soportadas) y los datos para el intercambio de claves (como parámetros RSA o Diffie-Hellman).

2. ServerHello, el servidor responde con la versión de TLS seleccionada, la suite de cifrado elegida, certificado digital para autenticación (contiene la clave pública del servidor) y también los parámetros necesarios para el intercambio de claves (si se utiliza Diffie-Hellman).

3. Intercambio de claves, si se utiliza RSA, el cliente cifra una clave simétrica con la clave pública del servidor y la envía, si por le contrario si se utiliza Diffie-Hellman (DH o ECDHE) el cliente y el servidor comparten parámetros públicos y generan una clave simétrica compartida.

4. Finalización del handshake, ambas partes generan las claves de sesión a partir de los parámetros negociados, donde cada parte envía un mensaje Finished que confirma la autenticación mutua y la negociación exitosa, por tanto el tráfico sera cifrado a partir de este punto.

De este proceso podemos destacar algunas limitaciones como un alta latencia, ya que necesita múltiples viajes para completar el proceso, un excesiva flexibilidad que permite el uso algoritmos inseguros si no se configura adecuadamente. Ademas no siempre se garantiza Perfect Forward Secrecy (PFS) cuando se usa RSA estático, por lo que las claves pueden ser comprometidas.

TLS 1.3 reduce el handshake a 1 viaje de ida y vuelta (1-RTT) o incluso 0-RTT para reconexiones, lo que acelera la conexión. Quedando el proceso reducido a los siguientes pasos:

1. ClientHello, el cliente envía las suites de cifrado soportadas (solo opciones modernas como AES-GCM y ChaCha20-Poly1305), los parámetros para el intercambio de claves efímero (DHE o ECDHE) y opcionalmente, datos para reanudar una conexión previa (0-RTT).

2. ServerHello + Finalización combinada, el servidor responde con la suite de cifrado seleccionada, los parámetros para generar la clave compartida (DHE o ECDHE) y la confirmación del handshake y autenticación con su certificado digital. Aqui el tráfico puede empezar a cifrarse inmediatamente.

3. Cifrado inmediato, tanto el cliente como el servidor generan las claves de sesión usando la clave compartida, por lo que los mensajes finales (Finished) se intercambian bajo cifrado, verificando la autenticidad mutua.

4. Reconexión (0-RTT, opcional), si ya se realizo una conexión previa, el cliente puede enviar datos cifrados en el primer mensaje (ClientHello), lo que reduce aún más la latencia, aunque esto introduce riesgos de replay attacks, pero que se pueden mitigar con mecanismos adicionales disponibles.

Como hemos visto TLS 1.3 gana en eficiencia ya que el handshake es más rápido y requiere menos pasos, por otra parte la seguridad mejora al eliminar algoritmos y configuraciones obsoletas y como remate hace uso de Perfect Forward Secrecy (PFS) de forma obligatoria, por lo que solo permite métodos de intercambio efímeros. Todo esto lo convierte en un protocolo bastante robusto y confiable.

Compresion

En TLS 1.2, la compresión es una opción negociable durante el handshake y consta de los siguientes pasos clave:

• ClientHello: El cliente incluye una lista de métodos de compresión soportados en el mensaje ClientHello, pudiendo ser "null" para indicar que no se realiza compresión o "DEFLATE" que es un método estándar para comprimir datos. También se pueden indicar métodos personalizados aunque rara vez son utilizados.

• ServerHello: El servidor selecciona un método de compresión de la lista proporcionada por el cliente, informando del método seleccionado en el mensaje ServerHello.

• Compresión de datos: Si se acuerda un método de compresión, los datos transmitidos entre el cliente y el servidor se comprimen antes de ser cifrados. Esto reduce el tamaño de los paquetes, especialmente útil para conexiones con ancho de banda limitado.

La compresión introduce riesgos como el ataque CRIME (Compression Ratio Info-leak Made Easy) que explota la correlación entre el tamaño de los datos comprimidos y el contenido de texto plano y ademas facilita que el atacante deduzca información sensible, como cookies o tokens de sesión.

TLS 1.3 elimina completamente el soporte para la compresión durante el handshake, reduciendose asi los pasos clave a los siguientes:

• ClientHello: El cliente no incluye ninguna opción de compresión en su mensaje ClientHello. La compresión no es negociable en TLS 1.3.

• ServerHello: El servidor tampoco ofrece ni selecciona ningún método de compresión.

• Transmisión de datos: Todos los datos transmitidos entre el cliente y el servidor permanecen sin comprimir. Esto elimina cualquier riesgo asociado a la compresión, como el ataque CRIME.

Renegociación

En TLS 1.2, la renegociación puede realizarse durante una conexión activa, repitiendo parte del handshake. Quedando los pasos necesarios distribuidos como sigue:

1. Iniciación de la renegociación: Esta puede ser iniciada por el cliente (por ejemplo, para cambiar de un certificado de cliente a otro), o por el servidor (por ejemplo, para pedir autenticación adicional del cliente).

2. Un nuevo handshake sobre la conexión existente:

   • ClientHello: El cliente envía un nuevo mensaje ClientHello indicando los parámetros que desea renegociar.

   • ServerHello: El servidor responde con sus parámetros seleccionados.

   • Intercambio de claves: Las claves de sesión pueden ser renegociadas o permanecer iguales, dependiendo de los parámetros acordados.

   • Finalización: Ambas partes envían un mensaje Finished confirmando el nuevo estado.

3. Reanudación de la sesión: Una vez completada la renegociación, la conexión continúa con los nuevos parámetros.

Este proceso introduce vulnerabilidades como el que un atacante puede inyectar comandos o datos antes de que se renegocie la conexión, engañando al servidor para procesarlos como si provinieran del cliente legítimo. por otro lado la renegociación agrega tiempo y complejidad al flujo de la conexión.

Sin embargo TLS 1.3 elimina la renegociación completamente y la reemplaza por un nuevo mecanismo más seguro y eficiente consistente en la actualización de claves de sesión. Quedando los pasos clave como sigue:

1. Establecimiento inicial de la conexión: Se realiza un handshake estándar y se establecen los parámetros de la sesión.

2. Actualización de claves (Key Update): Si es necesario cambiar las claves de cifrado (por ejemplo, después de un período prolongado de conexión), se utiliza el mensaje KeyUpdate. Este mensaje solicita que ambas partes actualicen las claves de sesión derivadas de la clave principal sin necesidad de un nuevo handshake.

3. Sin renegociación del handshake: No se permite renegociar parámetros como suites de cifrado, certificados o versiones del protocolo y si se requieren cambios significativos, debe establecerse una nueva conexión TLS.

Las ventajas principales de eliminar la renegociación, son evitar la vulnerabilidad de inyección de datos asociada con el ataque de renegociación insegura, como efecto secundario se simplifica el protocolo al evitar handshakes redundantes durante la conexión.

Conclusiones finales

En términos generales podemos decir que TLS 1.3 mejora la velocidad, la seguridad y ademas simplifica el protocolo en si mismo, al eliminar características obsoletas y por tanto reducir varias vulnerabilidades, eso no quiere decir que el TLS 1.2 no siga siendo necesario, ante cualquier conexión que necesitemos asegurar debemos usar siempre la versión mas actual disponible y si la única disponible es la 1.2, ademas debemos asegurarnos de que este bien configurada.