En lengre SOCKS-kjede skjuler ikke automatisk neste hopp

En kjede endrer hvem som åpner hver forbindelse. Den legger ikke til kryptering bare ved at nok en SOCKS-adresse settes på en liste.

Tenk deg en klient som bygger denne kjeden selv:

application → SOCKS A → SOCKS B → website

Den ber først A om å koble til B. Gjennom den strømmen kan den deretter forhandle med B om en forbindelse til nettstedet. Hvis transporten fra klienten til A bærer begge forhandlingene uten kryptering, kan en tilstrekkelig dyktig observatør på den lenken lese oppsettsbyttene som klienten sendte. Den ytre TCP-destinasjonen er ikke observatørens eneste mulige bevis.

Skill kjeden fra den beskyttede applikasjonsutvekslingen

HTTPS kan beskytte nettstedets applikasjonsinnhold etter at TLS-økten begynner. Det krypterer ikke tidligere SOCKS-oppsettsmeldinger bakover. SOCKS5-godkjenning med brukernavn og passord er heller ikke en kryptert transport.

En kryptert ordning mellom klienten og første hopp endrer synligheten på den lenken. Den har fortsatt en operatør og et annet endepunkt som holder den dekrypterte strømmen. Beskriv den tillitsgrensen i stedet for å hevde at kjeden ikke kan spores.

En overordnet rute konfigurert på serveren er en annen topologi. Hvis A velger B internt, har klienten ikke nødvendigvis sendt en fullstendig liste over mellommenn over sin første forbindelse. Ikke hevd at enhver kjede avdekker hvert hopp på samme måte.

For en nyttig personvernvurdering, navngi observatøren, lenken, proxy-forhandlingen og TLS-grensene. Nettstedet som observerer Bs utgang, og observatøren i aksessnettet som ser klientens første forbindelse, svarer på forskjellige spørsmål. Å telle hopp alene svarer på ingen av dem.