Unha cadea SOCKS máis longa non agocha automaticamente o seguinte salto

Unha cadea cambia quen abre cada conexión. Non engade cifrado só porque se engada outra dirección SOCKS a unha lista.

Pense nun cliente que constrúe esta cadea por si mesmo:

application → SOCKS A → SOCKS B → website

Primeiro pide a A que se conecte a B. A través dese fluxo pode despois negociar con B unha conexión ao sitio web. Se o transporte do cliente a A leva ambas negociacións sen cifrado, un observador suficientemente capaz nesa ligazón pode ler os bytes de configuración que enviou o cliente. O destino TCP exterior non é a única proba posible para o observador.

Separe a cadea do intercambio de aplicación protexido

HTTPS pode protexer o contido de aplicación do sitio web despois de que comece a súa sesión TLS. Non cifra retroactivamente as mensaxes de configuración SOCKS anteriores. A autenticación SOCKS5 con usuario e contrasinal tampouco é un transporte cifrado.

Un arranxo cifrado entre o cliente e o primeiro salto cambia a visibilidade nesa ligazón. Aínda ten un operador e outro extremo que conserva o fluxo descifrado. Describa esa fronteira de confianza en vez de afirmar que a cadea non se pode rastrexar.

Unha ruta principal configurada no servidor é outra topoloxía. Se A escolle B internamente, o cliente non necesariamente enviou unha lista completa de intermediarios pola súa primeira conexión. Non afirme que cada cadea expón cada salto do mesmo xeito.

Para unha avaliación útil da privacidade, nomee o observador, a ligazón, a negociación co proxy e as fronteiras TLS. O sitio web que observa a saída de B e o observador da rede de acceso que vixía a primeira conexión do cliente responden preguntas distintas. Contar só os saltos non responde a ningunha das dúas.