La cifratura del tunnel WSS finisce al terminatore TLS, non nell'app

Un tunnel trasportato dentro un WebSocket sicuro ha esattamente la cifratura che il client vi ha messo, non di più. Lo schema wss:// dice che TLS protegge una connessione su un salto. Non dice nulla sul fatto che i byte dentro i messaggi WebSocket siano protetti separatamente, e questa distinzione decide chi può leggere il tuo traffico quando qualcosa nel mezzo termina TLS.

Due livelli che sembrano uno solo

Un WebSocket sicuro è TLS con una stretta di mano WebSocket eseguita sopra, come descrive RFC 6455 nelle sue sezioni su connessione e sicurezza. Il livello TLS autentica il server e cifra il flusso, poi il livello WebSocket incornicia ciò che l'applicazione decide di inviare.

Sono due decisioni indipendenti, e un diagramma che disegna un solo lucchetto su tutto il percorso nasconde la seconda. Chiedete chi termina la connessione TLS. Poi chiedete cosa mette il client dentro ogni messaggio. Tutto il resto sulla distribuzione deriva da quelle due risposte.

Progetto A: il trasporto è l'unica cifratura

Nel progetto più semplice, il client prende pacchetti IP grezzi e li avvolge in messaggi WebSocket. Nulla all'interno è cifrato, quindi il componente che detiene la sessione TLS legge payload in chiaro. Quando quel componente è il tuo stesso server del tunnel, questo è il punto finale previsto e il progetto è coerente, perché il server avrebbe comunque visto il traffico.

Diventa un'altra disposizione quando un proxy di ispezione si siede sul percorso e termina TLS con un certificato di cui il client si fida. Quel proxy ora detiene lo stesso testo in chiaro che avrebbe detenuto il server, e nessuna quantità di incorniciamento WebSocket lo cambia. Il trust store del client ha deciso questo esito molto prima che il tunnel si aprisse, perché ha scelto di accettare quel certificato per quel nome. Il proxy vede anche l'host richiesto e la dimensione di ogni messaggio, il che basta a prendere l'impronta di molta attività senza decifrare altro.

Progetto B: il payload porta le proprie chiavi

Nel secondo progetto, il client cifra e autentica i suoi pacchetti con un protocollo VPN che ha la propria identità di peer e il proprio scambio di chiavi, poi trasporta il risultato dentro messaggi WebSocket. Terminare qui il TLS esterno espone testo cifrato, non traffico. Il proxy può vedere dimensioni e tempi dei messaggi, e nulla d'altro nel payload. È un'esposizione molto più piccola, ed è comunque metadato che vale la pena nominare in una revisione invece di scacciarlo con un gesto.

Gli endpoint del protocollo interno vedono comunque testo in chiaro, che è il senso della disposizione e anche il suo limite. Se un componente sull'endpoint è autorizzato a leggere dati prima della cifratura o dopo la decifratura, il livello extra non lo vincola. Le chiavi, e il software che le gestisce, restano il confine che conta.

Un'etichetta VPN, un'icona client familiare o una pagina di marketing non sono prova che questo progetto esista. Leggere il formato del payload lo è.

Tracciate dove appare davvero il testo in chiaro

Lo schema dell'URL vi dà un solo fatto, quindi ricavate il resto dalle interfacce. Eseguite i controlli qui sotto in ordine, perché ciascuno restringe il successivo:

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

Iniziate dalla connessione esterna. Una sessione TCP di lunga durata verso la porta TLS è l'aspetto di un vettore WebSocket, e una seconda sessione verso un host non correlato merita una spiegazione prima di guardare più a fondo. Poi trovate l'interfaccia del tunnel sul client, perché un dispositivo tun o tap vi dice che il client gestisce pacchetti IP invece di fare da proxy a un singolo flusso applicativo.

La cattura sull'interfaccia del tunnel di solito risolve la questione del payload. Intestazioni leggibili lì significano che i pacchetti interni non sono mai stati cifrati separatamente, mentre payload ad alta entropia significano che lo sono stati. Ripetete la cattura sull'interfaccia esterna e confrontate le due: se entrambe sembrano casuali, il livello interno fa un lavoro che quello esterno non può annullare.

Rivedete la fiducia che avete davvero concesso

Un certificato radice aziendale installato è un fatto sul trust store del client, non un'asserzione su ciò che un proxy registra o ispeziona. Stabilite la politica distribuita e il percorso di connessione reale invece di dedurre comportamenti dalla presenza di una CA.

Su apparecchiature gestite, chiedete all'amministratore quale componente termina TLS, se il client convalida un certificato appuntato o uno pubblico, e qual è il formato del payload. Quelle tre risposte producono un risultato che potrete difendere in seguito.

Scrivete il risultato come un confine e non come un verdetto. "TLS termina al proxy di ispezione, e il payload interno è cifrato separatamente con chiavi detenute solo dagli endpoint" è un'affermazione verificabile che sopravvive a un cambio di fornitore. "I WebSockets sono sicuri" no.