Tor Browser 11.0.2 Release and Expanded Blocking of Tor Sites

The release of the specialized browser Tor Browser 11.0.2 has been announced, focusing on anonymity, security, and privacy. When using Tor Browser, all traffic is routed exclusively through the Tor network, making it impossible to connect directly via the system’s standard network connection. This prevents tracking of the user’s real IP address (however, if the browser is compromised, attackers may gain access to system network settings, so for complete leak prevention, products like Whonix are recommended). Tor Browser builds are available for Linux, Windows, and macOS.

For additional protection, Tor Browser includes the HTTPS Everywhere extension, which enables traffic encryption on all sites where possible. To reduce the risk of attacks using JavaScript and to block plugins by default, the NoScript extension is included. Alternative transports are used to combat blocking and traffic inspection. To prevent fingerprinting, APIs such as WebGL, WebGL2, WebAudio, Social, SpeechSynthesis, Touch, AudioContext, HTMLMediaElement, Mediastream, Canvas, SharedWorker, WebAudio, Permissions, MediaDevices.enumerateDevices, and screen.orientation are disabled or restricted. Telemetry, Pocket, Reader View, HTTP Alternative-Services, MozTCPSocket, “link rel=preconnect,” and the libmdns library are also disabled or modified.

The new version is synchronized with the codebase of Firefox 91.4.0, which fixed 15 vulnerabilities, 10 of which were marked as critical. Seven of these were caused by memory handling issues, such as buffer overflows and use-after-free errors, potentially allowing attackers to execute code when opening specially crafted pages. Some TTF fonts have been removed from the Linux build, as their use caused text rendering issues in Fedora Linux interface elements. The “network.proxy.allow_bypass” setting, which controls protection against improper use of the Proxy API in extensions, has been disabled. For the obfs4 transport, a new default bridge “deusexmachina” is now used.

Ongoing Tor Blocking in Russia

The situation with Tor blocking in Russia continues. Roskomnadzor changed the domain mask in the registry of banned sites from “www.torproject.org” to “*.torproject.org” and expanded the list of IP addresses to be blocked. As a result, most Tor project subdomains, including blog.torproject.org, gettor.torproject.org, and support.torproject.org, have been blocked. The forum at forum.torproject.net, hosted on Discourse infrastructure, remains accessible. gitlab.torproject.org and lists.torproject.org are partially available; access was initially lost but later restored, likely after IP address changes (gitlab now points to gitlab-02.torproject.org).

At the same time, there have been no further reports of blocking Tor network bridges and nodes, or the host ajax.aspnetcdn.com (Microsoft CDN) used in the meek-azure transport. It appears that experiments with blocking Tor network nodes have ceased after the main Tor site was blocked. The situation with the mirror tor.eff.org is complicated, as it continues to operate. This mirror shares the same IP address as eff.org, the site of the Electronic Frontier Foundation (EFF), so blocking tor.eff.org would partially block the well-known human rights organization’s website.

Potential Attacks on Tor and the KAX17 Group

Additionally, a new report has been published about possible attempts to deanonymize Tor users, linked to the group KAX17, identified by specific fake contact emails in node parameters. In September and October, the Tor project blocked 570 potentially malicious nodes. At its peak, the KAX17 group managed to control up to 900 nodes in the Tor network, hosted by 50 different providers, which is about 14% of all relays (for comparison, in 2014 attackers managed to control nearly half of Tor relays, and in 2020, 23.95% of exit nodes).

Controlling a large number of nodes allows an operator to deanonymize users via a Sybil attack, which can occur if attackers control both the first and last nodes in the anonymization chain. The first node knows the user’s IP address, and the last node knows the IP address of the requested resource. This enables deanonymization by adding a hidden marker to packet headers at the entry node, which remains unchanged throughout the chain, and analyzing this marker at the exit node. If attackers control exit nodes, they can also modify unencrypted traffic, such as removing redirects to HTTPS versions of sites and intercepting unencrypted content.

According to Tor network representatives, most of the nodes removed in the fall were used only as middle relays, not for handling entry or exit traffic. Some researchers note that the nodes belonged to all categories, with a 16% chance of connecting to a KAX17-controlled entry node and a 5% chance for an exit node. Even so, the overall probability of a user simultaneously connecting to both entry and exit nodes controlled by the group (out of 900 KAX17 nodes) is estimated at 0.8%. There is no direct evidence that KAX17 nodes were used for attacks, but such attacks remain a potential risk.