Entrevista de redes: ¿Cómo funciona el handshake de TLS 1.3 y cuándo es seguro 0-RTT?

Pregunta y alcance

Una API global utiliza TLS 1.3. Explica paso a paso un handshake completo y un handshake reanudado. Explica qué se cifra en cada etapa, cómo el certificado autentica al servidor, cómo se generan las claves y si GET /rates y POST /transfers deberían usar 0-RTT.

Utiliza una línea base explícita: el cliente se conecta a un servicio HTTPS sobre TCP; el servidor se autentica con un certificado X.509; un handshake completo utiliza ECDHE efímero; una conexión reanudada utiliza un session ticket emitido en una conexión anterior; y el punto de entrada de la API puede ser un balanceador de carga o una CDN. HTTP/3 integra TLS 1.3 en el establecimiento de conexión de QUIC, pero la línea base utiliza registros TLS sobre TCP para concretar el orden de los mensajes y las propiedades de seguridad.

Esta pregunta es adecuada para entrevistas de backend, cliente, infraestructura, SRE, seguridad e ingeniería de software en general. El entrevistador no solo busca una recitación de ClientHello a Finished. El candidato debe explicar cómo la identidad queda vinculada a este handshake, qué claves protegen qué etapas y por qué eliminar un viaje de ida y vuelta (round trip) de la red crea un problema de retransmisión (replay) que la aplicación debe manejar.

Lo que el entrevistador está evaluando

Primero, ¿puede el candidato separar el intercambio de claves, la autenticación y el cifrado masivo? La clave pública en el certificado normalmente verifica la firma de CertificateVerify sobre la transcripción del handshake. No cifra todo el tráfico comercial subsiguiente. Las claves simétricas de tráfico provienen de ECDHE, una PSK y el key schedule basado en HKDF.

Segundo, ¿puede el candidato ubicar con precisión el límite de cifrado? El ClientHello y el ServerHello iniciales exponen la información necesaria para la negociación. Después de procesar ServerHello, ambos pares pueden derivar claves de tráfico del handshake. Esas claves protegen EncryptedExtensions, Certificate, CertificateVerify y Finished. Luego, claves de tráfico de aplicación independientes protegen los datos de la aplicación.

Tercero, ¿puede el candidato distinguir la reanudación de 0-RTT? La reanudación de sesión puede acortar la autenticación mientras sigue completando un handshake de 1-RTT. Con 0-RTT, el cliente envía datos tempranos (early data) en su primer envío (flight). Ambos pueden involucrar una PSK, pero solo los early data carecen de la frescura derivada del ServerHello actual.

Cuarto, ¿puede el candidato traducir el riesgo del protocolo a la semántica del negocio? TLS 1.3 otorga a los early data propiedades más débiles: no tienen confidencialidad directa perfecta (forward secrecy) ni garantía de no retransmisión entre conexiones. Su habilitación no puede decidirse únicamente a partir del método HTTP. Cobrar dinero, crear una sesión, incrementar un contador, emitir una recompensa o consumir un token de un solo uso cambia la respuesta.

Quinto, ¿puede el candidato proponer un plan observable de despliegue y depuración? Una respuesta sólida distingue un handshake completo, una reanudación de 1-RTT y 0-RTT; verifica tickets, ALPN, HelloRetryRequest, la aceptación o rechazo de early data y el 425 Too Early de HTTP; y verifica el canal de seguridad independiente desde un terminador TLS en el borde (edge) hasta el origen.

Preguntas para aclarar primero

• ¿Qué transporte se está utilizando? HTTPS sobre TCP y QUIC/HTTP/3 utilizan la criptografía de TLS 1.3, pero transportan mensajes y establecen conexiones de manera diferente. La línea base utiliza TCP.
• ¿Es una conexión inicial o reanudada? Una primera conexión no tiene una PSK utilizable y requiere autenticación por certificado. Una conexión reanudada puede ofrecer un ticket anterior, pero no necesariamente envía 0-RTT.
• ¿El servidor solicita un certificado de cliente? La mayoría de las API web autentican únicamente al servidor. mTLS agrega el Certificate y el CertificateVerify del cliente.
• ¿Dónde termina TLS? Si termina en una CDN o balanceador de carga, el cliente autentica ese endpoint perimetral. El tráfico de borde a origen es una conexión separada con sus propias decisiones de cifrado e identidad.
• ¿Cuáles son las semánticas de retransmisión de la operación? ¿Es GET /rates verdaderamente de solo lectura? ¿Consume un token de un solo uso, incrementa un contador facturable o desencadena trabajo costoso? Una clave de idempotencia en POST /transfers no elimina automáticamente todos los riesgos de early data.
• ¿Ambos extremos implementan HTTP early data correctamente? El cliente debe reintentar de forma segura en la conexión establecida si la capa TLS rechaza los early data o el servidor devuelve 425.

