Planteamiento y contexto
Usted opera una conexión administrativa de larga duración. La mayoría de las solicitudes deben evitar el trabajo de certificados de cliente, pero las operaciones de alto riesgo deben identificar al cliente. Diseñe la autenticación de cliente posterior al handshake en TLS 1.3 y explique su límite en comparación con mutual TLS durante el handshake inicial.
Qué está evaluando el entrevistador
La respuesta debe tratar la autenticación posterior al handshake como un flujo de mensajes opcional de TLS 1.3, no como una segunda conexión TLS. Debe cubrir que el cliente anuncie la capacidad post_handshake_auth en su ClientHello inicial, que el servidor envíe CertificateRequest más tarde, que el cliente devuelva su cadena de certificados y CertificateVerify, el manejo de fallos y la vinculación del resultado a HTTP/2, HTTP/3 o una solicitud de aplicación.
Preguntas aclaratorias para hacer primero
Alcance de la autenticación
Pregunte si la autenticación es una vez por conexión, una vez por solicitud de alto riesgo o dependiente del inquilino. Almacenarla en caché durante demasiado tiempo amplía la ventana de revocación; solicitarla con demasiada frecuencia añade costes de validación de certificados y mensajes de protocolo.
Límite de protocolo e implementación
Confirme si la conexión transporta HTTP/1.1, HTTP/2, HTTP/3 o un protocolo personalizado, y si la biblioteca TLS expone una API posterior al handshake. La aplicación debe bloquear las operaciones protegidas hasta que se complete la autenticación.
Política de fallos y revocación
Defina si un certificado caducado, una CA desconocida, una firma incorrecta o una capacidad no admitida rechaza una solicitud, cierra la conexión o deja una sesión de pocos privilegios. Identifique la fuente de OCSP, certificados cortos o listas de revocación.
Estructura de respuesta de 30 segundos
“La autenticación posterior al handshake en TLS 1.3 requiere que el cliente anuncie post_handshake_auth en su ClientHello inicial. Posteriormente, el servidor envía CertificateRequest; el cliente devuelve Certificate, CertificateVerify y Finished. El servidor valida la cadena, el uso, la firma y el estado de revocación antes de vincular la identidad a solicitudes posteriores. Si la capacidad no se negoció o la validación falla, la política debe rechazar la operación protegida o cerrar la conexión en lugar de degradar silenciosamente.”
Respuesta detallada paso a paso
Paso 1: Negociar la capacidad y crear una sesión cifrada no autenticada
El cliente anuncia el soporte en ClientHello. El servidor completa el handshake TLS 1.3 ordinario pero marca la conexión como cifrada y no autenticada por cliente. A un cliente que no anunció la capacidad no se le puede exigir que presente un certificado más tarde; enrútelo a privilegios bajos o reconéctelo según la política.
Paso 2: Enviar CertificateRequest cuando la política lo requiera
Cuando un endpoint de alto riesgo o una política de inquilino requiera identidad, el servidor envía CertificateRequest con algoritmos de firma aceptables y restricciones de autoridad de certificación. La máquina de estados TLS debe serializar esto con las escrituras de la aplicación para que los flujos concurrentes no puedan observar un estado a medio actualizar.
Paso 3: Validar la respuesta del cliente
El cliente envía su cadena de certificados, CertificateVerify y Finished. Valide la cadena, la identidad SAN o URI, el uso de claves, el algoritmo de firma, la validez y la revocación. Solo entonces adjunte la identidad, la huella digital del certificado y la hora de autenticación al contexto de la conexión. Las solicitudes sensibles que lleguen antes deben encolarse o rechazarse.
Paso 4: Gestionar fallos y reintentos
Ante una capacidad no admitida, un certificado faltante, una firma inválida o una revocación, devuelva un error de aplicación, envíe una alerta TLS o cierre según la política. Limite los reintentos por recuento y tiempo. Nunca convierta automáticamente una solicitud de alto riesgo fallida en una solicitud anónima. Registre clases de error y versiones de configuración sin material de clave privada ni contenidos de certificado innecesarios.
Paso 5: Considerar la reanudación, concurrencia y migración
La reanudación de sesión no demuestra automáticamente que la autorización de aplicación actual siga siendo válida. Reevalúe la política en una conexión reanudada. Con la multiplexación de HTTP/2, un flujo puede activar la autenticación mientras otros flujos envían solicitudes, por lo que debe definir el límite de bloqueo. Confirme que la implementación de QUIC/TLS en HTTP/3 admita el flujo de mensajes antes de prometerlo.
Paso 6: Operar la confianza y el material de claves
Utilice una CA de cliente dedicada, certificados de corta duración y un despliegue de almacén de confianza auditable. Durante la rotación de CA, mantenga una ventana de doble confianza y una ruta de reversión. Separe los permisos para claves privadas del servidor, almacenes de confianza y publicación de políticas; la verificación de clientes no debe otorgar acceso a operaciones con claves del servidor.
Paso 7: Probar y observar
Construya una matriz de clientes con y sin la capacidad. Pruebe el éxito, certificados caducados, firmas incorrectas, revocación, tiempos de espera, flujos concurrentes y reanudación. Supervise la tasa de CertificateRequest, la tasa de éxito, las clases de fallos, la latencia de autenticación, las solicitudes protegidas rechazadas y los cierres de conexión. Asegúrese de que los registros de prueba no expongan claves privadas ni cargas útiles sensibles completas.
Respuesta de muestra de alta calidad
Modelaría dos estados: cifrado-pero-no-autenticado y autenticado-por-cliente. El cliente debe anunciar post_handshake_auth en ClientHello antes de que el servidor pueda enviar CertificateRequest. El cliente devuelve su cadena, CertificateVerify y Finished; el servidor comprueba CA, SAN, uso, firma, validez y revocación antes de vincular la identidad a la solicitud de alto riesgo.
Si la capacidad no se negoció o la validación falla, rechace la operación protegida; no degrade silenciosamente. Congele los flujos HTTP/2 protegidos mientras la autenticación esté pendiente y verifique el soporte de la biblioteca para HTTP/3. Reevalúe la autorización después de la reanudación. Despliegue con una matriz de clientes y observe iniciación, éxito, motivos de fallo, latencia y comportamiento de revocación.
Errores comunes
- Error: Asumir que una conexión establecida significa que el cliente está autenticado. → Por qué falla: El cifrado y la identidad del cliente son estados independientes. → Solución: Rastrear ambos estados explícitamente.
- Error: Exigir un certificado a un cliente que no negoció la capacidad. → Por qué falla: La capacidad debe anunciarse en el ClientHello inicial. → Solución: Utilizar una política de bajos privilegios o de reconexión.
- Error: Ejecutar la solicitud después de que la autenticación falle. → Por qué falla: Los mensajes de autenticación llegan de forma asíncrona y no aseguran el trabajo retroactivamente. → Solución: Bloquear los flujos protegidos hasta que se complete la validación.
- Error: Reutilizar una identidad de conexión antigua para una nueva autorización de inquilino. → Por qué falla: La reanudación y los cambios de política pueden invalidar el estado antiguo de la aplicación. → Solución: Reevaluar utilizando una versión de autorización.
Preguntas y respuestas de seguimiento
Pregunta de seguimiento 1: ¿Por qué sigue siendo común el mutual TLS inicial?
El mutual TLS inicial selecciona y verifica la identidad antes de que termine el handshake, por lo que su estado y compatibilidad son más simples cuando cada solicitud requiere autenticación. La autenticación posterior al handshake se adapta a conexiones de larga duración donde solo una minoría de operaciones necesita identidad adicional, a costa de más estado y reglas de concurrencia.
Pregunta de seguimiento 2: ¿Puede reemplazar la autorización de la aplicación?
No. Demuestra la posesión de una clave privada y una cadena de certificados válida. La aplicación aún asigna el SAN, inquilino, rol, operación y estado de revocación a una decisión de autorización y registra la versión de la decisión.
Pregunta de seguimiento 3: ¿Se debe desconectar a un cliente sin certificado?
No siempre. Una política puede mantener una sesión de bajos privilegios y rechazar solicitudes protegidas. Un plano de gestión que requiera autenticación continua debe devolver un error claro y cerrar. Haga que la elección sea auditable y observable.
Pregunta de seguimiento 4: ¿Cómo se demuestra que una biblioteca admite el flujo?
Compruebe la API con versiones y las pruebas de interoperabilidad para la negociación de extensiones, CertificateRequest, certificados inválidos, flujos concurrentes y reanudación. Una sola bandera de configuración no demuestra que la máquina de estados completa esté implementada.