Intercanvi de claus TLS enfront del certificat de client: quin inicia la sessió?

Portar un valor públic d’intercanvi de claus en una apretada de mà no és el mateix esdeveniment que un client que inicia la sessió. L’un estableix l’estat criptogràfic de la connexió; l’altre diu qui és el client, i només passa quan el servidor ho demana i l’intercanvi ho permet. Tractar el primer com el segon porta a conclusions equivocades sobre què amaga un VPN i què no. Llegiu els missatges i després decidiu quina de les quatre propietats heu observat de debò.

Dos objectes que semblen iguals en una captura

Un client TLS 1.3 pot aportar material d’intercanvi de claus en el seu primer vol sense presentar cap certificat. Aquesta aportació és pública per disseny, perquè el servidor la necessita per derivar el secret compartit. El certificat de client és un missatge diferent i només s’envia després que el servidor en demani un. Porta una identitat que després el servidor verifica, i l’autenticació mútua és una decisió del servidor, no una propietat que impliqui el conjunt de xifratges. La identitat de l’aplicació és una tercera cosa ben diferent: un formulari d’accés, un testimoni de portador, una galeta. Cap d’aquestes apareix a l’apretada de mà, i totes sobreviuen a un canvi de camí de xarxa.

Les quatre files són independents. Una connexió pot tenir la primera i la segona fila, saltar-se la tercera i encara portar la quarta en una capçalera de galeta.

Decidiu què pot demostrar una apretada de mà capturada

Només amb l’apretada de mà, un observador aprèn la versió negociada, el conjunt de xifratges, el certificat del servidor i els valors públics d’intercanvi de claus. Això n’hi ha prou per obtenir una empremta d’una implementació de client i per veure a quin servidor es va contactar. El que no aporta és l’estat privat necessari per desxifrar la connexió, la secreciesa del qual descansa en l’intercanvi efímer i no en la part pública. Tampoc no aporta una identitat de compte, que mai no havia estat a l’apretada de mà.

Per tant, la conclusió honesta és estreta: en aquest intercanvi no es va presentar cap certificat de client. No és que el client no enviés res enllaçable, i de cap manera no és que la sessió no portés cap identificador.

Llegiu els missatges en lloc del nom del xifratge

Pregunteu al servidor què demana, en lloc de deduir-ho del conjunt de xifratges. Una apretada de mà TLS 1.3 que inclou una sol·licitud de certificat és visible a la transcripció, i la seva absència ho és igualment.

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

Després repetiu amb un certificat de client configurat i compareu. La segona execució hauria de mostrar el certificat enviat i acceptat; la primera no n’hauria de mostrar cap, i aquesta és la diferència concreta de què tracta l’argument.

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

Si només us cal el cas ordinari de navegació, la sortida detallada del client ja n’hi ha prou per veure la versió del protocol, el resultat de la verificació i si es va oferir un certificat de client. Un servidor que mai no envia una sol·licitud de certificat no n’ha pogut rebre cap.

On la represa canvia la resposta

La represa de TLS 1.3 fa servir tiquets associats a estat secret, de manera que una connexió posterior pot completar-se sense un intercanvi complet de certificats. Això redueix el que veu un observador i canvia el que demostra la transcripció. No crea una identitat on no n’hi havia. Una sessió represa continua pertanyent a la mateixa sessió d’aplicació, i qualsevol galeta o testimoni d’aquella sessió continua sent l’identificador que importa.

Per això una revisió de privadesa que s’atura a "cap certificat de client" es perd la part interessant. La pregunta que cal fer és quina part té un identificador estable, no quin missatge va faltar en una apretada de mà.

Anoteu quatre propietats, no un sol veredicte

Anoteu l’acord de claus, la verificació del servidor, l’autenticació del client i la identitat de l’aplicació com quatre línies separades, amb l’evidència de cadascuna. Aquest inventari sobreviu als canvis de versió del protocol i fa que un argument sobre privadesa sigui verificable per una altra persona. Després afegiu què hi aporta el camí de xarxa. Un VPN canvia l’adreça d’origen que veu un servei; no elimina un inici de sessió, una galeta ni una empremta de dispositiu que l’aplicació ja té.

Anoteu junts la versió negociada de la connexió i el resultat de la sol·licitud de certificat, perquè aquesta parella és el que un revisor necessita per reproduir la vostra conclusió sense una captura pròpia.