Довший ланцюг SOCKS не приховує наступний вузол автоматично

Ланцюг змінює того, хто відкриває кожне з'єднання. Він не додає шифрування лише тому, що до списку додано ще одну адресу SOCKS.

Розглянемо клієнт, який сам будує цей ланцюг:

application → SOCKS A → SOCKS B → website

Спершу він просить A з'єднатися з B. Через цей потік він потім може домовитися з B про з'єднання із сайтом. Якщо транспорт від клієнта до A несе обидві домовленості без шифрування, достатньо здатний спостерігач на цій ланці може прочитати байти налаштування, які надіслав клієнт. Зовнішній адресат TCP — не єдиний можливий доказ спостерігача.

Відокремлюйте ланцюг від захищеного обміну застосунку

HTTPS може захистити вміст застосунку сайту після початку сеансу TLS. Він не шифрує заднім числом раніші повідомлення налаштування SOCKS. Автентифікація SOCKS5 за іменем користувача й паролем теж не є шифрованим транспортом.

Зашифрована схема між клієнтом і першим вузлом змінює видимість на цій ланці. У неї все ще є оператор та інша кінцева точка, що тримає розшифрований потік. Опишіть цю межу довіри, а не стверджуйте, що ланцюг неможливо відстежити.

Батьківський маршрут, налаштований на сервері, — інша топологія. Якщо A вибирає B усередині, клієнт не обов'язково надіслав повний список посередників через своє перше з'єднання. Не стверджуйте, що кожен ланцюг розкриває кожен вузол однаково.

Для корисної оцінки приватності назвіть спостерігача, ланку, домовленість із проксі та межі TLS. Сайт, який спостерігає за виходом B, і спостерігач мережі доступу, який стежить за першим з'єднанням клієнта, відповідають на різні питання. Сам лише підрахунок вузлів не відповідає ні на одне з них.