TLS 1.3: La evolución del protocolo que hace HTTPS más seguro y rápido

TLS 1.3 es la versión más reciente del protocolo que protege la conexión entre el navegador y el sitio web. Gracias a TLS, los datos transmitidos a través de una conexión HTTPS están cifrados, lo que impide que terceros puedan interceptar el tráfico y leer contraseñas, formularios u otra información sensible.

Sin embargo, HTTPS no es un algoritmo de cifrado independiente; en realidad, es simplemente HTTP funcionando sobre un canal seguro proporcionado por TLS. Antes de que los datos se envíen, el navegador y el servidor negocian los parámetros de la conexión, acuerdan los algoritmos criptográficos y generan claves compartidas.

Con la llegada de TLS 1.3, este proceso se ha simplificado notablemente respecto a versiones anteriores. Se eliminaron mecanismos obsoletos, se redujeron los intercambios necesarios entre cliente y servidor y se comenzó a cifrar antes los mensajes de control. Como resultado, el HTTPS moderno es ahora más seguro y más rápido.

TLS 1.3: qué es y qué papel desempeña en HTTPS

TLS significa Transport Layer Security, es decir, "seguridad de la capa de transporte". Su función principal es crear un canal seguro entre dos participantes de una conexión: en el caso de un sitio web, normalmente el navegador del usuario y el servidor web.

Cuando ves https:// en la barra de direcciones, el navegador primero establece una conexión TLS y solo entonces transmite las solicitudes HTTP a través de ese canal cifrado. Así, podemos imaginar HTTPS como HTTP viajando dentro de un túnel cifrado.

TLS resuelve varias tareas a la vez:

• Cifra los datos transmitidos para que no puedan ser leídos si son interceptados.
• Permite que el navegador verifique que se está conectando al servidor correcto.
• Controla la integridad de los datos y detecta cualquier intento de modificación durante la transmisión.

¿En qué se diferencia TLS de HTTPS?

TLS no está ligado exclusivamente a los sitios web; es un protocolo criptográfico universal sobre el que pueden funcionar diferentes protocolos de aplicación. HTTPS es solo una de las implementaciones más comunes de TLS.

Por eso, los términos "cifrado HTTPS" y "cifrado TLS" a menudo se usan como sinónimos, aunque técnicamente corresponden a distintos niveles. HTTPS define cómo el navegador y el servidor intercambian datos web, mientras que TLS garantiza la seguridad del canal de comunicación.

Por ejemplo, el navegador puede hacer solicitudes HTTP para páginas, APIs o imágenes. Si se usa HTTPS, ese tráfico se protege con TLS antes de enviarse y se descifra en el servidor al recibirlo.

Si quieres saber más sobre el proceso completo desde que introduces una URL hasta la carga total de la página, consulta el artículo ¿Qué sucede cuando abres un sitio web? Así carga el navegador una página paso a paso.

¿Qué datos protege TLS?

Una vez establecida la conexión segura, TLS cifra todos los datos de aplicación que pasan entre cliente y servidor. Esto incluye:

• Contenido de las páginas web visitadas;
• Nombre de usuario y contraseñas;
• Mensajes y comentarios;
• Consultas de búsqueda;
• Datos introducidos en formularios;
• Solicitudes a APIs;
• Archivos transferidos;
• Cookies y otros elementos del tráfico HTTP.

Con una configuración correcta de HTTPS, incluso si alguien intercepta los paquetes de red, no podrá ver el contenido de los datos, solo un flujo cifrado.

No obstante, TLS no garantiza el anonimato total. Un observador aún puede ver las direcciones IP, el volumen de datos transmitidos, los tiempos de intercambio y otros metadatos. Pero el contenido del tráfico HTTPS permanece protegido.

¿Por qué es importante TLS 1.3?

TLS ha evolucionado durante décadas, y cada versión ha corregido fallos anteriores. TLS 1.3, estandarizado en 2018, supone una revisión profunda del protocolo, no solo una actualización menor respecto a TLS 1.2.

