The release of Tor 0.4.7.7 toolset has been announced, used for organizing the operation of the anonymous Tor network. The Tor 0.4.7.7 version is recognized as the first stable release of the 0.4.7 branch, which has developed over the past ten months. The 0.4.7 branch will be supported as part of the standard maintenance cycle — update releases will be discontinued in nine months or three months after the release of the 0.4.8.x branch.
Key changes in the new branch:
- The implementation of the Round Trip Time (RTT) Congestion Control protocol has been added, regulating traffic through the Tor network (between the client and the exit node or onion service). The protocol aims to reduce the size of queues at relays and overcome current bandwidth limitations. Until now, the speed of a single upload stream through exit nodes and onion services was capped at 1 MB/sec, as the sending window has a fixed size of 1000 cells per stream, and in each cell, up to 512 bytes of data can be sent (stream speed with 0.5 sec latency in the chain = 1000*512/0.5 = ~1 MB/sec).
To forecast the available bandwidth and determine packet queue size, the new protocol uses Round Trip Time (RTT) estimation. Simulations have shown that the implementation of the new protocol at exit nodes and onion services will lead to reduced queuing delays, the removal of flow speed limits, increased Tor network performance, and more optimal use of available bandwidth. On the client side, flow control support will be offered on May 31 in the next major release of Tor Browser, built on the Tor 0.4.7 branch.
- A simplified Vanguards-lite protection against de-anonymization attacks for short-lived onion services has been added, which reduces the risk of identifying the guard nodes of an onion service or onion client when the service operates for less than a month (for onion services running longer than a month, the vanguards add-on is recommended). The essence of the method is that onion clients and services automatically select 4 long-lived guard nodes ("layer 2 guard relay") to use in the middle of the chain, and these nodes are kept for a random period (on average a week).
- For servers The directory has implemented the ability to assign the MiddleOnly flag to relays using a new consensus method. This new method involves moving the logic for setting the MiddleOnly flag from the client side to the directory servers. For relays tagged as MiddleOnly, the Exit, Guard, HSDir, and V2Dir flags are automatically removed, and the BadExit flag is set.
Source: opennet.ru
