Выпуск новой стабильной ветки 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.
Источник: http://www.opennet.ru/opennews/art.shtml? num=57143
© OpenNet
