Дужи SOCKS ланац не скрива следећи скок аутоматски

Ланац мења ко отвара сваку везу. Не додаје шифровање само зато што је на листу додата још једна SOCKS адреса.

Замислите клијента који сам гради овај ланац:

application → SOCKS A → SOCKS B → website

Најпре тражи од A да се повеже са B. Кроз тај ток затим може да преговара са B о вези са сајтом. Ако пренос од клијента до A носи оба преговора без шифровања, довољно способан посматрач на тој вези може да прочита бајтове подешавања које је клијент послао. Спољно TCP одредиште није једини могући посматрачев доказ.

Одвојите ланац од заштићене размене апликације

HTTPS може да заштити апликациони садржај сајта након почетка TLS сесије. Не шифрује уназад претходне SOCKS поруке подешавања. Ни провера идентитета корисничким именом и лозинком у SOCKS5 није шифровани пренос.

Шифровани распоред између клијента и првог скока мења видљивост на тој вези. И даље има оператера и другу крајњу тачку која држи дешифровани ток. Опишите ту границу поверења уместо да тврдите да се ланац не може пратити.

Надређена рута коју је конфигурисао сервер друга је топологија. Ако A изнутра бира B, клијент није нужно послао потпуну листу посредника својом првом везом. Не тврдите да сваки ланац открива сваки скок на исти начин.

За корисну процену приватности наведите посматрача, везу, преговор са проксијем и границе TLS-а. Сајт који посматра B-ов излаз и посматрач приступне мреже који гледа прву клијентову везу одговарају на различита питања. Само бројање скокова не одговара ни на једно.