Se eliminaron algoritmos criptográficos antiguos y métodos de intercambio de claves estáticos, se redujo la cantidad de combinaciones posibles y se modificó el proceso de establecimiento de la conexión. Además, tras el mensaje ServerHello, el resto del "handshake" en TLS 1.3 ya se transmite cifrado.

Como resultado, navegador y servidor necesitan menos pasos para empezar a transmitir datos protegidos, lo que explica por qué TLS 1.3 es más rápido que generaciones anteriores.

¿Cómo funciona HTTPS y cómo se establece la conexión segura?

Al introducir una dirección web y pulsar Enter, el navegador no comienza inmediatamente a transmitir datos por HTTPS. Primero, debe establecer una conexión de red con el servidor y luego crear un canal seguro usando TLS.

Tras obtener la dirección IP del sitio, el navegador se conecta al servidor y lanza el proceso conocido como TLS handshake, durante el cual cliente y servidor acuerdan los parámetros de la futura conexión segura.

¿Qué ocurre tras introducir la dirección web?

De manera resumida, el proceso es así: el navegador resuelve la IP del dominio vía DNS, se conecta al servidor y comunica las versiones de TLS y parámetros criptográficos que soporta.

En TLS 1.3, el primer mensaje del cliente es ClientHello, donde el navegador envía la lista de conjuntos criptográficos compatibles, extensiones adicionales del protocolo e información necesaria para el inicio del intercambio de claves.

El servidor responde con ServerHello, eligiendo los parámetros adecuados. A partir de ahí, ambas partes pueden calcular un secreto compartido del que se derivarán las claves para el cifrado posterior.

La principal diferencia de TLS 1.3 es que la mayor parte de la información para el intercambio de claves se transmite ya en el primer mensaje del cliente, eliminando rondas adicionales de negociación que eran necesarias en TLS 1.2.

TLS handshake en palabras sencillas

El TLS handshake es como una breve revisión antes de una conversación privada: navegador y servidor se aseguran de que usan el mismo método de protección, generan un secreto común y solo entonces empiezan el intercambio real de información.

La clave secreta no se envía como tal por la red. Cliente y servidor intercambian parámetros públicos y luego calculan por separado el mismo secreto compartido.

En TLS 1.3, normalmente se emplea el intercambio de claves temporal basado en Diffie-Hellman, a menudo con curvas elípticas. Así, la clave de sesión solo existe temporalmente y no depende del secreto privado del certificado del servidor.

Tras un handshake exitoso, ambas partes obtienen claves simétricas que se usarán para cifrar el flujo principal de datos, ya que el cifrado simétrico es mucho más rápido que las operaciones con claves públicas y privadas.

¿Cómo verifica el navegador el certificado del sitio?

El cifrado por sí solo no basta; el navegador debe asegurarse de que realmente se está conectando al sitio correcto y no a un servidor suplantador.

Para ello, el servidor envía un certificado digital, que incluye información sobre el dominio, la clave pública y la firma digital de una autoridad certificadora.

El navegador comprueba varios aspectos: si el dominio en el certificado coincide con el sitio visitado, si el certificado está vigente y si puede construir una cadena de confianza hasta una autoridad reconocida por el sistema operativo o el propio navegador.

Si la verificación es exitosa, el usuario ve la conexión HTTPS sin alertas. Si el certificado está caducado, emitido para otro dominio o no puede ser validado, el navegador advierte de un problema de seguridad.

El certificado sirve sobre todo para autenticar el servidor. El tráfico real no se cifra directamente usando la clave pública del certificado; tras el handshake, se emplean claves simétricas independientes.

¿Cómo negocian las partes las claves de cifrado?

En TLS 1.3, cliente y servidor crean pares de claves temporales e intercambian sus partes públicas. Con esa información, ambas partes calculan por separado un mismo secreto compartido.

Un tercero puede ver los parámetros públicos transmitidos, pero eso no es suficiente para calcular la clave secreta final. A partir del secreto común, se generan diferentes claves para cada etapa de la sesión, aumentando así la seguridad.

