Cómo funciona TLS: la guía completa del handshake 2026

En pocas palabras: TLS 1.3 (RFC 8446, IETF, 2018) protege tu conexión con un handshake de 1-RTT que combina intercambio de claves efímero por curvas elípticas (ECDH) para forward secrecy, firmas digitales para autenticar al servidor y derivación de claves con HKDF/HMAC, cifrando los datos con una de solo tres cipher suites AEAD: AES-128-GCM, AES-256-GCM o ChaCha20-Poly1305.

TLS, sigla de Transport Layer Security, es el protocolo criptográfico que cifra el tráfico entre tu navegador y un servidor cada vez que aparece el candado en la barra de direcciones. No es un algoritmo único: orquesta generación de números aleatorios, intercambio de claves con curvas elípticas (ECDH), funciones hash, códigos de autenticación de mensajes (HMAC) y cifrado simétrico AEAD en un solo handshake. La versión vigente, TLS 1.3, la define el IETF en RFC 8446.

¿Qué pasa cuando tu navegador muestra el candado y qué cripto hay detrás?

El candado es apenas la señal visible: detrás ya se ejecutó un handshake que combinó cifrado simétrico, intercambio de claves asimétrico, firmas digitales, funciones hash y autenticación de mensajes en milisegundos.

Ponele que entrás a tu banco online. Vos no ves nada raro, la página carga y listo. Pero en el fondo tu navegador y el servidor del banco acaban de negociar qué algoritmo de cifrado usar, generar un secreto compartido sin transmitirlo nunca, verificar que el certificado del servidor es legítimo y derivar claves de sesión que van a cifrar cada byte que intercambien de ahí en más.

Eso es TLS. No es una caja negra mágica: es la combinación ordenada de varias primitivas criptográficas que, por separado, ya conocés si alguna vez tocaste AES, RSA, ECC, SHA o HMAC. TLS es donde todas esas piezas se juntan en una coreografía.

¿Cuál es la diferencia entre SSL y TLS?

SSL es el antecesor directo de TLS: Netscape lanzó SSL 1.0 en 1994 (nunca salió al público) y SSL 2.0 en 1995, con fallas serias que obligaron a un rediseño completo en SSL 3.0 (1996). TLS es, en esencia, la continuación de ese trabajo bajo otro nombre y bajo el control del IETF. En un caso real de mTLS sobre QUIC profundizamos sobre esto.

• SSL 1.0 (1994): primer intento de Netscape, nunca se liberó públicamente.
• SSL 2.0 (1995): primera versión pública, con fallas graves descubiertas rápido.
• SSL 3.0 (1996): rediseño completo que terminó siendo la base de todas las versiones de TLS.
• TLS 1.0 (1999): el IETF toma el protocolo; es, básicamente, SSL 3.1.
• TLS 1.1 (2006): suma protección contra ataques a CBC.
• TLS 1.2 (2008): cipher suites con SHA-2, modos AEAD y PRF configurables.
• TLS 1.3 (2018): handshake de 1-RTT, forward secrecy obligatorio y eliminación de algoritmos legacy.

Hoy “SSL” quedó como forma coloquial de referirse a TLS (el típico “certificado SSL” que vendés en un hosting, en realidad es un certificado TLS). Según RFC 8996, el IETF deprecó oficialmente TLS 1.0 y 1.1 en marzo de 2021, moviéndolos a estado histórico. TLS 1.2 sigue siendo seguro si está bien configurado, pero TLS 1.3 es el estándar de facto desde 2018-2020, soportado por todos los navegadores y servidores modernos.

¿Cómo funciona el handshake de TLS 1.3 paso a paso?

El handshake de TLS 1.3 funciona en seis fases: Client Hello, Server Hello, derivación de claves, handshake cifrado, autenticación opcional del cliente y datos de aplicación cifrados, todo en una sola ida y vuelta (1-RTT) entre cliente y servidor.

Así entendés cómo funciona TLS en la práctica, fase por fase:

• Client Hello (la oferta inicial): el navegador manda la versión del protocolo, 32 bytes aleatorios (ClientRandom), la lista de cipher suites (en TLS 1.3 solo hay tres), los grupos de curvas elípticas soportados (X25519, P-256, entre otros), su clave pública efímera (key share) y el SNI con el hostname al que quiere conectarse.
• Server Hello (la respuesta): el servidor elige una cipher suite de la lista, agrega su propio ServerRandom y manda su propia clave pública efímera en la misma curva que eligió el cliente.
• Derivación de claves (la parte matemática): ambos lados calculan el mismo secreto compartido con ECDH, sin transmitirlo nunca, y después usan HKDF (definido en RFC 5869) sobre HMAC-SHA256 o HMAC-SHA384 para derivar las claves de handshake y, más tarde, las claves de aplicación.
• Handshake cifrado (autenticación del servidor): a partir de acá todo va cifrado, a diferencia de TLS 1.2 donde el certificado viajaba en claro. El servidor manda su certificado X.509, una firma digital (CertificateVerify) que prueba que tiene la clave privada correspondiente, y un Finished con el MAC de toda la transcripción.
• Autenticación del cliente (opcional, mTLS): en la mayoría de la navegación web solo se autentica el servidor, pero en comunicación API a API o arquitecturas zero-trust el cliente también manda certificado.
• Datos de aplicación: con el handshake terminado, ambos lados cifran todo con AES-128-GCM, AES-256-GCM o ChaCha20-Poly1305, con un nonce distinto por cada registro.

