Ei lengre SOCKS-kjede løyner ikkje automatisk neste hopp

Ei kjede endrar kven som opnar kvar tilkopling. Ho legg ikkje til kryptering berre ved at endå ei SOCKS-adresse blir sett på ei liste.

Tenk deg ein klient som byggjer denne kjeda sjølv:

application → SOCKS A → SOCKS B → website

Han ber først A om å kopla til B. Gjennom den straumen kan han deretter forhandla med B om ei tilkopling til nettstaden. Viss transporten frå klienten til A ber begge forhandlingane utan kryptering, kan ein tilstrekkeleg dyktig observatør på den lenkja lesa oppsettsbyta som klienten sende. Den ytre TCP-destinasjonen er ikkje det einaste mogelege provet observatøren har.

Skil kjeda frå den verna applikasjonsutvekslinga

HTTPS kan verna applikasjonsinnhaldet til nettstaden etter at TLS-økta byrjar. Det krypterer ikkje tidlegare SOCKS-oppsettsmeldingar bakover. Ikkje heller er SOCKS5-innlogging med brukarnamn og passord ein kryptert transport.

Ei kryptert ordning mellom klienten og fyrste hopp endrar synlegheiten på den lenkja. Ho har framleis ein operatør og eit anna endepunkt som held den dekrypterte straumen. Skildr den tillitsgrensa i staden for å hevda at kjeda ikkje kan sporast.

Ei overordna rute som er sett opp på tenaren, er ein annan topologi. Viss A vel B internt, har klienten ikkje nødvendigvis sendt ei fullstendig liste over mellommenn over den fyrste tilkoplinga si. Ikkje hevd at kvar kjede avdekkjer kvart hopp på same måte.

For ei nyttig personvernvurdering, namngi observatøren, lenkja, proxy-forhandlinga og TLS-grensene. Nettstaden som observerer utgangen til B, og observatøren i aksessnettet som ser den fyrste tilkoplinga til klienten, svarar på ulike spørsmål. Å telja hopp åleine svarar på ingen av dei.