En længere SOCKS-kæde skjuler ikke automatisk det næste hop
Identificér de ukrypterede opsætningsbeskeder i en klientopbygget SOCKS-kæde, før du antager, at endnu et hop skjuler destinationsmetadata.
En kæde ændrer, hvem der åbner hver forbindelse. Den tilføjer ikke kryptering blot ved at sætte endnu en SOCKS-adresse på en liste.
Overvej en klient, der selv bygger denne kæde:
application → SOCKS A → SOCKS B → websiteDen beder først A om at forbinde til B. Gennem den strøm kan den derefter forhandle med B om en forbindelse til webstedet. Hvis transporten fra klienten til A bærer begge forhandlinger uden kryptering, kan en tilstrækkeligt dygtig observatør på det led læse de opsætningsbytes, som klienten sendte. Den ydre TCP-destination er ikke observatørens eneste mulige bevis.
Adskil kæden fra den beskyttede applikationsudveksling
HTTPS kan beskytte webstedets applikationsindhold, efter at dets TLS-session begynder. Det krypterer ikke tidligere SOCKS-opsætningsbeskeder bagudrettet. SOCKS5-godkendelse med brugernavn og adgangskode er heller ikke en krypteret transport.
En krypteret ordning mellem klienten og det første hop ændrer synligheden på det led. Den har stadig en operatør og et andet endepunkt, som holder den dekrypterede strøm. Beskriv den tillidsgrænse i stedet for at hævde, at kæden ikke kan spores.
En overordnet rute, der er konfigureret på serveren, er en anden topologi. Hvis A vælger B internt, har klienten ikke nødvendigvis sendt en fuldstændig liste over mellemled over sin første forbindelse. Påstå ikke, at enhver kæde afslører ethvert hop på samme måde.
For en brugbar privatlivsvurdering skal du navngive observatøren, leddet, proxyforhandlingen og TLS-grænserne. Webstedet, der observerer Bs udgang, og observatøren i adgangsnettet, der ser klientens første forbindelse, besvarer forskellige spørgsmål. At tælle hop alene besvarer ingen af dem.