По-дългата верига SOCKS не скрива автоматично следващия възел
Разпознайте нешифрованите съобщения за настройка във верига SOCKS, изградена от клиента, преди да приемете, че още един възел скрива метаданните за местоназначението.
Веригата променя кой отваря всяка връзка. Тя не добавя шифроване просто защото в списък е добавен още един адрес SOCKS.
Представете си клиент, който сам изгражда тази верига:
application → SOCKS A → SOCKS B → website
Първо той иска от A да се свърже с B. През този поток после може да договори с B връзка към сайта. Ако транспортът от клиента до A носи двете договорки без шифроване, достатъчно способен наблюдател на тази връзка може да прочете байтовете за настройка, които клиентът е изпратил. Външната TCP дестинация не е единственото възможно доказателство за наблюдателя.
Отделете веригата от защитения обмен на приложението
HTTPS може да защити съдържанието на приложението на сайта, след като сесията TLS започне. Той не шифрова обратно по време по-ранните съобщения за настройка на SOCKS. И удостоверяването на SOCKS5 с потребителско име и парола не е шифрован транспорт.
Шифрованата подредба между клиента и първия възел променя видимостта на тази връзка. Тя все още има оператор и друга крайна точка, която държи дешифрирания поток. Опишете тази граница на доверие, вместо да твърдите, че веригата е невъзможна за проследяване.
Родителският маршрут, зададен на сървъра, е друга топология. Ако A избира B вътрешно, клиентът не е задължително да е изпратил пълен списък от посредници по първата си връзка. Не твърдете, че всяка верига разкрива всеки възел по един и същ начин.
За полезна оценка на поверителността назовете наблюдателя, връзката, договарянето с проксито и границите на TLS. Сайтът, който наблюдава изхода на B, и наблюдателят на мрежата за достъп, който гледа първата връзка на клиента, отговарят на различни въпроси. Самото броене на възли не отговаря на нито един от тях.