Շղթան փոխում է, թե ով է բացում յուրաքանչյուր կապը: Այն գաղտնագրում չի ավելացնում միայն այն պատճառով, որ ցանկին ավելացվում է ևս մեկ SOCKS հասցե:

Դիտարկենք հաճախորդ, որը ինքն է կառուցում այս շղթան.

application → SOCKS A → SOCKS B → website

Այն սկզբում խնդրում է A-ին միանալ B-ին: Այդ հոսքի միջով այն հետո կարող է B-ի հետ բանակցել կայքի հետ կապի շուրջ: Եթե հաճախորդից A տրանսպորտը երկու բանակցություններն էլ տեղափոխում է առանց գաղտնագրման, այդ կապուղու վրա բավականաչափ ընդունակ դիտորդը կարող է կարդալ հաճախորդի ուղարկած կարգավորման բայթերը: Արտաքին TCP նպատակակետը դիտորդի միակ հնարավոր ապացույցը չէ:

Առանձնացրեք շղթան պաշտպանված հավելվածային փոխանակումից

HTTPS-ը կարող է պաշտպանել կայքի հավելվածային բովանդակությունը TLS սեսիան սկսվելուց հետո: Այն հետադարձ ուժով չի գաղտնագրում ավելի վաղ SOCKS կարգավորման հաղորդագրությունները: SOCKS5-ի օգտանունով և գաղտնաբառով նույնականացումը նույնպես գաղտնագրված տրանսպորտ չէ:

Հաճախորդի և առաջին ցատկի միջև գաղտնագրված դասավորությունը փոխում է տեսանելիությունը այդ կապուղու վրա: Այն դեռ ունի օպերատոր և մեկ այլ վերջնակետ, որը պահում է ապակոդավորված հոսքը: Նկարագրեք այդ վստահության սահմանը՝ փոխարենը չպնդելով, որ շղթան անհետևելի է:

Սերվերում կարգավորված ծնողական երթուղին այլ տոպոլոգիա է: Եթե A-ն ներքուստ ընտրում է B-ին, հաճախորդը պարտադիր չէ, որ իր առաջին կապով ուղարկած լինի միջնորդների ամբողջական ցանկը: Չպնդեք, որ ամեն շղթա ամեն ցատկ բացահայտում է նույն կերպ:

Օգտակար գաղտնիության գնահատման համար անվանեք դիտորդին, կապուղին, վստահված սերվերի բանակցությունը և TLS սահմանները: B-ի ելքը դիտող կայքը և հաճախորդի առաջին կապը հետևող մուտքի ցանցի դիտորդը տարբեր հարցերի են պատասխանում: Միայն ցատկերը հաշվելը ոչ մեկին չի պատասխանում:

Առնչվող հոդվածներ