Este reparto garantiza que una sola clave no se use para todas las operaciones. TLS 1.3 crea secretos distintos para el handshake, el tráfico de aplicación y otros elementos de la sesión.

Al finalizar la verificación, servidor y navegador confirman que ambos han calculado las claves correctas y que los mensajes previos no han sido alterados. Solo entonces se considera establecida la conexión segura y el navegador puede enviar solicitudes HTTP dentro del canal HTTPS.

¿Cómo cifra los datos TLS 1.3?

Una vez finalizado el handshake, navegador y servidor pasan a la transmisión de datos cifrados. En esta fase, TLS 1.3 ya no usa operaciones costosas de clave pública para cada solicitud, sino algoritmos simétricos rápidos.

La combinación de criptografía asimétrica para establecer la confianza y simétrica para transferir datos es lo que permite que HTTPS sea seguro y rápido en el uso cotidiano.

Cifrado simétrico y asimétrico

La criptografía asimétrica usa un par de claves (pública y privada) y es ideal para la autenticación y el intercambio seguro de secretos, pero es más costosa computacionalmente que los algoritmos simétricos.

Por ello, TLS no cifra todo el tráfico web con la clave pública del certificado. Tras el handshake, las partes cambian a cifrado simétrico usando secretos compartidos.

TLS 1.3 emplea algoritmos modernos de cifrado autenticado como AES-GCM y ChaCha20-Poly1305, que no solo ocultan el contenido, sino que también permiten comprobar la integridad de los datos. Si un paquete cifrado es alterado, el receptor detectará la manipulación o corrupción.

Esto es fundamental en HTTPS: no basta con que un atacante no pueda leer una contraseña transmitida, tampoco debe poder modificar silenciosamente una solicitud, cambiar el contenido de la página o inyectar datos propios.

¿Por qué se usan claves de sesión temporales?

Un solo secreto permanente para todas las conexiones HTTPS sería un grave fallo de seguridad, ya que su compromiso permitiría descifrar grandes volúmenes de tráfico interceptado previamente.

TLS 1.3 genera nuevos secretos para cada conexión, ligados a la sesión concreta. Al terminar la sesión, esas claves no se reutilizan para futuras conexiones.

Gracias al intercambio temporal de claves, TLS 1.3 garantiza Forward Secrecy: incluso si un atacante obtiene después la clave privada del servidor, no podrá descifrar sesiones antiguas previamente grabadas.

Esto representa una mejora importante sobre versiones antiguas de TLS, donde el compromiso de una clave podía afectar conexiones pasadas.

¿Qué ve tu proveedor de Internet durante una conexión HTTPS?

El cifrado TLS protege el contenido, pero no oculta el hecho de que existe una conexión de red. El proveedor sigue viendo la IP del servidor, ya que necesita enrutar los paquetes.

También puede observar el momento de la conexión, su duración y el volumen aproximado de datos transmitidos. A partir de estos datos, a veces es posible inferir el tipo de tráfico, pero nunca leer la solicitud HTTP o el contenido de la página.

En una conexión HTTPS estándar, el proveedor no ve qué escribes en los formularios, qué datos devuelve el servidor o qué cookies se intercambian.

Algunos datos técnicos pueden depender de los protocolos adicionales utilizados. Por eso, TLS debe entenderse como protección del contenido, no como una herramienta de anonimato total.

¿Por qué no se puede descifrar fácilmente el tráfico HTTPS interceptado?

Supongamos que alguien graba todos los paquetes entre navegador y servidor, incluyendo datos del handshake y registros cifrados.

Eso no es suficiente para recuperar el contenido: las claves finales no se transmiten directamente, sino que cada parte las calcula de forma independiente a partir de un secreto común, que no puede derivarse de los parámetros públicos en un tiempo razonable si la criptografía está bien implementada.

Cada bloque de datos se cifra con las claves de esa sesión y se verifica su integridad. Un cambio mínimo en un paquete interceptado hará que la verificación criptográfica falle y los datos serán descartados.

