’n Langer SOCKS-ketting verberg nie outomaties die volgende hop nie

’n Ketting verander wie elke verbinding open. Dit voeg nie enkripsie by bloot deur nog ’n SOCKS-adres by ’n lys te voeg nie.

Oorweeg ’n kliënt wat hierdie ketting self bou:

application → SOCKS A → SOCKS B → website

Dit vra eers A om aan B te koppel. Deur daardie stroom kan dit dan met B onderhandel vir ’n verbinding na die webwerf. As die vervoer van kliënt na A albei onderhandelinge sonder enkripsie dra, kan ’n voldoende bekwame waarnemer op daardie skakel die opstelgrepe lees wat die kliënt gestuur het. Die buitenste TCP-bestemming is nie die waarnemer se enigste moontlike bewyse nie.

Skei die ketting van die beskermde toepassingsuitruiling

HTTPS kan die webwerf se toepassingsinhoud beskerm nadat sy TLS-sessie begin. Dit enkripteer nie terugwerkend vroeëre SOCKS-opstelboodskappe nie. SOCKS5-gebruikersnaam/wagwoord-verifikasie is ook nie ’n geënskripteerde vervoer nie.

’n Geënskripteerde reëling tussen kliënt en eerste hop verander die sigbaarheid op daardie skakel. Dit het steeds ’n operateur en nog ’n eindpunt wat die gedekripteerde stroom hou. Beskryf daardie vertrouensgrens eerder as om te beweer die ketting is onopspoorbaar.

’n Bediener-gekonfigureerde ouerroete is ’n ander topologie. As A B intern kies, het die kliënt nie noodwendig ’n volledige lys tussengangers oor sy eerste verbinding gestuur nie. Moenie beweer elke ketting ontbloot elke hop op dieselfde manier nie.

Vir ’n nuttige privaatheidsevaluering, noem die waarnemer, die skakel, die volmagonderhandeling en die TLS-grense. Die webwerf wat B se uitgang waarneem en die toegangsnetwerk-waarnemer wat die kliënt se eerste verbinding dophou, beantwoord verskillende vrae. Om net hope te tel, beantwoord nie een van die twee nie.