The darknet and Tor hidden services have failed to achieve the massive success achieved by the surface web. In addition to a group of other reasons, one of the most important factors underpinning this failure, is the usability issues associated with the darknet. Due to these usability issues, in addition to latency, users find it relatively hard to access the darknet and Tor hidden services via the onion router.
The lack of readability and meaningfulness of an onion address represents the major usability challenge facing users when they attempt to access onion hidden services. As such, only a small percentage of Tor’s hidden services are accessed frequently, while the vast majority of these hidden services, which average nearly 45,000 per day, don’t receive any traffic. Due to the lack of incoming traffic, in addition to other reasons, a large number of onion hidden services get shut down as fast as they get launched.
Consequently, it is quite clear that an appropriate naming system has to be utilized by the onion router to minimize the shutdown of onion hidden services, that takes place due to the lack of incoming traffic. Mitigation of this usability issue is speculated to boost the rate of growth of onion hidden services, as well as their user base.
The Onion Name System OnionNS:
A recently published paper re-introduced the Onion Name System (OnionNS) concept as a solution to the usability issues associated with the domain names of onion hidden services. OnionNS was first described in 2015 as a privacy enhanced distributed DNS that enables operators of onion hidden services to select a “globally unique” domain name for their hidden service. OnionNS is formulated as an optional backward compatible Tor plug-in on top of the structure of existent onion hidden services.
However, implementation of OnionNS onto a Tor network can render a user or the onion hidden service more vulnerable to deanonymization attacks launched by an adversary. As such, it is quite obvious that sufficient countermeasures should be taken in order to minimize the risks of such forms of deanonymization attacks.
How can OnionNS be used with minimal vulnerabilities?
Authors of the paper proposed a solution to the vulnerabilities associated with the usage of OnionNS for annotating the domain names of onion hidden services. Following consideration of different data structures, the researchers proposed a novel B+ Hash Tree data structure in order to provide the exact same properties of a Merkle Tree data structure, that is used at the core of the OnionNS design and deployment.
Throughout the evaluation phase, they compared the novel data structure against the abstract deployment of a Merkle Tree in Python. This showed that B+ Hash Tree exhibited better performance than the Merkle Tree deployment when initializations and efficient insertions were to be considered.
Due to the fact that the Merkle Tree doesn’t support dynamic node insertions, every new insertion is taken up in the form of a new tree initialization and takes a longer duration to accommodate when compared with the B+ Hash Tree. The B+ Hash Tree, with its dynamical insertion capabilities, performs new node insertions in an effective manner. It is also obvious that deployment of the Merkle Tree takes up more space as it requires a minimum of two adjoined data structures to be able to perform the same set of operations performed by the B+ Hash Tree.
During the design phase, creation of several limited time windows to submit the ticket hash, within every 24 hour period, the resources invested by an attacker to monitor the network have to be increased by multiple folds. Within the same vein, if the attacker can submit the ticket hash within the last five minutes of each hour, they would need to raise their resource investment by 24 fold.
Nevertheless, by doing so, there is a chance to invent a different vulnerability to the system. The solution may enable domain squatters to acquire a larger number of domains during any given 24 hour period. At the best case, within a 24 hour period, with the existing system, a domain squatter could only acquire one domain. During a worse case scenario, depending on the threshold value of the proof of work, a domain squatter has the chance to acquire several more domains during a 24 hour period. Nonetheless, with the newly proposed deployment system, depending on the number of limited time windows established within a 24 hour period, the total number of hidden service domains a squatter can acquire, increases as the number of limited time windows rises. As such, although changing the time window of submission can effectively act as a deterrent for a passive adversary, it may create new loopholes to the OnioNS system. Domain squatters have the opportunity to perform minimalistic land rush attacks and acquire sufficient domain names, that can leave the OnioNS partially dysfunctional similar to Namecoin.
The bottom line:
The Onion Name System increases vulnerabilities to the Tor network, if deployed with the currently implemented settings. Nevertheless, altering the ticket hash submission interval can reduce a considerable number of possible vulnerabilities when the OpenNS is deployed. The change could be induced via deployment of a B+ Hash Tree data structure to replace the Merkle Tree data structure, in OnionNS implementation. As B+ Hash Tree data framework supports dynamic updates, the additional strain which could take place within the system with the additional domain registrations that has to be added with the new submission window, can be gracefully handled. Consequently, according to the results of this research, it could be safely stated that B+ Hash Trees represent an ideal candidate to replace Merkle Tree data structure when OnionNS is deployed onto the Tor Network.