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