Estructura de respuesta de 30 segundos

“En un handshake completo de TLS 1.3, el cliente envía un ClientHello con versiones, suites de cifrado y una cuota de clave (key share) ECDHE. El servidor selecciona parámetros en ServerHello y devuelve su cuota. Ambos pares introducen el resultado de ECDHE y la transcripción en HKDF para derivar las claves del handshake, por lo que las extensiones, el certificado, la firma y el Finished posteriores a ServerHello están cifrados. El cliente valida la cadena, el hostname, el CertificateVerify y el Finished, y luego envía su propio Finished. Claves de tráfico de aplicación separadas protegen los datos posteriores.

La reanudación utiliza una PSK asociada con un ticket anterior y puede evitar la autenticación completa por certificado. Si 0-RTT también está habilitado, el cliente envía early data con ClientHello. Esos datos dependen únicamente de la PSK, no tienen confidencialidad directa perfecta y pueden retransmitirse entre conexiones. Yo solo permitiría lecturas explícitamente seguras para reintentos y sin efectos secundarios. Una transferencia debe esperar a que finalice el handshake, con una política de gateway consistente, 425 Too Early y soporte de reintento normal.”

Análisis detallado paso a paso

Paso 1: ClientHello suministra material de negociación

El cliente comienza con ClientHello. Comúnmente contiene un nonce, versiones de TLS compatibles, suites de cifrado de TLS 1.3, algoritmos de firma, grupos de intercambio de claves compatibles, uno o más valores de key_share y extensiones como SNI y ALPN. Una suite de cifrado de TLS 1.3 selecciona principalmente un algoritmo AEAD y el hash utilizado por HKDF. Otras extensiones negocian los algoritmos de firma de certificados y los grupos de intercambio de claves.

Este mensaje aún no está protegido por claves de tráfico de handshake en TLS 1.3 ordinario. SNI también es normalmente visible a menos que los pares utilicen ECH con éxito. Decir que TLS cifra cada campo desde el primer byte ignora que los pares aún no han derivado claves de tráfico compartidas para esta conexión.

La cuota de clave del cliente es un valor público de ECDHE efímero. Su valor privado correspondiente permanece local. El valor público no es en sí mismo el secreto compartido. Cada par combina su valor privado con el valor público del otro par para calcular el mismo secreto ECDHE.

Paso 2: ServerHello selecciona parámetros y completa el intercambio de clave fresca

El servidor selecciona la versión de TLS, la suite de cifrado y la cuota de clave aceptable, y luego envía ServerHello. Con ECDHE, también suministra su valor público efímero. ClientHello más ServerHello determina los parámetros criptográficos, y ambos pares ahora pueden alimentar el secreto ECDHE en el key schedule HKDF de TLS 1.3.

Si el cliente no ofreció una cuota en un grupo que el servidor acepte, el servidor puede enviar HelloRetryRequest y requerir otro ClientHello con un grupo seleccionado. Eso cuesta otro viaje de ida y vuelta, y un intento original de early data no puede simplemente continuar como la ruta exitosa normal. Un RTT adicional intermitente en producción debería motivar una verificación de HRR en lugar de asumir automáticamente fluctuación de red (jitter).

Después de ServerHello, ambos pares pueden derivar los secretos de tráfico de handshake del cliente y del servidor. El protocolo protege los mensajes de handshake posteriores con esas claves. Un observador pasivo no puede leer el certificado ni la mayoría de las extensiones posteriores, aunque los tamaños de registro, los tiempos y la información inicial no oculta por ECH siguen siendo observables.

Paso 3: Los parámetros del servidor, el certificado y la firma de la transcripción establecen la identidad

El servidor envía a continuación el mensaje cifrado EncryptedExtensions, que contiene selecciones para extensiones como ALPN. Envía CertificateRequest si desea autenticación de cliente. Un handshake HTTPS unidireccional típico luego envía los mensajes del servidor Certificate, CertificateVerify y Finished.

Esos mensajes tienen tareas distintas:

