Një zinxhir SOCKS më i gjatë nuk e fsheh automatikisht hapin tjetër

Zinxhiri ndryshon kush hap çdo lidhje. Nuk shton enkriptim thjesht sepse një adresë tjetër SOCKS i shtohet një liste.

Merrni një klient që e ndërton vetë këtë zinxhir:

application → SOCKS A → SOCKS B → website

Së pari i kërkon A-s të lidhet me B. Përmes atij rrjedhe mund të negociojë më pas me B një lidhje me faqen. Nëse transporti nga klienti në A i mban të dyja negociatat pa enkriptim, një vëzhgues mjaft i aftë në atë lidhje mund të lexojë bajtët e konfigurimit që dërgoi klienti. Destinacioni i jashtëm TCP nuk është prova e vetme e mundshme e vëzhguesit.

Ndani zinxhirin nga shkëmbimi i mbrojtur i aplikacionit

HTTPS mund të mbrojë përmbajtjen e aplikacionit të faqes pasi të fillojë sesioni TLS. Nuk i enkripton në mënyrë retroaktive mesazhet e mëparshme të konfigurimit SOCKS. As vërtetimi SOCKS5 me emër përdoruesi dhe fjalëkalim nuk është transport i enkriptuar.

Një rregullim i enkriptuar midis klientit dhe hapit të parë ndryshon dukshmërinë në atë lidhje. Ai vazhdon të ketë një operator dhe një pikë tjetër fundore që mban rrjedhën e dekriptuar. Përshkruani atë kufi besimi në vend që të pohon se zinxhiri është i pagjurmueshëm.

Një rrugë mëmë e konfiguruar në server është topologji tjetër. Nëse A zgjedh B-në nga brenda, klienti nuk ka dërguar domosdoshmërisht një listë të plotë ndërmjetësish përmes lidhjes së tij të parë. Mos poho se çdo zinxhir ekspozon çdo hap në të njëjtën mënyrë.

Për një vlerësim të dobishëm të privatësisë, emërtoni vëzhguesin, lidhjen, negocimin me përfaqësuesin dhe kufijtë e TLS. Faqja që vëzhgon daljen e B dhe vëzhguesi i rrjetit të aksesit që shikon lidhjen e parë të klientit përgjigjen pyetjeve të ndryshme. Numërimi i vetëm i hapave nuk përgjigjet për asnjërën.