Scambio di chiavi TLS e certificato client: quale dei due accede?

Trasportare un valore pubblico di scambio chiavi in un handshake non è lo stesso evento di un client che accede. Uno stabilisce lo stato crittografico della connessione; l’altro dichiara chi è il client, e avviene solo quando il server lo chiede e lo scambio lo supporta. Trattare il primo come il secondo porta a conclusioni sbagliate su ciò che una VPN nasconde e ciò che non nasconde. Leggi i messaggi e poi decidi quale delle quattro proprietà hai davvero osservato.

Due oggetti che sembrano uguali in una cattura

Un client TLS 1.3 può fornire materiale di scambio chiavi nel suo primo volo senza presentare alcun certificato. Quel contributo è pubblico per progetto, perché il server ne ha bisogno per derivare il segreto condiviso. Il certificato client è un altro messaggio e viene inviato solo dopo che il server ne ha richiesto uno. Porta un’identità che il server verifica poi, e l’autenticazione reciproca è una decisione del server, non una proprietà implicata dalla suite di cifratura. L’identità dell’applicazione è una terza cosa del tutto diversa: un modulo di accesso, un token bearer, un cookie. Nulla di questo compare nell’handshake, e tutto sopravvive a un cambio di percorso di rete.

Le quattro righe sono indipendenti. Una connessione può avere la prima e la seconda riga, saltare la terza e portare comunque la quarta in un’intestazione cookie.

Decidi che cosa può dimostrare un handshake catturato

Solo dall’handshake un osservatore apprende la versione negoziata, la suite di cifratura, il certificato del server e i valori pubblici di scambio chiavi. Basta per prendere un’impronta di un’implementazione client e per vedere quale server è stato contattato. Ciò che non fornisce è lo stato privato necessario a decifrare la connessione, la cui segretezza poggia sullo scambio effimero e non sulla parte pubblica. Non fornisce neppure un’identità di account, che non è mai stata nell’handshake fin dall’inizio.

Quindi la conclusione onesta è stretta: in questo scambio non è stato presentato alcun certificato client. Non è che il client non abbia inviato nulla di collegabile, e di certo non è che la sessione non portasse alcun identificatore.

Leggi i messaggi invece del nome del cifrario

Chiedi al server che cosa richiede, invece di dedurlo dalla suite di cifratura. Un handshake TLS 1.3 che include una richiesta di certificato è visibile nella trascrizione, e la sua assenza lo è altrettanto.

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

Poi ripeti con un certificato client configurato e confronta. La seconda esecuzione dovrebbe mostrare il certificato inviato e accettato; la prima non dovrebbe mostrarne nessuno, e questa è la differenza concreta di cui si discute.

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

Se ti serve solo il caso di navigazione ordinario, l’output dettagliato del client basta per vedere la versione del protocollo, l’esito della verifica e se è stato offerto un certificato client. Un server che non invia mai una richiesta di certificato non può averne ricevuto uno.

Dove la ripresa cambia la risposta

La ripresa TLS 1.3 usa ticket associati a stato segreto, così una connessione successiva può completarsi senza uno scambio completo di certificati. Ciò riduce quello che un osservatore vede e cambia quello che la trascrizione dimostra. Non crea un’identità dove non c’era. Una sessione ripresa appartiene ancora alla stessa sessione applicativa, e qualsiasi cookie o token in quella sessione resta l’identificatore che conta.

Per questo una revisione della privacy che si ferma a «nessun certificato client» perde la parte interessante. La domanda da porre è quale parte detiene un identificatore stabile, non quale messaggio mancasse in un handshake.

Annota quattro proprietà, non un solo verdetto

Annota accordo sulle chiavi, verifica del server, autenticazione del client e identità dell’applicazione come quattro righe separate, con l’evidenza di ciascuna. Questo inventario sopravvive ai cambi di versione del protocollo, e rende un’argomentazione sulla privacy verificabile da altri. Poi aggiungi che cosa apporta il percorso di rete. Una VPN cambia l’indirizzo sorgente che un servizio vede; non rimuove un accesso, un cookie o un’impronta del dispositivo che l’applicazione già possiede.

Annota insieme la versione negoziata della connessione e l’esito della richiesta di certificato, perché è quella coppia che serve a un revisore per riprodurre la tua conclusione senza una cattura propria.