Dłuższy łańcuch SOCKS nie ukrywa automatycznie następnego przeskoku

Łańcuch zmienia to, kto otwiera każde połączenie. Nie dodaje szyfrowania tylko dlatego, że do listy dopisano kolejny adres SOCKS.

Wyobraźmy sobie klienta, który sam buduje ten łańcuch:

application → SOCKS A → SOCKS B → website

Najpierw prosi A o połączenie z B. Przez ten strumień może następnie wynegocjować z B połączenie ze stroną. Jeśli transport od klienta do A przenosi oba negocjacje bez szyfrowania, odpowiednio zdolny obserwator na tym łączu może odczytać bajty konfiguracji wysłane przez klienta. Zewnętrzny cel TCP nie jest jedynym możliwym dowodem obserwatora.

Oddziel łańcuch od chronionej wymiany aplikacji

HTTPS może chronić treść aplikacji strony po rozpoczęciu jej sesji TLS. Nie szyfruje jednak wstecz wcześniejszych komunikatów konfiguracji SOCKS. Także uwierzytelnianie SOCKS5 nazwą użytkownika i hasłem nie jest szyfrowanym transportem.

Szyfrowany układ między klientem a pierwszym przeskokiem zmienia widoczność na tym łączu. Nadal ma operatora i inny punkt końcowy, który trzyma odszyfrowany strumień. Opisz tę granicę zaufania, zamiast twierdzić, że łańcucha nie da się prześledzić.

Trasa nadrzędna skonfigurowana na serwerze to inna topologia. Jeśli A wybiera B wewnętrznie, klient niekoniecznie wysłał pełną listę pośredników pierwszym połączeniem. Nie twierdź, że każdy łańcuch ujawnia każdy przeskok w ten sam sposób.

Do użytecznej oceny prywatności nazwij obserwatora, łącze, negocjację z proxy i granice TLS. Strona obserwująca wyjście B i obserwator sieci dostępowej patrzący na pierwsze połączenie klienta odpowiadają na różne pytania. Samo liczenie przeskoków nie odpowiada na żadne z nich.