Por eso, los ataques modernos contra HTTPS no buscan "romper el AES", sino explotar otros puntos débiles: robo de claves, compromiso de dispositivos, errores de certificados, vulnerabilidades del servidor o engañar al usuario para que confíe en sitios falsos.

TLS 1.3 vs TLS 1.2: principales cambios

Durante mucho tiempo, TLS 1.2 fue el estándar de protección para conexiones HTTPS, pero conservaba muchos mecanismos heredados de versiones más antiguas, complicando la configuración y permitiendo el uso de algoritmos obsoletos.

Con TLS 1.3 se cambió el enfoque: se redujo la cantidad de algoritmos admitidos y se eliminaron mecanismos que ya no cumplían con los requisitos modernos de seguridad.

Handshake más corto

Uno de los cambios más visibles es la reducción del TLS handshake. En TLS 1.2, cliente y servidor a menudo necesitaban varios intercambios antes de transmitir datos, cada uno añadiendo latencia según la distancia de red.

Con TLS 1.3, los parámetros clave y la generación de las claves se realizan más rápido. Normalmente, basta un solo intercambio adicional tras establecer la conexión de transporte para pasar a la transmisión segura de datos.

Cuanto más lejos está el servidor, más notable es la diferencia. Si una ronda de red tarda decenas o cientos de milisegundos, eliminar una ronda extra reduce directamente el tiempo de carga inicial.

Eliminación de algoritmos obsoletos

TLS 1.2 soportaba una amplia gama de mecanismos, incluidos algunos que se volvieron inseguros o difíciles de configurar correctamente. TLS 1.3 ha reducido drásticamente esta lista, eliminando métodos antiguos de intercambio de claves, modos de cifrado obsoletos y otros mecanismos históricos.

Esto disminuye el riesgo de que un servidor soporte HTTPS de forma incorrecta o con esquemas criptográficos débiles.

Ahora, la variante segura no es solo recomendable, sino parte integral del estándar.

Forward Secrecy como estándar

En TLS 1.2, la protección Forward Secrecy dependía del conjunto de cifrados y la configuración del servidor. Se podían usar tanto claves temporales modernas como esquemas antiguos.

En TLS 1.3, el intercambio temporal de claves es la norma, de modo que la clave privada de larga duración del servidor no basta, por sí sola, para descifrar sesiones anteriores.

Esto es vital para la web: un atacante podría almacenar tráfico cifrado durante años esperando conseguir la clave del servidor. Con TLS 1.3 bien implementado, ese escenario deja de ser viable.

Menos variantes, menos errores

En criptografía, demasiadas opciones aumentan el riesgo de configuraciones erróneas. TLS 1.2 permitía combinar numerosos algoritmos y modos, obligando a los administradores a estar atentos a la seguridad de cada uno.

TLS 1.3 simplifica el modelo: el conjunto de algoritmos es más compacto y las opciones peligrosas han sido eliminadas. Así, TLS 1.3 es más seguro tanto por su criptografía como por reducir la posibilidad de malas configuraciones.

¿Por qué TLS 1.3 ha hecho que HTTPS sea más rápido?

El cifrado requiere procesamiento, por eso antes HTTPS se consideraba más lento que HTTP. Hoy en día, el coste de las operaciones criptográficas es bajo, pero una parte importante de la latencia ocurre antes de transferir la página: durante el establecimiento de la conexión.

Aquí es donde TLS 1.3 brilla: reduce el número de intercambios de red necesarios antes de enviar los datos útiles.

¿Qué es 1-RTT?

RTT (Round Trip Time) es el tiempo que tarda un paquete en ir del cliente al servidor y volver. Si el RTT es de 50 ms, cada ronda adicional suma ese retraso antes de poder transmitir los datos.

El handshake estándar de TLS 1.3 se denomina 1-RTT porque tras el ClientHello y la respuesta del servidor, ambas partes ya tienen la información suficiente para finalizar la negociación de claves y empezar el intercambio seguro.

Para el usuario, esto significa que el navegador puede enviar la primera solicitud HTTP mucho antes.

¿Cómo funciona la reanudación de sesión?

