El handshake de TLS 1.3 en líneas generales

Qué es

RFC 8446 define el handshake. El cliente envía un ClientHello con las extensiones supported_versions, signature_algorithms y key_share; el key share es un valor público (EC)DHE efímero para uno o más grupos. El servidor elige un grupo y responde con un ServerHello que incluye su propio key_share. Ambos lados derivan entonces las claves de handshake, y todo mensaje posterior va cifrado: EncryptedExtensions, el Certificate y el CertificateVerify del servidor (una firma sobre la transcripción) y Finished (un HMAC sobre la transcripción). El cliente responde con su propio Finished y a partir de ahí puede enviar datos de aplicación. Un único viaje de ida y vuelta, de ahí «1-RTT». Si el cliente supuso un grupo que el servidor no admite, el servidor envía HelloRetryRequest y el cliente reintenta con un key share distinto, lo que cuesta un viaje de ida y vuelta adicional.

Después del handshake, el servidor puede enviar mensajes NewSessionTicket; una conexión posterior presenta el ticket como pre_shared_key y puede omitir el intercambio de certificados. Con un PSK de este tipo, el cliente también puede enviar «datos tempranos» (early data, 0-RTT) en su primer envío. La RFC afirma sin rodeos que los datos 0-RTT no tienen forward secrecy y que no existen garantías contra la repetición (replay) entre conexiones.

Por qué importa

RFC 8446 enumera lo que se eliminó respecto a TLS 1.2: los conjuntos de cifrado RSA estático y Diffie-Hellman estático (transporte de clave RSA), la compresión, DSA, los grupos DHE personalizados y los cifrados simétricos heredados; la renegociación queda prohibida por completo. Todo intercambio de claves de clave pública ofrece ahora forward secrecy, y todo conjunto de cifrado restante es AEAD (TLS_AES_128_GCM_SHA256 es de implementación obligatoria). El certificado ya no es visible en el cable, lo que cambia lo que pueden ver los middleboxes pasivos y los registros.

Cómo aplicarlo

• Preferir TLS 1.3 siempre que ambos extremos lo admitan; la versión se negocia mediante supported_versions, no mediante el campo de versión heredado, de modo que los middleboxes antiguos que inspeccionan ese campo siguen viendo «TLS 1.2».
• Ofrecer primero el grupo de key share que prefieren los pares esperados, para evitar viajes de ida y vuelta por HelloRetryRequest; la RFC exige secp256r1 y recomienda X25519 para los clientes.
• Dejar 0-RTT desactivado salvo que la capa de aplicación solo envíe solicitudes idempotentes de forma temprana; la sección de la RFC sobre prevención de repetición describe tickets de un solo uso y comprobaciones de frescura que un servidor necesitaría.
• Preferir la reanudación con un key share nuevo (psk_dhe_ke): la RFC indica que un PSK usado solo pierde forward secrecy para los datos de aplicación, de modo que una clave de ticket filtrada expondría esas sesiones. Rotar las claves de ticket de todos modos.

Trampas

El «modo de compatibilidad con middleboxes» hace que TLS 1.3 parezca, en el cable, una reanudación de sesión de la versión 1.2; por eso, para descifrar capturas de paquetes se necesitan los secretos de la sesión, no solo el certificado. Los certificados de cliente siguen funcionando, pero se solicitan dentro de la parte cifrada del handshake, de modo que los proxies que terminan TLS deben gestionarlos ellos mismos.