Intercambio de claves TLS fronte ao certificado de cliente: cal inicia sesión?

Levar un valor público de intercambio de claves nun saludo non é o mesmo suceso que un cliente que inicia sesión. Un establece o estado criptográfico da conexión; o outro declara quen é o cliente, e só ocorre cando o servidor o pide e o intercambio o admite. Tratar o primeiro como o segundo leva a conclusións equivocadas sobre o que oculta unha VPN e o que non. Lea as mensaxes e despois decida cal das catro propiedades observou realmente.

Dous obxectos que se parecen nunha captura

Un cliente TLS 1.3 pode achegar material de intercambio de claves no seu primeiro voo sen presentar ningún certificado. Esa achega é pública por deseño, porque o servidor a necesita para derivar o segredo compartido. O certificado de cliente é outra mensaxe e só se envía despois de que o servidor solicite un. Leva unha identidade que o servidor verifica despois, e a autenticación mutua é unha decisión do servidor, non unha propiedade que implique o conxunto de cifrados. A identidade da aplicación é unha terceira cousa completamente distinta: un formulario de acceso, un token de portador, unha cookie. Nada iso aparece no saludo, e todo iso sobrevive a un cambio de ruta de rede.

As catro filas son independentes. Unha conexión pode ter a primeira e a segunda fila, saltar a terceira e aínda así levar a cuarta nunha cabeceira de cookie.

Decida que pode demostrar un saludo capturado

Só co saludo, un observador coñece a versión negociada, o conxunto de cifrados, o certificado do servidor e os valores públicos de intercambio de claves. Iso abonda para tomar unha pegada dunha implementación de cliente e para ver a que servidor se contactou. O que non achega é o estado privado necesario para descifrar a conexión, cuxa seguridade descansa no intercambio efémero e non na parte pública. Tampouco achega unha identidade de conta, que nunca estivo no saludo desde o principio.

Así que a conclusión honesta é estreita: neste intercambio non se presentou ningún certificado de cliente. Non é que o cliente non enviase nada enlazable, e desde logo non é que a sesión non levase ningún identificador.

Lea as mensaxes en lugar do nome do cifrado

Pregunte ao servidor que solicita, en vez de deducilo do conxunto de cifrados. Un saludo TLS 1.3 que inclúe unha solicitude de certificado é visible na transcrición, e a súa ausencia tamén o é.

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

Despois repita cun certificado de cliente configurado e compare. A segunda execución debería mostrar o certificado enviado e aceptado; a primeira non debería mostrar ningún, e esa é a diferenza concreta da que trata o argumento.

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

Se só precisa o caso ordinario de navegación, a saída detallada do cliente abonda para ver a versión do protocolo, o resultado da verificación e se se ofreceu un certificado de cliente. Un servidor que nunca envía unha solicitude de certificado non puido recibir unha.

Onde a reanudación cambia a resposta

A reanudación de TLS 1.3 usa tickets asociados a estado secreto, de xeito que unha conexión posterior pode completarse sen un intercambio completo de certificados. Iso reduce o que ve un observador e cambia o que demostra a transcrición. Non crea unha identidade onde non a había. Unha sesión reanudada segue pertencendo á mesma sesión de aplicación, e calquera cookie ou token desa sesión segue sendo o identificador que importa.

Por iso unha revisión de privacidade que se detén en "ningún certificado de cliente" perde a parte interesante. A pregunta que hai que facer é que parte ten un identificador estable, non que mensaxe faltou nun saludo.

Anote catro propiedades, non un só veredicto

Anote o acordo de claves, a verificación do servidor, a autenticación do cliente e a identidade da aplicación como catro liñas separadas, coa evidencia de cada unha. Ese inventario sobrevive aos cambios de versión do protocolo, e fai que un argumento sobre privacidade sexa comprobable por outra persoa. Despois engada que achega a ruta de rede. Unha VPN cambia o enderezo de orixe que ve un servizo; non elimina un inicio de sesión, unha cookie nin unha pegada de dispositivo que a aplicación xa ten.

Anote xuntos a versión negociada da conexión e o resultado da solicitude de certificado, porque ese par é o que un revisor necesita para reproducir a súa conclusión sen unha captura propia.