Intercambio de claves TLS frente al certificado de cliente: ¿cuál inicia sesión?

Llevar un valor público de intercambio de claves en un saludo no es el mismo suceso que un cliente que inicia sesión. Uno establece el estado criptográfico de la conexión; el otro declara quién es el cliente, y solo ocurre cuando el servidor lo pide y el intercambio lo admite. Tratar el primero como el segundo lleva a conclusiones equivocadas sobre qué oculta una VPN y qué no. Lea los mensajes y después decida cuál de las cuatro propiedades observó realmente.

Dos objetos que se parecen en una captura

Un cliente TLS 1.3 puede aportar material de intercambio de claves en su primer vuelo sin presentar ningún certificado. Esa aportación es pública por diseño, porque el servidor la necesita para derivar el secreto compartido. El certificado de cliente es otro mensaje y solo se envía después de que el servidor solicite uno. Lleva una identidad que el servidor verifica después, y la autenticación mutua es una decisión del servidor, no una propiedad que implique el conjunto de cifrados. La identidad de la aplicación es una tercera cosa completamente distinta: un formulario de acceso, un token de portador, una cookie. Nada de eso aparece en el saludo, y todo ello sobrevive a un cambio de ruta de red.

Las cuatro filas son independientes. Una conexión puede tener la primera y la segunda fila, saltarse la tercera y aun así llevar la cuarta en una cabecera de cookie.

Decida qué puede demostrar un saludo capturado

Solo con el saludo, un observador conoce la versión negociada, el conjunto de cifrados, el certificado del servidor y los valores públicos de intercambio de claves. Eso basta para tomar una huella de una implementación de cliente y para ver a qué servidor se contactó. Lo que no aporta es el estado privado necesario para descifrar la conexión, cuya secrecía descansa en el intercambio efímero y no en la parte pública. Tampoco aporta una identidad de cuenta, que nunca estuvo en el saludo desde el principio.

Así que la conclusión honesta es estrecha: en este intercambio no se presentó ningún certificado de cliente. No es que el cliente no enviara nada enlazable, y desde luego no es que la sesión no llevara ningún identificador.

Lea los mensajes en lugar del nombre del cifrado

Pregunte al servidor qué solicita, en vez de deducirlo del conjunto de cifrados. Un saludo TLS 1.3 que incluye una solicitud de certificado es visible en la transcripción, y su ausencia lo es igualmente.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Después repita con un certificado de cliente configurado y compare. La segunda ejecución debería mostrar el certificado enviado y aceptado; la primera no debería mostrar ninguno, y esa es la diferencia concreta de la que trata el argumento.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

Si solo necesita el caso ordinario de navegación, la salida detallada del cliente basta para ver la versión del protocolo, el resultado de la verificación y si se ofreció un certificado de cliente. Un servidor que nunca envía una solicitud de certificado no puede haber recibido uno.

Dónde la reanudación cambia la respuesta

La reanudación de TLS 1.3 usa tickets asociados a estado secreto, de modo que una conexión posterior puede completarse sin un intercambio completo de certificados. Eso reduce lo que ve un observador y cambia lo que demuestra la transcripción. No crea una identidad donde no la había. Una sesión reanudada sigue perteneciendo a la misma sesión de aplicación, y cualquier cookie o token de esa sesión sigue siendo el identificador que importa.

Por eso una revisión de privacidad que se detiene en "ningún certificado de cliente" se pierde la parte interesante. La pregunta que hay que hacer es qué parte tiene un identificador estable, no qué mensaje faltó en un saludo.

Anote cuatro propiedades, no un solo veredicto

Anote el acuerdo de claves, la verificación del servidor, la autenticación del cliente y la identidad de la aplicación como cuatro líneas separadas, con la evidencia de cada una. Ese inventario sobrevive a los cambios de versión del protocolo y hace que un argumento sobre privacidad sea comprobable por otra persona. Después añada qué aporta la ruta de red. Una VPN cambia la dirección de origen que ve un servicio; no elimina un inicio de sesión, una cookie ni una huella de dispositivo que la aplicación ya tiene.

Anote juntos la versión negociada de la conexión y el resultado de la solicitud de certificado, porque ese par es lo que un revisor necesita para reproducir su conclusión sin una captura propia.