Выпуск новой стабильной ветки 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.

Основные изменения в новой ветке:

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

    Для прогнозирования имеющейся пропускной способности в новом протоколе используется оценка времени приема-передачи (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.
Release. Ссылка here.