Eine längere SOCKS-Kette verbirgt den nächsten Hop nicht automatisch

Eine Kette ändert, wer jede Verbindung öffnet. Sie fügt nicht allein dadurch Verschlüsselung hinzu, dass eine weitere SOCKS-Adresse in eine Liste aufgenommen wird.

Betrachten Sie einen Client, der diese Kette selbst aufbaut:

application → SOCKS A → SOCKS B → website

Er bittet zuerst A, eine Verbindung zu B herzustellen. Über diesen Strom kann er anschließend mit B eine Verbindung zur Website aushandeln. Trägt der Transport vom Client zu A beide Aushandlungen unverschlüsselt, kann ein hinreichend leistungsfähiger Beobachter auf dieser Strecke die vom Client gesendeten Einrichtungsbytes lesen. Das äußere TCP-Ziel ist nicht der einzige mögliche Beleg des Beobachters.

Trennen Sie die Kette vom geschützten Anwendungsaustausch

HTTPS kann die Anwendungsinhalte der Website schützen, nachdem ihre TLS-Sitzung begonnen hat. Frühere SOCKS-Einrichtungsnachrichten verschlüsselt es nicht rückwirkend. Auch die SOCKS5-Authentifizierung mit Benutzername und Passwort ist kein verschlüsselter Transport.

Eine verschlüsselte Anordnung zwischen Client und erstem Hop verändert die Sichtbarkeit auf dieser Strecke. Sie hat weiterhin einen Betreiber und einen weiteren Endpunkt, der den entschlüsselten Strom hält. Beschreiben Sie diese Vertrauensgrenze, statt zu behaupten, die Kette sei nicht nachvollziehbar.

Eine serverseitig konfigurierte Elternroute ist eine andere Topologie. Wählt A intern B, hat der Client über seine erste Verbindung nicht zwangsläufig eine vollständige Liste der Zwischenstationen gesendet. Behaupten Sie nicht, jede Kette lege jeden Hop auf dieselbe Weise offen.

Für eine brauchbare Datenschutzbewertung benennen Sie Beobachter, Strecke, Proxy-Aushandlung und TLS-Grenzen. Die Website, die Bs Ausgang beobachtet, und der Beobachter im Zugangsnetz, der die erste Verbindung des Clients sieht, beantworten verschiedene Fragen. Das bloße Zählen von Hops beantwortet keine von beiden.