El cliente valida la cadena, el intervalo de validez, el hostname y los algoritmos de firma permitidos de acuerdo con su política de PKI, y luego verifica la firma de CertificateVerify sobre la transcripción. Esto vincula el control de la clave privada del certificado a este ClientHello, ServerHello y conjunto de parámetros negociados. Un atacante no puede trasplantar una firma de un handshake no relacionado.

Paso 4: Finished completa el handshake y separa las claves de aplicación

El Finished del servidor es un valor de verificación derivado de la transcripción y de un secreto del handshake. Una comprobación exitosa le indica al cliente que la negociación observada no fue modificada y que el par posee el material de claves del handshake correspondiente. Aceptar datos sin autenticación de certificado o verificación de Finished descartaría las garantías de identidad e integridad de TLS.

Luego, el cliente envía su propio Finished. Si el servidor solicitó mTLS, el cliente envía primero su certificado y CertificateVerify. Los pares protegen los datos de aplicación con secretos de tráfico de aplicación en lugar de seguir reutilizando las claves del handshake. TLS 1.3 puede usar posteriormente KeyUpdate para cambiar a nuevas claves de tráfico de aplicación.

La confidencialidad directa perfecta proviene de (EC)DHE efímero. Si los pares borran los valores privados efímeros y los secretos de tráfico obsoletos, una filtración futura de la clave privada a largo plazo del certificado del servidor no debería descifrar el tráfico de aplicación capturado de esos handshakes completos finalizados. La clave del certificado autentica; no es la única fuente de confidencialidad directa perfecta.

Paso 5: Los session tickets convierten conexiones posteriores en reanudación por PSK

Después de un handshake completo, el servidor puede enviar NewSessionTicket. El cliente almacena el ticket y el secreto de reanudación asociado. En una conexión posterior, ofrece la identidad del ticket en pre_shared_key y utiliza un binder para demostrar la posesión de la PSK correspondiente. Si el servidor la acepta, la PSK autentica la conexión reanudada, eliminando normalmente la necesidad de enviar la cadena de certificados y CertificateVerify nuevamente.

La reanudación no requiere renunciar a un ECDHE fresco. TLS 1.3 admite PSK pura y PSK combinada con ECDHE. Los diseños en producción comúnmente se preocupan por PSK+DHE porque preserva los beneficios de autenticación y cómputo de la reanudación al tiempo que incorpora material Diffie-Hellman fresco en el tráfico de aplicación 1-RTT ordinario. La PSK pura tiene propiedades diferentes, por lo que la respuesta debe nombrar el modo seleccionado.

Un ticket no es una credencial de inicio de sesión permanente. Tiene un tiempo de vida, parámetros criptográficos vinculados, rotación de claves del servidor y una política para compartir entre clústeres. Si un servicio multirregión no puede descifrar o validar consistentemente un ticket, recurrir a un handshake completo o rechazar la reanudación es una rama de compatibilidad válida. Buscar una tasa de reanudación más alta no justifica un tiempo de vida ilimitado para la clave del ticket.

Paso 6: 0-RTT coloca early data en el primer flight

Si un ticket permite early data, el cliente puede enviar ClientHello y datos de aplicación en el primer flight de la conexión reanudada. Los early data se cifran con un secreto de tráfico temprano del cliente derivado de la PSK. Al momento del envío, el cliente no ha recibido el ServerHello de esta conexión.

Eso reduce la latencia pero genera dos debilidades críticas:

1. Los early data se derivan de la PSK sin el intercambio ECDHE de esta conexión, por lo que no tienen confidencialidad directa perfecta.
2. No dependen del nonce ni del ServerHello de este servidor, por lo que el protocolo no puede garantizar que el mismo texto cifrado no sea retransmitido en otra conexión.

El servidor puede aceptar o rechazar el lote de early data de TLS. Si lo rechaza, el cliente debe retransmitir las solicitudes que aún necesiten ejecución después de que se complete el handshake normal. Las aplicaciones ya enfrentan incertidumbre cuando un servidor puede haber procesado una solicitud pero el cliente no recibió el resultado. 0-RTT además permite que un atacante cree duplicados deliberados entre conexiones.

Paso 7: Decidir la elegibilidad a partir de los efectos secundarios del negocio

Sin información adicional, la RFC 8470 permite a los clientes usar métodos HTTP seguros en early data y prohíbe métodos inseguros o desconocidos. El método es solo un primer filtro. El comportamiento del recurso determina el riesgo real.

