Cuando abres una página web, hay un momento invisible en el que tu navegador y el servidor se dan la mano y se ponen de acuerdo en cómo hablar sin que nadie más pueda escuchar. Ese momento es el handshake TLS, el apretón de manos criptográfico que sostiene el candado verde de tu barra de direcciones. Hoy vamos a abrir la puerta y ver qué hay dentro.
Dos mundos criptográficos que se complementan
Toda la criptografía que protege internet se apoya en dos familias de algoritmos. La criptografía simétrica usa una única clave secreta para cifrar y descifrar: es rapidísima, pero requiere que emisor y receptor compartan esa clave sin que nadie la intercepte. La criptografía asimétrica (o de clave pública) usa un par de claves matemáticamente relacionadas: una pública, que cualquiera puede ver, y una privada, que solo conoce el dueño. Es lenta, pero resuelve el problema de compartir secretos a través de un canal inseguro.
TLS no elige entre una y otra: las combina. La parte asimétrica sirve para intercambiar de forma segura una clave de sesión, y con esa clave simétrica se cifra el tráfico real de la página. Así se consigue la velocidad del cifrado simétrico con la seguridad del asimétrico.
El apretón de manos, paso a paso
En TLS 1.3, el protocolo más reciente y el que usa la mayoría del tráfico web actual, el handshake se reduce a dos viajes de ida y vuelta (en TLS 1.2 eran cuatro). El navegador envía un mensaje ClientHello con los algoritmos que soporta. El servidor responde con su ServerHello, elige el algoritmo común y envía su certificado digital.
El certificado es la pieza clave de la confianza: contiene la clave pública del sitio y la firma de una autoridad de certificación (CA), una entidad acreditada como Let’s Encrypt o DigiCert. El navegador verifica esa firma usando la clave pública de la CA, que ya viene instalada en tu sistema operativo. Si la firma es válida y el certificado está dentro de su fecha de vigencia, el navegador sabe que está hablando con el sitio correcto.
Secreto de reenvío: aunque te espíen, no leerán lo viejo
Para derivar la clave de sesión, TLS 1.3 usa ECDHE (Diffie-Hellman sobre curvas elípticas), un intercambio de claves que genera un secreto compartido sin que viaje nunca por la red. Su propiedad más valiosa es el forward secrecy o secreto de reenvío: cada sesión usa claves efímeras que se destruyen al terminar. Aunque un atacante grabara todo tu tráfico hoy y robara la clave privada del servidor mañana, no podría descifrar lo que grabó. Es la razón por la que los protocolos antiguos sin esta propiedad (como la primera versión de TLS) se consideran obsoletos.
El cifrado real del tráfico
Con la clave de sesión ya establecida, comienza la fase de datos. TLS parte el flujo en bloques llamados registros TLS y los cifra con un cifrador simétrico autenticado, normalmente AES-256-GCM o ChaCha20-Poly1305. La parte GCM y Poly1305 es clave: no solo ocultan el contenido, también lo autentican, garantizando que nadie haya alterado ni reordenado los paquetes por el camino. Si un byte se manipula, el receptor lo detecta y descarta la conexión.
Además, cada registro lleva su número de secuencia, lo que impide ataques de repetición en los que un atacante reintroduce un mensaje capturado antes para confundir al receptor. Cifrado, autenticación e integridad trabajan juntos en una sola capa.
¿Y qué pasa con el sitio en sí?
Es importante separar dos cosas: TLS cifra el canal entre tu navegador y el servidor, pero no protege los datos una vez que llegan al servidor, ni garantiza que el servidor sea honesto. El candado significa «nadie escucha el camino», no «este sitio es fiable». Por eso el cifrado va siempre acompañado de otras capas: la verificación de identidad del certificado, la política de la página y el propio código del sitio.
La próxima vez que veas el candado, sabrás que detrás hay curvas elípticas, claves efímeras y cifrado autenticado trabajando en milisegundos para que tu conversación con la web sea tuya y de nadie más.
