The release of the Tor 0.4.7.7 toolkit, used to organize the operation of the anonymous Tor network, has been presented. Tor version 0.4.7.7 is recognized as the first stable release of the 0.4.7 branch, which has been in development for the past ten months. The 0.4.7 branch will be maintained as part of the regular maintenance cycle - updates will be discontinued after 9 months or 3 months after the release of the 0.4.8.x branch.
Main changes in the new branch:
- Added implementation of the congestion control protocol (RTT Congestion Control), which regulates traffic through the Tor network (between the client and the exit node or onion service). The protocol aims to reduce the size of relay queues and overcome current throughput limitations. Until now, the speed of one download stream through output nodes and onion services was limited to 1 MB/sec, since the sending window has a fixed size of 1000 cells per stream and 512 bytes of data can be sent in each cell (flow rate with a chain delay of 0.5 sec = 1000*512/0.5 = ~1 MB/sec).
To predict the available throughput and determine the size of the packet queue, the new protocol uses Round Trip Time (RTT) estimation. The simulation showed that the use of the new protocol at exit nodes and onion services will lead to a reduction in queuing delays, removal of flow rate restrictions, increased performance of the Tor network and more optimal use of available bandwidth. Client-side flow control support will be offered on May 31st in the next major release of Tor Browser, built on the Tor 0.4.7 branch.
- Added simplified protection for Vanguards-lite against de-anonymization attacks on short-lived onion services, which reduces the risk of identifying guard nodes of an onion service or onion client in conditions when the service has been running for less than a month (for onion services running for more than a month, it is recommended to use vanguards addition). The essence of the method is that onion clients and services automatically select 4 long-running guard nodes (βlayer 2 guard relayβ) for use in the middle of the chain and these nodes are saved for a random time (on average a week).
- For directory servers, it is now possible to assign the MiddleOnly flag to relays using a new method for achieving consensus. The new method involves moving the logic for setting the MiddleOnly flag from the client level to the directory server side. For relays marked MiddleOnly, the Exit, Guard, HSDir and V2Dir flags are automatically cleared, and the BadExit flag is set.
Source: opennet.ru