Вимагати, щоб кожен користувач Tor був ретранслятором, допомогло б масштабувати мережу для роботи з усіма нашими користувачами, а запуск ретранслятора Tor може допомогти вашій анонімності.
Однак багато користувачів Tor не можуть бути хорошими ретрансляторами — наприклад, деякі клієнти Tor працюють через обмежені брандмауери, підключаються через модем або іншим чином не в змозі ретранслювати трафік.
Надання послуг цим клієнтам є важливою частиною забезпечення ефективної анонімності для всіх, оскільки багато користувачів Tor підпадають під такі чи подібні обмеження, і включення цих клієнтів збільшує анонімність.
Однак, ми хочемо заохочувати користувачів Tor запускати ретранслятори, тому ми дійсно бажаємо спростити процес налаштування та підтримки ретранслятора.
За останні кілька років ми досягли значного прогресу завдяки простому налаштуванню: Tor добре вміє автоматично визначати, чи доступний він і яку пропускну здатність він може запропонувати.
Є чотири кроки, які ми повинні виконати, перш ніж ми зможемо це зробити:
По-перше, нам все ще потрібно покращити автоматичну оцінку потрібної пропускної здатності.
Можливо, перемикання на транспорт UDP є найпростішою відповіддю, яка, насправді, зовсім не проста.
По-друге, нам потрібно попрацювати над масштабуванням як мережі (як припинити вимагати, щоб усі ретранслятори Tor могли підключатися до всіх ретранслятор Tor), так і каталогу (як припинити вимагати, щоб усі користувачі Tor знали про всі ретранслятори Tor).
Такі зміни можуть мати великий вплив на потенційну та реальну анонімність.
Дивіться Розділ Виклики для детальної інформації.
Знову ж таки, тут допоможе передача UDP.
По-третє, ми повинні краще розуміти ризики, які можуть призвести до того, що зловмисник зможе передавати трафік через ваш ретранслятор, і водночас ви надсилаєте власний анонімний трафік.
Три різні дослідження описують способи ідентифікації ретранслятора в схемі, пропускаючи трафік через ретранслятор-кандидат і шукаючи провалів трафіку, поки схема активна.
Ці атаки, що засмічують, не такі страшні в контексті Tor доти, поки вузли не є клієнтами.
Але якщо ми намагаємося заохотити більше клієнтів увімкнути функціональні можливості ретранслятора (такі як мостовий ретранслятор або як звичайні ретранслятори), нам потрібно краще зрозуміти цю загрозу і дізнатися як її пом’якшити.
По-четверте, нам може знадобитися якась схема стимулювання, щоб спонукати людей ретранслювати трафік іншим та / або стати вихідними вузлами.
Ось наші поточні думки щодо стимулів Tor.
Будь ласка, допоможіть у всьому цьому!
Було б непогано дозволити операторам ретрансляторів говорити такі речі, як відхилити reject www.slashdot.org у своїх політиках виходу, а не вимагати від них дізнатися весь простір IP-адрес, який може бути охоплений сайтом (а потім також блокувати інші сайти за цією IP-адресою).
Але є дві проблеми.
По-перше, користувачі все ще можуть обійти ці блоки.
Наприклад, вони можуть запитувати IP-адресу, а не ім’я хоста, коли вони виходять з мережі Tor.
Це означає, що операторам все одно потрібно буде дізнатися всі IP-адреси для відповідних місць призначення.
Друга проблема полягає в тому, що це дозволить віддаленим зловмисникам цензурувати довільні сайти.
Наприклад, якщо оператор Tor блокує www1.slashdot.org, а потім якийсь зловмисник отруює DNS вузла Tor або іншим чином змінює це ім’я хосту на IP-адресу головного сайту новин, то може статися що вузол Tor блокує сайт новин.
Ні, ви не можете довіряти мережі вибирати шлях.
Шкідливі ретранслятори можуть направити вас через своїх друзів, які в змові.
Це дасть супротивнику можливість спостерігати за вашим трафіком від початку до кінця.
Це було б зручно з кількох причин:
Це дозволить Tor краще працювати з новими протоколами, такими як VoIP.
Це могло б вирішити всю потребу в синхронізації сокетів застосунків.
Ретрансляторам виходу також не потрібно буде виділяти багато дескрипторів файлів для всіх вихідних підключень.
Ми рухаємося в цьому напрямку. Деякі зі складних проблем:
IP-пакети розкривають характеристики ОС.
Нам все одно потрібно буде виконати нормалізацію пакетів на рівні IP, щоб зупинити такі речі як атаки з використанням відбитків TCP.
Враховуючи різноманітність і складність стеків TCP, а також атаки з використанням цифрових відбитків на пристроях, схоже, що найкращий вибір — це постачання власного стека TCP для користувацького простору.
Потоки на рівні програми все ще потребують очищення.
Нам все одно знадобляться програми на стороні користувача, такі як Torbutton.
Тому це не стане лише питанням захоплення пакетів та їх анонімізації на рівні IP.
Деякі протоколи все одно мають витік інформації.
Наприклад, ми повинні переписати запити DNS, щоб вони доставлялися на не зв'язаний DNS-сервер, а не на DNS-сервер у постачальника послуг інтернету користувачу; таким чином, ми повинні розуміти протоколи, які ми транспортуємо.
DTLS (Датаграма TLS) здебільшого не має користувачів, а IPsec безсумнівно великий.
Після того, як ми виберемо механізм транспортування, нам потрібно розробити новий наскрізний протокол Tor, щоб уникнути атак за типом привласнення міток та інших потенційних проблем з анонімністю та цілісністю оскільки відтепер ми дозволяємо скидання, повторне надсилання тощо.
Політика виходу для довільних IP-пакетів означає створення захищеної системи виявлення вторгнень (СВВ).
Наші оператори вузлів кажуть нам, що політики вихідного трафіку є однією з головних причин, чому вони хочуть запустити Tor.
Додавання СВВ для обробки політик виходу підвищить складність безпеки Tor і, швидше за все, не спрацює, про що свідчить увесь масив документів про СВВ та протидію СВВ.
Багато потенційних проблем зловживання усуваються завдяки тому, що Tor транспортує лише дійсні потоки TCP (на відміну від довільного IP, включаючи неправильно сформовані пакети та IP-флуд.)
Політики виходу стають ще важливішими, оскільки ми отримуємо можливість транспортувати IP-пакети.
Нам також потрібно стисло описати політики виходу в каталозі Tor, щоб клієнти могли передбачити, які вузли дозволять вихід їхнім пакетам.
Клієнти також мають передбачити всі пакети, які вони хочуть надіслати під час сеансу, перш ніж вибрати свій вихідний вузол!
Внутрішній простір імен Tor потрібно буде переробити.
Ми підтримуємо адреси сервісу «.onion», перехоплюючи їх, коли вони передаються клієнту Tor.
Для цього на рівні IP буде потрібний складніший інтерфейс між Tor і локальним DNS інтерпретатором.
