Delší řetěz SOCKS další skok automaticky neskryje

Řetěz mění, kdo otevírá každé spojení. Nepřidává šifrování jen tím, že se do seznamu přidá další adresa SOCKS.

Vezměme klienta, který tento řetěz sestavuje sám:

application → SOCKS A → SOCKS B → website

Nejprve požádá A, aby se připojil k B. Tímto tokem pak může s B vyjednat spojení s webem. Pokud přenos od klienta k A nese obě vyjednávání bez šifrování, dostatečně schopný pozorovatel na tomto spoji může číst nastavovací bajty, které klient odeslal. Vnější cíl TCP není jediným možným důkazem pozorovatele.

Oddělte řetěz od chráněné výměny aplikace

HTTPS dokáže chránit aplikační obsah webu poté, co začne jeho relace TLS. Nešifruje zpětně dřívější nastavovací zprávy SOCKS. Ani ověřování SOCKS5 jménem a heslem není šifrovaný přenos.

Šifrované uspořádání mezi klientem a prvním skokem mění viditelnost na tomto spoji. Stále má provozovatele a další koncový bod, který drží dešifrovaný tok. Popište tuto hranici důvěry, místo abyste tvrdili, že řetěz nelze vystopovat.

Rodičovská trasa nakonfigurovaná na serveru je jiná topologie. Pokud A vybírá B uvnitř, klient nemusel svým prvním spojením poslat úplný seznam prostředníků. Netvrďte, že každý řetěz odhaluje každý skok stejně.

Pro užitečné posouzení soukromí pojmenujte pozorovatele, spoj, vyjednávání s proxy a hranice TLS. Web, který pozoruje výstup B, a pozorovatel přístupové sítě, který sleduje první spojení klienta, odpovídají na různé otázky. Pouhé počítání skoků neodpovídá na ani jednu.