SOCKS kate luzeago batek ez du hurrengo jauzia automatikoki ezkutatzen
Identifikatu bezeroak eraikitako SOCKS kate bateko konfigurazio-mezu zifratugabeak, beste jauzi batek helmugako metadatuak ezkutatzen dituela suposatu aurretik.
Kateak aldatzen du nork irekitzen duen konexio bakoitza. Ez du zifratzerik gehitzen zerrendan beste SOCKS helbide bat gehitze hutsagatik.
Demagun kate hau berak eraikitzen duen bezero bat:
application → SOCKS A → SOCKS B → website
Lehenengo A-ri eskatzen dio B-rekin konekta dadin. Korronte horren bidez, gero B-rekin negoziatu dezake webgunerako konexioa. Bezerotik A-rako garraioak negoziazio biak zifratu gabe eramaten baditu, esteka horretan gaitasun nahikoa duen behatzaile batek bezeroak bidalitako konfigurazio-byteak irakur ditzake. Kanpoko TCP helmuga ez da behatzailearen froga posible bakarra.
Bereizi katea aplikazio-truke babestutik
HTTPS-ek webgunearen aplikazio-edukia babes dezake bere TLS saioa hasi ondoren. Ez ditu atzeraeraginez zifratzen aurretiko SOCKS konfigurazio-mezuak. SOCKS5 erabiltzaile-izena/pasahitza autentifikazioa ere ez da garraio zifratua.
Bezeroaren eta lehen jauziaren arteko konfigurazio zifratuak esteka horretako ikusgaitasuna aldatzen du. Oraindik operadore bat eta deskodetutako korrontea eusten duen beste mutur bat ditu. Deskribatu konfiantza-muga hori, katea arrastaezina dela esan beharrean.
Zerbitzarian konfiguratutako guraso-bidea beste topologia bat da. A-k B barruan hautatzen badu, bezeroak ez du nahitaez bitartekarien zerrenda osoa bidali bere lehen konexioan. Ez esan kate bakoitzak jauzi bakoitza modu berean agertzen duenik.
Pribatutasun-ebaluazio erabilgarri baterako, izenda itzazu behatzailea, esteka, proxyarekin eginiko negoziazioa eta TLS mugak. B-ren irteera behatzen duen webguneak eta bezeroaren lehen konexioa zaintzen duen sarbide-sareko behatzaileak galdera desberdinak erantzuten dituzte. Jauziak soilik zenbatzeak ez dio bati ere erantzuten.