Una clave de idempotencia no justifica por sí sola habilitar 0-RTT para transferencias. El registro de idempotencia debe ser consistente en cada nodo de procesamiento, confirmarse atómicamente en el límite de transacción correcto y cubrir los efectos secundarios de auditoría, notificación, límites y fraude. Retransmitir una solicitud interceptada también puede bloquear o consumir la clave. La política más segura sigue siendo esperar a que se complete el handshake para escrituras de alto riesgo.

Paso 8: Hacer consistentes las políticas de gateway, origen y cliente

HTTP define Early-Data: 1 y 425 Too Early. Cuando un gateway reenvía una solicitud que pudo haber llegado en early data en un salto anterior, preserva la señal de riesgo. Un origen que no puede procesar la solicitud de forma segura devuelve 425. El cliente reintenta en la conexión después de que se completa el handshake, y ese reintento no debe volver a utilizar early data.

Cada instancia perimetral debe manejar la misma clase de solicitud de manera consistente. Si una instancia se ejecuta de inmediato mientras otra espera a que finalice el handshake o la rechaza, un atacante puede aprovechar las diferencias entre instancias para duplicar efectos. Los controles incluyen:

• Deshabilitar 0-RTT de forma predeterminada y permitir únicamente recursos de solo lectura registrados explícitamente.
• Limitar el tiempo de vida del ticket, el tamaño de los early data y la ventana de aceptación.
• Utilizar un estado antirrepetición compartido o particionado consistentemente, reconociendo al mismo tiempo que reduce el riesgo pero no reemplaza la semántica de la aplicación.
• Rechazar los early data en su conjunto bajo carga pesada para que la retransmisión no amplifique el trabajo costoso.
• Garantizar que la CDN, el proxy inverso y el origen entiendan Early-Data y 425.

Respuesta de ejemplo sólida

“Utilizaré como línea base un handshake ECDHE completo sobre TCP con autenticación por certificado del servidor.

El cliente envía ClientHello con versiones compatibles, suites de cifrado de TLS 1.3, algoritmos de firma, grupos de intercambio de claves y una cuota de clave efímera, además de posibles extensiones SNI y ALPN. El servidor selecciona parámetros en ServerHello y devuelve su cuota de clave. Ambos pares introducen el resultado de ECDHE y la transcripción en HKDF para derivar las claves de tráfico del handshake. Después de la fase de intercambio de claves, EncryptedExtensions, el certificado del servidor, CertificateVerify y Finished se cifran.

El certificado suministra una cadena de confianza para la identidad del servidor. CertificateVerify firma esta transcripción del handshake con la clave privada del certificado, vinculando la identidad a esta negociación. Finished autentica la integridad de la transcripción y confirma la posesión de las claves del handshake. Después de que el cliente valida la cadena, el hostname, la firma y Finished, envía su propio Finished, y los pares cambian a claves de tráfico de aplicación independientes. La clave pública del certificado verifica la identidad; no cifra todos los datos de negocio. La confidencialidad directa perfecta proviene principalmente de ECDHE efímero y del borrado de secretos.

Una conexión posterior puede reanudarse con la PSK asociada con NewSessionTicket. Puede usar un handshake normal PSK+DHE de 1-RTT u opcionalmente usar 0-RTT. Con 0-RTT, el cliente envía early data junto con ClientHello, pero esos bytes están protegidos únicamente por claves derivadas de PSK, no tienen confidencialidad directa perfecta y pueden retransmitirse entre conexiones.

Por lo tanto, nunca enviaría POST /transfers en 0-RTT. Incluso con una clave de idempotencia, se debe comprobar que los efectos de transferencia, auditoría, límites y notificación sean todos seguros frente a duplicados. GET /rates entra en una lista de permitidos únicamente si es una lectura pura, reintentable de forma segura y no tiene un token de un solo uso ni efectos secundarios inaceptables. El gateway y el origen propagan Early-Data: 1, devuelven 425 Too Early cuando no es seguro, y el cliente reintenta tras completarse el handshake. Durante el despliegue, mido por separado los handshakes completos, las reanudaciones de 1-RTT y 0-RTT, y luego verifico la aceptación de tickets, HRR, la ruta de rechazo y la política entre nodos.”

Errores comunes

