Garāka SOCKS ķēde automātiski nepaslēpj nākamo lēcienu

Ķēde maina, kas atver katru savienojumu. Tā nepievieno šifrēšanu tikai tāpēc, ka sarakstam pievienota vēl viena SOCKS adrese.

Apskatīsim klientu, kas šo ķēdi veido pats:

application → SOCKS A → SOCKS B → website

Vispirms tas lūdz A izveidot savienojumu ar B. Caur šo straumi tas pēc tam var vienoties ar B par savienojumu ar vietni. Ja pārsūtīšana no klienta uz A pārvadā abas vienošanās bez šifrēšanas, pietiekami spējīgs novērotājs šajā posmā var nolasīt klienta nosūtītos iestatīšanas baitus. Ārējais TCP galamērķis nav vienīgais iespējamais novērotāja pierādījums.

Atdaliet ķēdi no aizsargātās lietojumprogrammas apmaiņas

HTTPS var aizsargāt vietnes lietojumprogrammas saturu pēc tam, kad sākas tās TLS sesija. Tas neatgriezeniski nešifro iepriekšējos SOCKS iestatīšanas ziņojumus. Arī SOCKS5 lietotājvārda/paroles autentifikācija nav šifrēts pārvadījums.

Šifrēta kārtība starp klientu un pirmo lēcienu maina redzamību šajā posmā. Tai joprojām ir operators un cits galapunkts, kas tur atšifrēto straumi. Aprakstiet šo uzticēšanās robežu, nevis apgalvojiet, ka ķēdi nav iespējams izsekot.

Serverī konfigurēts vecākmarsruts ir cita topoloģija. Ja A iekšēji izvēlas B, klients nav obligāti nosūtījis pilnu starpnieku sarakstu savā pirmajā savienojumā. Neapgalvojiet, ka katra ķēde atklāj katru lēcienu vienādi.

Lietderīgam privātuma novērtējumam nosauciet novērotāju, posmu, vienošanos ar starpniekserveri un TLS robežas. Vietne, kas novēro B izeju, un piekļuves tīkla novērotājs, kas vēro klienta pirmo savienojumu, atbild uz dažādiem jautājumiem. Tikai lēcienu skaitīšana neatbild ne uz vienu.