Даўжэйшы ланцуг SOCKS не хавае наступны вузел аўтаматычна

Ланцуг змяняе, хто адкрывае кожнае злучэнне. Ён не дадае шыфравання проста таму, што ў спіс дададзены чарговы адрас SOCKS.

Разгледзім кліент, які будуе гэты ланцуг сам:

application → SOCKS A → SOCKS B → website

Спачатку ён просіць A злучыцца з B. Праз гэты паток ён потым можа дамовіцца з B пра злучэнне з сайтам. Калі транспарт ад кліента да A нясе абедзве дамоўленасці без шыфравання, дастаткова здольны назіральнік на гэтым звяне можа прачытаць байты наладкі, якія адправіў кліент. Знешні адрасат TCP — не адзінае магчымае сведчанне для назіральніка.

Аддзяляйце ланцуг ад абароненага абмену прыкладання

HTTPS можа абараніць змест прыкладання сайта пасля пачатку сеанса TLS. Ён не шыфруе заднім числам ранейшыя паведамленні наладкі SOCKS. Аўтэнтыфікацыя SOCKS5 па імені і паролі таксама не з'яўляецца шыфраваным транспартам.

Шыфраваная схема паміж кліентам і першым вузлом змяняе бачнасць на гэтым звяне. У яе ўсё яшчэ ёсць аператар і іншы канчатковы пункт, які трымае расшыфраваны паток. Апішыце гэтую мяжу даверу, а не сцвярджайце, што ланцуг немагчыма прасачыць.

Бацькоўскі маршрут, наладжаны на серверы, — іншая тапалогія. Калі A выбірае B унутры сябе, кліент не абавязкова адправіў поўны спіс пасярэднікаў праз сваё першае злучэнне. Не сцвярджайце, што кожны ланцуг раскрывае кожны вузел аднолькава.

Для карыснай ацэнкі прыватнасці назвіце назіральніка, звяно, дамоўленасць з проксі і межы TLS. Сайт, які назірае за выхадам B, і назіральнік сеткі доступу, які сочыць за першым злучэннем кліента, адказваюць на розныя пытанні. Просты падлік вузлоў не адказвае ні на адно з іх.