Представлен выпуск инструментария 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.