Pli longa SOCKS-ĉeno ne aŭtomate kaŝas la sekvan salton

Ĉeno ŝanĝas, kiu malfermas ĉiun konekton. Ĝi ne aldonas ĉifradon simple per tio, ke oni aldonas plian SOCKS-adreson al listo.

Konsideru klienton, kiu mem konstruas ĉi tiun ĉenon:

application → SOCKS A → SOCKS B → website

Ĝi unue petas al A konektiĝi al B. Tra tiu fluo ĝi poste povas intertrakti kun B pri konekto al la retejo. Se la transporto de la kliento al A portas ambaŭ intertraktadojn sen ĉifrado, sufiĉe kapabla observanto sur tiu ligilo povas legi la agordajn bitokojn, kiujn la kliento sendis. La ekstera TCP-celo ne estas la sola ebla pruvo de la observanto.

Apartigu la ĉenon de la protektita aplikada interŝanĝo

HTTPS povas protekti la aplikadan enhavon de la retejo post kiam komenciĝas ĝia TLS-sesio. Ĝi ne ĉifras retroaktive pli fruajn SOCKS-agordajn mesaĝojn. Ankaŭ la aŭtentigo de SOCKS5 per uzantnomo kaj pasvorto ne estas ĉifrita transporto.

Ĉifrita aranĝo inter la kliento kaj la unua salto ŝanĝas videblecon sur tiu ligilo. Ĝi ankoraŭ havas operatoron kaj alian finpunkton, kiu tenas la malĉifritan fluon. Priskribu tiun fidlimon anstataŭ aserti, ke la ĉeno estas nespurebla.

Patra itinero agordita en la servilo estas alia topologio. Se A elektas B interne, la kliento ne nepre sendis kompletan liston de perantoj per sia unua konekto. Ne asertu, ke ĉiu ĉeno malkaŝas ĉiun salton same.

Por utila privateca takso, nomu la observanton, la ligilon, la intertraktadon kun la prokurilo kaj la TLS-limojn. La retejo, kiu observas la eliron de B, kaj la observanto de la alirreto, kiu rigardas la unuan konekton de la kliento, respondas al malsamaj demandoj. Nur nombri saltojn respondas al neniu el ili.