En lengre SOCKS-kjede skjuler ikke automatisk neste hopp

En kjede forandrer hvem som åpner hver forbindelse. Den tilfører ikke kryptering bare ved at enda en SOCKS-adresse legges til i en liste.

Se for deg en klient som bygger denne kjeden på egen hånd:

application → SOCKS A → SOCKS B → website

Den ber A først om å koble seg til B. Gjennom den strømmen kan den så forhandle med B om en forbindelse til nettstedet. Dersom overføringen fra klienten til A bærer begge forhandlingene uten kryptering, kan en observatør med nok evne på den koblingen lese oppsettsbyttene klienten sendte. Den ytre TCP-adressen er ikke det eneste beviset en slik observatør kan bygge på.

Hold kjeden atskilt fra den beskyttede applikasjonsutvekslingen

HTTPS kan verne applikasjonsinnholdet til nettstedet når TLS-økten har startet. Det krypterer ikke tidligere SOCKS-oppsettsmeldinger i ettertid. Heller ikke SOCKS5-pålogging med brukernavn og passord er en kryptert overføring.

En kryptert ordning mellom klienten og første hopp endrer innsynet på den koblingen. Den har fortsatt en operatør og et annet endepunkt som sitter med den dekrypterte strømmen. Beskriv denne tillitsgrensen i stedet for å påstå at kjeden ikke lar seg spore.

En overordnet rute satt opp på tjeneren er en annen topologi. Velger A B internt, har ikke klienten nødvendigvis sendt en fullstendig liste over mellommenn på sin første forbindelse. Ikke hevd at hver kjede avdekker hvert hopp på samme vis.

For en nyttig personvernvurdering bør du navngi observatøren, koblingen, forhandlingen med mellomtjeneren og grensene for TLS. Nettstedet som ser utgangen til B, og observatøren i aksessnettet som følger klientens første forbindelse, svarer på forskjellige spørsmål. Bare det å telle hopp svarer på ingen av dem.