Subís una app a producción, probás el endpoint, todo responde rápido, y ese handshake completo (con ECDH, HKDF, firma digital y verificación de certificado incluidos) pasó en el tiempo que tardás en parpadear. Esa es la gracia de TLS 1.3: toda esa complejidad, resuelta en un solo viaje de ida y vuelta.

¿Qué cifrados usa TLS 1.3?

TLS 1.3 define exactamente tres cipher suites, todas AEAD (cifrado autenticado con datos asociados), eliminando las más de 37 combinaciones que permitía TLS 1.2.

• TLS_AES_128_GCM_SHA256: AES-128 en modo GCM, clave de 128 bits, hash SHA-256, nivel de seguridad de 128 bits. Rinde bien en casi cualquier CPU moderna con aceleración AES-NI.
• TLS_AES_256_GCM_SHA384: AES-256 en modo GCM, clave de 256 bits, hash SHA-384. Pensado para aplicaciones de alta seguridad, aunque sin aceleración por hardware es algo más lento que su hermano de 128 bits.
• TLS_CHACHA20_POLY1305_SHA256: cifrado de flujo ChaCha20 con MAC Poly1305, clave de 256 bits. Es la opción natural para celulares y servidores ARM sin aceleración AES por hardware.

¿Por qué solo tres opciones y no las decenas que tenía TLS 1.2? Porque cada cipher suite que se saca reduce superficie de ataque y posibilidad de mala configuración. RC4, 3DES y los modos CBC quedaron afuera porque, con el tiempo, mostraron fallas (el padding oracle de CBC es el ejemplo clásico).

¿Qué diferencia hay entre TLS 1.2 y TLS 1.3?

La diferencia más grande es que TLS 1.3 necesita un solo viaje de ida y vuelta (1-RTT) para cerrar el handshake, contra los dos que pedía TLS 1.2, y además cifra todo el intercambio después del Server Hello, algo que TLS 1.2 no hacía. Tema relacionado: cómo rotar certificados TLS sin cortes.

Característica	TLS 1.2 (2008)	TLS 1.3 (2018)
Viajes de ida y vuelta	2-RTT (completo)	1-RTT (completo), 0-RTT (reanudación)
Cipher suites	37+ (incluye RC4, 3DES, CBC)	3 (todas AEAD)
Intercambio de claves	RSA, DH, ECDH, DHE, ECDHE	Solo ECDHE (forward secrecy obligatorio)
Cifrado del handshake	Certificado del servidor en claro	Todo cifrado tras el Server Hello
RSA como transporte de clave	Soportado	Eliminado (rompe forward secrecy)
Cifrados CBC	Soportados	Eliminados (vulnerables a padding oracle)
Compresión	Soportada (vulnerable a CRIME)	Eliminada
Renegociación	Soportada	Eliminada

El tema es que TLS 1.2 no está muerto: sigue siendo ampliamente usado y se considera seguro si lo configurás bien (cipher suites AEAD, sin CBC, sin compresión). Lo que de verdad hay que sacar de producción son TLS 1.0 y 1.1, deprecados desde 2021.

¿Qué es el forward secrecy y por qué TLS 1.3 lo hace obligatorio?

Forward secrecy significa que si alguien roba la clave privada de largo plazo de tu servidor, no puede descifrar sesiones TLS pasadas, porque esas sesiones usaron claves efímeras que ya se descartaron.

En TLS 1.2 con intercambio RSA estático, el servidor usaba su clave privada RSA para descifrar el pre-master secret que mandaba el cliente. ¿Qué pasaba si alguien grababa el tráfico cifrado y después, meses más tarde, conseguía esa clave privada? Exacto: podía descifrar todo el historial grabado.

En TLS 1.3 esto no puede pasar, porque todo el intercambio de claves usa ECDH efímero: el servidor genera un par de claves nuevo para cada conexión y lo tira después de usarlo. Aunque la clave de firma de largo plazo del servidor se filtre, las sesiones anteriores quedan protegidas.

Escenario	RSA estático (TLS 1.2)	ECDH efímero (TLS 1.3)
Clave privada del servidor filtrada	Todas las sesiones pasadas quedan descifrables	Las sesiones pasadas siguen protegidas
Tráfico grabado + compromiso posterior	Tráfico expuesto	Tráfico seguro
Independencia de clave por sesión	No	Sí

