Een langere SOCKS-keten verbergt de volgende hop niet automatisch

Een keten verandert wie elke verbinding opent. Ze voegt geen versleuteling toe alleen doordat er nog een SOCKS-adres aan een lijst wordt toegevoegd.

Bekijk een client die deze keten zelf opbouwt:

application → SOCKS A → SOCKS B → website

Hij vraagt eerst A om verbinding te maken met B. Via die stroom kan hij daarna met B onderhandelen over een verbinding met de website. Als het transport van de client naar A beide onderhandelingen onversleuteld draagt, kan een voldoende capabele waarnemer op die schakel de instelbytes lezen die de client heeft verzonden. De buitenste TCP-bestemming is niet het enige mogelijke bewijs voor de waarnemer.

Scheid de keten van de beschermde applicatie-uitwisseling

HTTPS kan de applicatie-inhoud van de website beschermen nadat de TLS-sessie begint. Het versleutelt eerdere SOCKS-instelberichten niet met terugwerkende kracht. Ook SOCKS5-authenticatie met gebruikersnaam en wachtwoord is geen versleuteld transport.

Een versleutelde opzet tussen de client en de eerste hop verandert de zichtbaarheid op die schakel. Er is nog steeds een operator en een ander eindpunt dat de ontsleutelde stroom vasthoudt. Beschrijf die vertrouwensgrens in plaats van te beweren dat de keten niet te traceren is.

Een op de server geconfigureerde bovenliggende route is een andere topologie. Als A B intern kiest, heeft de client niet noodzakelijk een volledige lijst van tussenstations over zijn eerste verbinding gestuurd. Beweer niet dat elke keten elke hop op dezelfde manier blootlegt.

Voor een bruikbare privacybeoordeling noemt u de waarnemer, de schakel, de proxy-onderhandeling en de TLS-grenzen. De website die de uitgang van B waarneemt en de waarnemer in het toegangsnetwerk die de eerste verbinding van de client ziet, beantwoorden verschillende vragen. Alleen hops tellen beantwoordt geen van beide.