DarkOwl has unprecedented coverage of data from prominent darknets including Tor (or The Onion Router), which is widely considered to be the most well-known and popular darknet. In order to maintain collecting content from darknets such as Tor, our engineers continually monitor technological changes and advances in hidden services networks. In doing so, we often have unique insight in to the shifting landscape of the dark web.

Tor project announces domain name scheme shift

Last summer, the Tor Project announced that in October it would be ending support for its legacy v2 domain naming scheme, and began encouraging darknet administrators to start migrating their hidden darknet websites – known as onion services – to the more secure v3 address scheme. For non-technical users of the Tor anonymous network, this seems inconsequential nor applicable to them, except Tor’s onion service addressing nomenclature – designated as v2 versus v3 – is the primary mechanism by which services hosted on the network are accessed.

Maintaining persistent access and knowledge of this darknet landscape is critical to provide continuous coverage of data from the dark web.

When the projected time of the cutover came in mid-October, Tor services were not immediately “shut off” and inaccessible as expected. Tor project removed v2 introduction points with Tor version 0.4.6, but the effects are only realized for relay operators that updated their node with the latest software version.

Within that month, Tor Project did update the Tor Browser to version 10.5.10 disabling v2 and rendering v2 onion services unavailable. However, DarkOwl discovered depreciated v2 onion services are still accessible with legacy browser client executables. Then, just this week, Tor Project released Tor Browser 11.0.1 which includes additional features like a blockchain explorer.

Now that v2 onion services are no longer supported by the Tor Project, DarkOwl estimates a decrease of 62% of known onion services across the Tor network.

In the last year, many onion services providers on Tor have published both a v2 and v3 address, which replicates their website content on both address types to ease the transition and “mirror” the content accordingly, thereby minimizing content loss. Read below for more details on the evolution of the different onion service address types and why v3 addresses are preferred.

How Many Tor v3 Onions Have Emerged?

DarkOwl maintains one of the largest databases of Tor darknet content, including historical and “deep” darknet records. DarkOwl’s crawlers monitor the Tor network for mentions of Tor onion services and schedules new v3 addresses discovered for crawling and indexes the content into its searchable Vision SaaS platform for its clients to access.

Due to the nature of the network and its privacy focused topology, it is impossible to quantify the real number of services operating on the network at any given time. V2 onion descriptor information is stored in plain text in the hidden service directory (HSDir) and at one time, provided some indication of the volume of services available, but such information is not available for v3 services.

In fact, according to Tor Project metrics, there could be upwards of 600,000 v3 onion services active in the network, but that number is extrapolated from relays operating as onion-service directories.

A recent technical blog on v3 onion services suggests many of the v3 services are “barely used” – or setup to merely act as slave services for a malicious botnet.

In the last six weeks, DarkOwl’s Vision platform has observed an average of 104,095 active .onion services across both address schemes of which: 62% are v2 addresses and 38% are v3 addresses.

These numbers are determined by a daily snapshot of DarkOwl’s collection stack seeded by DarkOwl’s network intelligence gleaned by crawling the network 24/7 since 2016. These numbers are not reflective of the true total number of onion services active in the network on any given day.

DarkOwl analysts also noted that during the month of July 2021, when the option to create new v2 onion services was removed from the codebase by Tor Project, DarkOwl Vision witnessed a surge in new v3 addresses and identified 2963 new v3 onions in the last two weeks of July alone.

Tor Users Respond

Most Tor onion service providers have embraced the network address deprecation and encouraged its visitors to add their new v3 address to their browser bookmarks.

Some darknet website administrators assumed the v2 onion services were inaccessible back in July and disabled all their v2 addresses when the Tor Project simply disabled the creation of new services in the 0.4.6. release last summer.

Other users are skeptical of the shift, especially those that firsthand experienced multiple concerted v3 onion service outages in January. All v3 onion services were offline for more than 3 hours at a time when the consensus health check failed, due to excessive traffic directed at the directory authorities – possibly due to uncontrolled DDoS between darknet markets.

According to the Tor Project, the implementation bug was fixed in the July 0.4.6 release to default to a “reasonably live” version of the consensus health when a “live” consensus is unavailable.

History of Tor & Decentralized Network Security

The original purpose of the “The Onion Router” (Tor) protocol was to provide US government intelligence operatives in the field secure communications without compromising their digital or physical location. In 1996, the first “0th generation” onion router (OR) was setup as an experiment in encrypted network topography in a virtual environment on a single computer. Because it included export-restricted technology, the “1st Generation” Tor was developed and successful in its mission of providing a concealed internet for the US government for several years. By the year 2000, the “1st generation” Tor had reportedly served upwards of 5 million network accesses a day. In 2003, the “2nd Generation” Tor came along with network improvements, hence where the term “onion v2” originates. DarkOwl Vision Users Can Read More in DocID – f4dafdd81bd9dac95d017a84d4c39d1c71f7dd5f

In 2006, when the US Naval Research Laboratories handed over Tor to a group of volunteers at the Tor Project, the network’s purpose was to provide a decentralized, censorship resistant platform for users to communicate and share information.

