Una cadena SOCKS més llarga no amaga automàticament el següent salt

Una cadena canvia qui obre cada connexió. No afegeix xifratge només pel fet d'afegir una altra adreça SOCKS a una llista.

Penseu en un client que construeix aquesta cadena ell mateix:

application → SOCKS A → SOCKS B → website

Primer demana a A que es connecti a B. A través d'aquest flux, pot negociar després amb B una connexió al lloc web. Si el transport del client a A porta les dues negociacions sense xifratge, un observador prou capaç en aquell enllaç pot llegir els bytes de configuració que el client ha enviat. La destinació TCP externa no és l'única prova possible per a l'observador.

Separeu la cadena de l'intercanvi d'aplicació protegit

HTTPS pot protegir el contingut d'aplicació del lloc web després que comenci la seva sessió TLS. No xifra retroactivament els missatges de configuració SOCKS anteriors. L'autenticació per nom d'usuari i contrasenya de SOCKS5 tampoc no és un transport xifrat.

Un esquema xifrat entre el client i el primer salt canvia la visibilitat en aquell enllaç. Encara té un operador i un altre extrem que guarda el flux desxifrat. Descriu aquesta frontera de confiança en lloc d'afirmar que la cadena és impossible de rastrejar.

Una ruta pare configurada al servidor és una altra topologia. Si A tria B internament, el client no necessàriament ha enviat una llista completa d'intermediaris per la seva primera connexió. No afirmeu que cada cadena exposa cada salt de la mateixa manera.

Per a una avaluació útil de la privacitat, anomeneu l'observador, l'enllaç, la negociació amb el proxy i les fronteres TLS. El lloc web que observa la sortida de B i l'observador de la xarxa d'accés que mira la primera connexió del client responen preguntes diferents. Comptar només els salts no respon a cap de les dues.