Випуск нової стабільної гілки Tor 0.4.7

Наведено випуск інструментарію Tor 0.4.7.7, що використовується для організації роботи анонімної мережі Tor. Версія Tor 0.4.7.7 визнана першим стабільним випуском гілки 0.4.7, що розвивалася останні десять місяців. Гілка 0.4.7 супроводжуватиметься в рамках штатного циклу супроводу – випуск оновлень буде припинено через 9 місяців або через 3 місяці після релізу гілки 0.4.8.x.

Основні зміни у новій гілці:

  • Додана реалізація протоколу управління навантаженням (RTT Congestion Control), що регулює трафік через мережу Tor (між клієнтом та вихідним вузлом або onion-сервісом). Протокол націлений зменшення розміру черг на релеях і подолання поточних обмежень пропускної спроможності. Досі швидкість одного потоку завантаження через вихідні вузли і onion-сервіси упиралася в 1 MB/sec, оскільки вікно відправки має фіксований розмір 1000 осередків на потік і в кожному осередку можна відправити 512 байт даних (швидкість потоку при затримці в ланцюжку 0.5 сек = 1000 * 512/0.5 = ~ 1 МБ / sec).

    Для прогнозування наявної пропускної спроможності та визначення розміру черги пакетів у новому протоколі використовується оцінка часу приймання-передачі (RTT, Round Trip Time). Проведене моделювання показало, що застосування нового протоколу на вихідних вузлах та onion-сервісах призведе до зниження затримок перебування в черзі, зняття обмежень на швидкість потоку, збільшення продуктивності мережі Tor та більш оптимального використання наявної пропускної спроможності. На стороні клієнта підтримка управління потоком буде запропонована 31 травня у наступному значному випуску Tor Browser, побудованому на гілці Tor 0.4.7.

  • Додано спрощений захист Vanguards-lite від проведення атак з деанонімізації короткоживучих onion-сервісів, що знижує ризик визначення сторожових вузлів (guard) onion-сервісу або onion-клієнта, в умовах коли сервіс працює менше місяця (для onion-сервісів, що працюють більше місяця, рекомендується використовувати доповнення vanguards). Суть методу в тому, що onion-клієнти та сервіси автоматично вибирають 4 сторожові вузли («layer 2 guard relay») для використання в середині ланцюжка і дані вузли зберігаються випадковий час (в середньому тиждень).
  • Для серверів директорій реалізовано можливість призначення релеям прапора MiddleOnly з використанням нового методу досягнення консенсусу. Новий метод має на увазі винесення логіки виставлення прапора MiddleOnly з рівня клієнта на бік серверів директорій. Для помічених релеїв MiddleOnly автоматично знімаються прапори Exit, Guard, HSDir і V2Dir, і виставляється прапор BadExit.

Джерело: opennet.ru

Додати коментар або відгук