Rara vez un usuario visita un sitio solo una vez; durante la carga de una página, el navegador suele abrir nuevas conexiones y regresar más tarde al mismo servidor.

TLS admite la reanudación de sesión: tras una conexión exitosa, el servidor puede dar al cliente información que le permitirá, en futuras conexiones, reutilizar parte de la sesión previa y evitar repetir todo el proceso desde cero.

En TLS 1.3, este mecanismo se integra en el nuevo modelo de intercambio de claves, reduciendo aún más la latencia en reconexiones, especialmente útil en redes móviles donde las conexiones suelen interrumpirse o cambiar de red.

¿Qué es 0-RTT?

TLS 1.3 también soporta el modo 0-RTT o Early Data, en el que el navegador puede, al reconectarse, enviar parte de los datos de aplicación ya con el primer mensaje, sin esperar a completar un nuevo handshake.

Así, la ronda adicional de red desaparece para ciertos datos.

Pero 0-RTT tiene una limitación importante: estos datos pueden ser susceptibles a ataques de repetición. Un atacante no podrá leer el contenido, pero podría intentar reenviar datos grabados previamente. Por eso, 0-RTT no es adecuado para todas las operaciones, especialmente aquellas que modifican el estado, como compras o transferencias.

¿Cuánto se nota la mejora de velocidad?

En conexiones domésticas rápidas y cercanas, la diferencia entre TLS 1.2 y TLS 1.3 puede ser de solo decenas de milisegundos y casi imperceptible para el usuario.

Pero en situaciones con alta latencia (por ejemplo, al conectar con servidores en otros continentes desde una red móvil), eliminar una ronda puede ahorrar 150 ms o más solo en el establecimiento de la conexión segura.

Además, en una sola página puede haber varias conexiones: al sitio principal, a una CDN, a APIs y otros recursos, por lo que los pequeños retrasos se suman.

Por eso, optimizar el handshake es clave para servicios web modernos utilizados globalmente.

La velocidad no depende solo de TLS

TLS 1.3 reduce la latencia de establecimiento de conexión segura, pero no puede, por sí solo, hacer que un sitio lento sea rápido.

La velocidad final depende también de la distancia al servidor, la calidad de la red, el DNS, el uso de CDN, el tamaño de la página, el procesamiento en el servidor y el protocolo de transporte empleado.

De hecho, muchos sitios modernos emplean QUIC y HTTP/3, donde la negociación de la conexión segura y la del transporte están aún más integradas. Descubre más sobre este enfoque en el artículo QUIC: el protocolo que revoluciona la velocidad y estabilidad de Internet.

En resumen, la aceleración de HTTPS en la web moderna es fruto de varios cambios combinados: TLS 1.3 acorta el handshake criptográfico y los nuevos protocolos de transporte reducen aún más las demoras entre navegador y servidor.

Conclusión

TLS 1.3 representa un avance clave para HTTPS, ya que simplifica el protocolo, refuerza la protección de la conexión y reduce la latencia. Navegador y servidor requieren menos intercambios antes de empezar a transmitir datos, y los mecanismos criptográficos obsoletos han sido descartados.

Para el usuario, todo el proceso es casi invisible: al abrir un sitio, el navegador verifica el certificado, realiza el handshake, genera claves temporales y luego transmite el tráfico HTTP dentro de un canal cifrado. Así, logins, contraseñas, cookies, contenido de páginas y otros datos no pueden ser leídos simplemente interceptando paquetes de red.

Aun así, TLS 1.3 no garantiza el anonimato ni soluciona todos los problemas de velocidad. Las direcciones IP y ciertos metadatos siguen siendo visibles, y el rendimiento depende también de DNS, la distancia al servidor, CDN, HTTP/2 o HTTP/3 y la calidad de la red.

La gran ventaja de TLS 1.3 es que el HTTPS moderno ya no debe elegir entre seguridad y velocidad: la conexión protegida se establece más rápido, con mecanismos criptográficos más rigurosos y mejor adaptados a la estructura de Internet de hoy.