A few days ago it was released via a Tor blog post, andl Launch of Tor 0.4.1.5 tools used to organize the work of the anonymous Tor network.
This new version of Tor 0.4.1.5 is recognized as the first stable version of the 0.4.1 branch, that has developed in the last four months. Branch 0.4.1 will be accompanied by a regular maintenance cycle: the release of updates will be suspended 9 months or 3 months after the release of branch 0.4.2 and in addition a long support cycle is provided (LTS) for branch 0.3.5, whose updates will be released until February 1, 2022.
For those who are still unaware of the Tor project (The Onion Router). This is a project whose main objective is the development of a communications network distributed, low latency and overlaid over the internet in which the routing of the messages exchanged between users does not reveal their identity, that is, its IP address (anonymity at the network level) and that, in addition, it maintains the integrity and secrecy of the information that travels through it.
The system is designed with the flexibility necessary so that it can implement improvements, be deployed in the real world and can withstand different types of attack. However, it has weak points and cannot be considered a foolproof system.
What's new in the new branch of Tor 0.4.1
With the release of this new stable branch, experimental support for incremental filling at the chain level was implemented, which allows to strengthen the protection against the methods to determine the Tor traffic.
Client now adds padding cells at the beginning of the INTRODUCE and RENDEZVOUS strings, making the traffic in these strings more like regular outbound traffic.
While enhanced protection is the addition of two additional cells in each direction for the RENDEZVOUS strings, as well as a main cell and 10 main cells for the INTRODUCE strings. The method fires when MiddleNodes is specified in the configuration and can be disabled using the CircuitPadding option.
Added support for authenticated SENDME cells to protect against a DoS attack based on a load when the client requests to download large files and stops read operations after sending requests, but continues to send SENDME control commands that instruct input nodes to continue transmitting data.
Each SENDME cell now includes a traffic hash, which confirms and the end node, upon receiving the SENDME cell, can verify that the other side has already received the traffic sent by processing the passed cells.
The framework includes the implementation of a generalized subsystem for sending messages in publisher-subscriber mode, which can be used to organize interaction within the module.
To analyze the control commands, a generalized analysis subsystem is used instead of a separate analysis of the input data for each command.
La performance optimization It has been done to reduce the load on the CPU. Tor now uses a fast pseudo-random number generator (PRNG) for each stream, which is based on the use of the AES-CTR encryption mode and the use of buffering constructs like in the library and the new OpenBSD arc4random () code.
De the other changes announced in this branch, we can find:
- For small outputs, the proposed generator is almost 100 times faster than OpenSSL 1.1.1's CSPRNG.
- Despite the fact that the new PRNG is evaluated by Tor developers as reliable crypto, so far it is only used in places that require high performance, for example in code to program the extra padding attachment.
- Added "–list-modules" option to display a list of included modules
- For the third version of the hidden services protocol, the HSFETCH command was implemented, which was previously only supported in the second version.
- Fixed bugs in Tor startup code (bootstrap) and operation of the third version of the hidden services protocol.
Source: https://blog.torproject.org/