Recently the release of the new stable version of Tor 0.4.4.5 was presented, used to organize the work of the anonymous Tor network. Tor 0.4.4.5 it is considered the first stable version of branch 0.4.4, that has evolved over the last five months.
Branch 0.4.4 will be kept as part of the regular maintenance cycle; the release of updates will be discontinued after 9 months (in June 2021) or 3 months after the release of the 0.4.5.x branch.
In addition, a long support cycle (LTS) is also provided for the 0.3.5 branch, the updates of which will be released until February 1, 2022. The support for the 0.4.0.x, 0.2.9.x and 0.4.2 branches. 0.4.1.x has been discontinued. Support for the 20.x branch will be broken on May 0.4.3 and 15 on February 2021, XNUMX.
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.
Main new features of Tor 0.4.4.5
This new version of Tor comes with quite a few changes and fixes, of them we highlight the most important such as improved sentinel node selection algorithm, in which the problem with load balancing, as well as improved productivity and security.
Another major change, is that the ability to load balance the onion services was implemented. Since a service based on the third version of the protocol can now act as the backend for OnionBalance, which is configured using the HiddenServiceOnionBalanceInstance option.
It is also highlighted that the list of spare directory servers has been updated, which has not been updated since last year, and 105 of the 148 servers remain operational (the new list includes 144 entries generated in July).
In relays, it is allowed to work with EXTEND2 cells that are available only on the IPv6 address, and chain expansion over IPv6 is also allowed if the client and the relay support IPv6.
If, by expanding the chains of nodes, a cell can be accessed simultaneously via IPv4 and IPv6, then the IPv4 or IPv6 address is chosen at random. The existing IPv6 connection can extend the chain. The use of internal IPv4 and IPv6 addresses is prohibited.
Also expanded the amount of code that can be disabled when starting Tor without relay support.
On the other hand, also the correct handling of parameters for the DoS defense of the onion service is mentioned. Well, previously, the consensus parameters for the service's DoS defenses would overwrite the parameters set by the service operator through HiddenServiceEnableIntroDoSDefense.
Another important bug fix is the bug that was underestimating the total traffic from the Tor network onion service, ignoring any traffic originating from clients.
Besides that channels using outdated versions of the Tor handshake can no longer bypass checks canonicity of addresses. (This is just a minor issue, as such channels have no way to configure ed25519 keys and therefore should always be rejected for circuits that specify ed25519 identities.)
Of the other changes that stand out:
- The authorities now recommend protocol versions that are compatible with Tor 0.3.5 and later.
- Reset support for GUARD NEW / UP / DOWN control port events.
- Add IPv6 support to tor_addr_is_valid ().
- Add tests for the above changes and tor_addr_is_null ().
- Allow clients and relays to send IPv2-only, dual-stack EXTEND6 cells.
- Allow Tor to build on platforms where it doesn't know how to report which syscall caused the Linux seccomp2 sandbox crash.
- Allow the unlinkat () system call, which some Libc implementations use to implement unlink ().
- Added 3 new SocksPort ExtendedErrors (F2, F3, F7) reporting a new type of service connection failures.
Finally, if you want to know more about it, you can check the details in the following link