The Tor platform quickly became a haven for criminal activity, facilitating anonymous communication across underground digital communities and forums, elaborate drug marketplaces, child pornography and human trafficking. Consequently, deanonymizing onion services hosting criminal content has been a focus of many three-letter acronyms government and law-enforcement (LE) agencies around the world. Academic researchers and computer network science experts have received numerous grants and government funding to extensively study deanonymization attack methodologies and many journal publications exist.

Over the years, DarkOwl has witnessed successful deanonymization through various techniques including rendezvous point circuits (a.k.a. the cookie attack), time-correlation attacks, distributed denial of service attacks, which often force a criminal onion service to a LE-controlled guard node, (a.k.a. sniper attack), and circuit fingerprinting attacks.

Tor Project states that v3 onion service addressing is secure against enumeration attacks as well as other attacks that aren’t related to keys.

• An adversary who runs a relay on the Tor network can slowly learn a list of all the v2 onion services, via the v2 HSDir system.

• An adversary who can factor 1024-bit RSA keys can impersonate a v2 onion service.

• An adversary who can generate around 2^40 RSA keys can expect to generate two that correspond to the same onion address (a collision attack).

Earlier this year, German researchers published a TLS traffic analysis attack methodology, demonstrating 100% successful Tor onion service deanonymization in 12.5 days or less.

Tor v2 versus v3

Tor onion service addresses are intentionally not memorable, relying on a random string of non-mnemonic characters and numbers followed by the “.onion” top level domain (TLD). This string is automatically generated when the onion service is originally configured using a public key.

V3 onion service addresses are discernible by their lengthy 56-character address, e.g. Tor Project’s v3 address looks like: http://2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid[.]onion, where its v2 address is 16-characters: http://expyuzz4wqqyqhjn[.]onion.

The 16-character v2 address hashes represent an 80-bit number in base32 that contains the RSA public key of the onion service, where the v3 is 256-bit representation of its Elliptical Curve Cryptography (ECC) public key. Therefore, the onion service address is essentially a cryptographic representation of the originating domain’s information and a principal justification for network administrators encouraging exclusively using a more secure form of addressing.

The v3 address utilizes SHA3/ed25519/curve25519 cryptography which is considerably more secure than v2’s SHA1/DH/RSA1024 address encryption. The v2 addresses have been the standard for 15 years and the network overdue for a more secure mechanism to become standard.

The Tor Project announced it would be deprecating the v2 address format in July 2020 and outlined a specific timeline of the depreciation process, first removing the option to create new v2 onion services earlier this year and and releasing a new network client and browser in October that rendered v2 onion services inaccessible.

1. September 15th, 2020

0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6.

2. July 15th, 2021

0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.

3. October 15th, 2021

Release Tor client stable versions for all supported series that will disable v2 entirely.

Tor Development Continues and v2 [WARN]

In July, Tor Browser began displaying a “deprecated soon” warning message every time a v2 onion service was accessed. Since mid-October, instead of the warning page, the Tor Browser client logs records numerous [WARN] messages when the client accesses a legacy v2 onion service, despite displaying the website contents in the browser.

According to the developer’s comments on the Tor Project’s Github, eliminating v2 from the Tor network involves:

o   Modifying HSDir to stop accepting or serving v2 descriptors

o   Introduction points will stop allowing introductions for v2.

o   Refusing the TAP connection from the service side for rendezvous points.

These changes were scheduled to be released with version 0.3.5.x-final, but the actual release date of that update is unclear and no due date specified. Even though the introduction points no longer allow for v2 onion service address introductions, the effects of this will not actually be realized until every relay operator updates to the latest version of the Tor executable with these latest changes.

In early October, Tor Developer David Goulet edited Tor Project issue #40476 removing the 3rd bullet above stating:

“I decided to NOT remove the Rendezvous code path for TAP connections as it would create more complexity to the patch for which I'm trying to keep minimal.” - David Goulet, Tor Developer

Goulet merged the ticket with the disable SOCKS connections for v2 addresses in mid-October and closed the ticket.

Interestingly, in version tor-0.4.7.2-alpha, last modified less than a month ago, developer release notes focus on a new consensus method for v3 network congestion control and closes ticket #40476 by returning “bad hostname” for v2 onion service addresses.

Onion service v2 addresses are now not recognized anymore by tor meaning a bad hostname is returned when attempting to pass it on a SOCKS connection. No more deprecation log is emitted client side. Closes ticket 40476.

As of October 26th, Tor source code version 0.4.7.8 was available for download from the Tor Project and appears to incorporate all the changes mentioned above. One minor difference our analysts noted that the changelog states, “Send back the extended SOCKS error 0xF6 (Onion Service Invalid Address) for a v2 onion address” instead of “bad hostname.”

And v4 is already here

In 2019, rumors of a v4 onion service address emerged and many Tor onion service network administrators supposedly already mirror their content on v4 addresses.

The v4 onion services reportedly uses less CPU computational activity and subsequently less electricity to reduce e-pollution. There is allegedly also additional error handling, improved bootstrap reporting, and support for adaptive circuit padding to prevent time-based deanonymization attacks.

DarkOwl has not observed any v4 addresses in the network, nor has Tor Project released any documentation about v4 addresses for confirmation or analysis.

 Curious about something you’ve read? Contact us to learn how darknet data applies to your use case