En längre SOCKS-kedja döljer inte automatiskt nästa hopp

En kedja ändrar vem som öppnar varje anslutning. Den lägger inte till kryptering bara för att ännu en SOCKS-adress sätts upp på en lista.

Tänk dig en klient som bygger den här kedjan själv:

application → SOCKS A → SOCKS B → website

Den ber först A att ansluta till B. Genom den strömmen kan den sedan förhandla med B om en anslutning till webbplatsen. Om transporten från klienten till A bär båda förhandlingarna utan kryptering kan en tillräckligt kapabel observatör på den länken läsa de inställningsbyten som klienten skickade. Den yttre TCP-destinationen är inte observatörens enda möjliga bevis.

Skilj kedjan från det skyddade applikationsutbytet

HTTPS kan skydda webbplatsens applikationsinnehåll efter att dess TLS-session börjat. Det krypterar inte tidigare SOCKS-inställningsmeddelanden i efterhand. Inte heller SOCKS5-autentisering med användarnamn och lösenord är en krypterad transport.

En krypterad ordning mellan klienten och första hoppet ändrar synligheten på den länken. Den har fortfarande en operatör och en annan ändpunkt som håller den dekrypterade strömmen. Beskriv den tillitsgränsen i stället för att hävda att kedjan inte går att spåra.

En överordnad rutt som konfigurerats på servern är en annan topologi. Om A väljer B internt har klienten inte nödvändigtvis skickat en fullständig lista över mellanhänder över sin första anslutning. Påstå inte att varje kedja avslöjar varje hopp på samma sätt.

För en användbar integritetsbedömning, namnge observatören, länken, proxyförhandlingen och TLS-gränserna. Webbplatsen som observerar B:s utgång och observatören i åtkomstnätet som ser klientens första anslutning svarar på olika frågor. Att bara räkna hopp svarar på ingen av dem.