• Decir que la clave pública del certificado cifra todo el tráfico posterior → El tráfico de negocio en TLS 1.3 utiliza claves de tráfico simétricas → separa la verificación de la firma del certificado de ECDHE/PSK y HKDF.
• Decir que todo se cifra a partir de ClientHello en adelante → la negociación inicial precede a la derivación de claves del handshake → ubica el límite después de ServerHello para los mensajes de handshake posteriores.
• Validar únicamente la cadena y omitir la transcripción → la identidad debe estar vinculada a esta negociación → explica los roles independientes de CertificateVerify y Finished.
• Equiparar la reanudación con 0-RTT → una conexión reanudada puede esperar un handshake de 1-RTT → describe primero la reanudación por PSK y early data como opcional.
• Tratar 0-RTT como una reducción de RTT gratuita → early data no tiene confidencialidad directa perfecta y puede retransmitirse → asocia el riesgo con los efectos en la aplicación.
• Permitir automáticamente cada GET → un GET puede consumir un token, facturar uso o desencadenar trabajo costoso → crea listas de permitidos según la semántica real del recurso.
• Asumir que una clave de idempotencia resuelve la retransmisión de transferencias → la consistencia del clúster y los efectos secundarios circundantes aún pueden duplicarse → espera a que se complete el handshake para escrituras de alto riesgo.
• Configurar solo la CDN e ignorar el origen → la terminación TLS y el reenvío HTTP cruzan dos límites de seguridad → alinea el comportamiento del borde, gateway, origen, cliente y 425.

Preguntas de seguimiento

Pregunta de seguimiento 1: ¿Por qué TLS 1.3 es más rápido que TLS 1.2?

Un handshake completo típico de TLS 1.3 puede negociar parámetros y autenticar al servidor en un solo viaje de ida y vuelta de red (1-RTT), al tiempo que elimina algoritmos obsoletos y varios mensajes innecesarios de diseños anteriores. Su key schedule más unificado y su mecanismo de reanudación también ayudan. La latencia total de la solicitud aún incluye DNS, TCP, procesamiento del servidor y datos de aplicación. “TLS 1.3 es 1-RTT” no significa que una solicitud completa siempre cueste solo un RTT.

Pregunta de seguimiento 2: ¿Qué sucede con el tráfico histórico si se filtra la clave privada del certificado?

Si esos handshakes completos utilizaron ECDHE efímero y la implementación borró los valores privados efímeros y los secretos de tráfico obsoletos, la filtración exclusiva de la clave a largo plazo del certificado no debería descifrar el tráfico de aplicación capturado previamente. Ese es el valor de la confidencialidad directa perfecta. Una filtración de la clave de cifrado de tickets, de la PSK, del secreto de sesión o del secreto de tráfico del endpoint tiene un impacto diferente y debe evaluarse frente a los tiempos de vida de los tickets, los registros y la rotación.

Pregunta de seguimiento 3: ¿Por qué un almacén antirrepetición no hace que todas las solicitudes sean seguras para 0-RTT?

Un sistema multirregión global no puede hacer fácilmente que cada ticket y aceptación de early data sea fuertemente consistente y de un solo uso sin agregar latencia. Las particiones de red, el estado de los nodos, la rotación de tickets y las retransmisiones concurrentes de atacantes crean límites. Los controles del protocolo pueden limitar la ventana o la cantidad de retransmisiones exitosas, pero la aplicación aún debe asumir que pueden ocurrir solicitudes duplicadas y restringir early data a operaciones adecuadas.

Pregunta de seguimiento 4: ¿Cómo se verifica si en producción se utilizó un handshake completo, reanudación o 0-RTT?

En un entorno de prueba autorizado, utiliza openssl s_client -connect api.example:443 -servername api.example -tls1_3 -alpn h2 para inspeccionar la versión, el certificado y ALPN. Guarda y reutiliza una sesión, y luego observa si se reanuda y si se aceptan early data. La telemetría del servidor debe registrar el modo de handshake y el motivo del rechazo sin contenidos confidenciales. Descifra capturas de paquetes solo en un entorno controlado con claves de sesión exportadas por el cliente y luego límpialas.

Pregunta de seguimiento 5: ¿Es 425 Too Early una interrupción del servicio (outage)?

No necesariamente. Significa que el servidor rechaza el riesgo de retransmisión y es una ruta de control normal para early data. El cliente debe reintentar después de que finalice el handshake, y el reintento no debe usar early data. Si los usuarios ven fallos repetidos, verifica la implementación de reintentos del cliente, la propagación de Early-Data, la consistencia entre instancias de servidor y si se agregó por error un endpoint no apto a la lista de permitidos de 0-RTT.