Por esto exactamente TLS 1.3 sacó el RSA estático y el DH estático del protocolo: no hay forma de que den forward secrecy, así que ni se discute si quedan o no. Complementá con una alternativa P2P con TLS en el edge.

¿Qué es la reanudación 0-RTT y cuándo es riesgosa?

La reanudación 0-RTT permite mandar datos de aplicación en el primerísimo mensaje del handshake, usando una clave precompartida (PSK) de una conexión previa, pero esos datos no tienen forward secrecy y quedan expuestos a ataques de replay.

Si el cliente ya se conectó antes a ese servidor, puede reusar un PSK de la sesión anterior y arrancar a mandar datos sin esperar la vuelta completa del handshake. Suena genial para latencia. El problema: un atacante que capture ese primer mensaje puede retransmitirlo, y el servidor lo va a procesar de nuevo como si fuera legítimo.

Por eso 0-RTT solo es seguro para requests idempotentes, tipo GET o HEAD. Nunca para operaciones que cambian estado, como pagos o cambios de contraseña. Si tu API acepta 0-RTT para un endpoint de “confirmar pago”, tenés un problema serio de diseño, no de criptografía.

Errores comunes al configurar TLS

• Dejar TLS 1.0 o 1.1 habilitado “por compatibilidad”: ambas versiones están deprecadas desde marzo de 2021 por RFC 8996. Si tu servidor todavía las acepta, estás ampliando la superficie de ataque sin ganar nada real a cambio.
• Confundir forward secrecy con “estoy usando HTTPS, ya zafé”: tener el candado no garantiza nada si tu configuración sigue aceptando cipher suites con RSA estático. Revisá qué suites negocia tu servidor, no asumas.
• Usar 0-RTT en endpoints que cambian estado: habilitar early data para todo “porque mejora la latencia” abre la puerta a ataques de replay en operaciones que no deberían repetirse nunca.
• No renovar el certificado a tiempo: si administrás tu propio servidor o VPS, un certificado vencido tira el candado abajo y asusta a cualquier visitante. En proveedores como donweb.com los certificados SSL incluyen instalación gratuita, así te ahorrás ese dolor de cabeza puntual.

Preguntas Frecuentes

¿Qué es TLS y para qué sirve?

TLS es el protocolo criptográfico que cifra la comunicación entre un cliente (navegador, app, API) y un servidor en internet. Sirve para garantizar confidencialidad (nadie en el medio ve los datos), integridad (nadie los modifica sin que se detecte) y autenticación del servidor, según define RFC 8446.

¿Cómo funciona el handshake de TLS paso a paso?

El handshake de TLS 1.3 pasa por Client Hello, Server Hello, derivación de claves con ECDH y HKDF, autenticación del servidor con certificado y firma digital, y por último el inicio del cifrado de datos de aplicación con AES-GCM o ChaCha20-Poly1305. Todo en un solo viaje de ida y vuelta.

¿Qué diferencia hay entre TLS 1.2 y TLS 1.3?

TLS 1.3 reduce el handshake a 1-RTT (contra 2-RTT de TLS 1.2), deja solo 3 cipher suites AEAD (contra 37+), hace obligatorio el forward secrecy con ECDHE y cifra todo el handshake después del Server Hello, cosa que TLS 1.2 no hacía.

¿Qué es el forward secrecy en TLS?

Forward secrecy significa que comprometer la clave privada de largo plazo de un servidor no permite descifrar sesiones TLS pasadas, porque esas sesiones usaron claves ECDH efímeras generadas y descartadas por conexión. TLS 1.3 lo hace obligatorio al eliminar el RSA estático.

¿Qué cifrados usa TLS 1.3?

TLS 1.3 usa exactamente tres cipher suites AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 y TLS_CHACHA20_POLY1305_SHA256. Las tres combinan cifrado simétrico con autenticación integrada, sin necesidad de un MAC separado.

Conclusión

TLS 1.3 cambió el equilibrio entre velocidad y seguridad: menos cipher suites, handshake más corto, forward secrecy sin excepciones. Si administrás servidores propios, lo mínimo es confirmar que TLS 1.0 y 1.1 estén apagados (deprecados desde 2021 por RFC 8996) y que TLS 1.2, si todavía convive con 1.3, use solo suites AEAD. No hace falta memorizar la matemática de HKDF para operar bien: alcanza con entender qué fase del handshake depende de qué primitiva, y desconfiar de cualquier configuración que todavía permita RSA estático o CBC.

Fuentes

• RFC 8446 – The Transport Layer Security (TLS) Protocol Version 1.3, IETF
• RFC 8996 – Deprecating TLS 1.0 and TLS 1.1, IETF
• RFC 5869 – HMAC-based Extract-and-Expand Key Derivation Function (HKDF), IETF
• How TLS Protects Your Internet Connection: The Complete Guide, Dev.to