Una catena SOCKS più lunga non nasconde automaticamente il salto successivo

Una catena cambia chi apre ogni connessione. Non aggiunge cifratura solo perché un altro indirizzo SOCKS viene aggiunto a un elenco.

Considerate un client che costruisce da sé questa catena:

application → SOCKS A → SOCKS B → website

Chiede prima ad A di connettersi a B. Attraverso quel flusso può poi negoziare con B una connessione al sito. Se il trasporto dal client ad A porta entrambe le negoziazioni senza cifratura, un osservatore sufficientemente capace su quel collegamento può leggere i byte di configurazione inviati dal client. La destinazione TCP esterna non è l'unica prova possibile per l'osservatore.

Separate la catena dallo scambio applicativo protetto

HTTPS può proteggere il contenuto applicativo del sito dopo l'inizio della sessione TLS. Non cifra retroattivamente i precedenti messaggi di configurazione SOCKS. Neanche l'autenticazione SOCKS5 con nome utente e password è un trasporto cifrato.

Un assetto cifrato tra il client e il primo salto cambia la visibilità su quel collegamento. Ha ancora un operatore e un altro estremo che detiene il flusso decifrato. Descrivete quel confine di fiducia invece di affermare che la catena non è tracciabile.

Una rotta padre configurata sul server è un'altra topologia. Se A sceglie B internamente, il client non ha necessariamente inviato un elenco completo di intermediari sulla sua prima connessione. Non affermate che ogni catena espone ogni salto allo stesso modo.

Per una valutazione utile della privacy, nominate l'osservatore, il collegamento, la negoziazione con il proxy e i confini TLS. Il sito che osserva l'uscita di B e l'osservatore della rete d'accesso che guarda la prima connessione del client rispondono a domande diverse. Contare solo i salti non risponde a nessuna delle due.