Unify Tor2web network to improve preformance and stability - proposal

[whoami-burn]

Dear all,
I really appreciate your work and support about this project but i think that there are some lacks, i want to propose a new system that could improve performance and security.

The current system used by Tor2web has lacks that involve a low level of trust and performance:

1. No filtering of Hidden services

Tor2web allows the translation of any address that is not listed in the Blacklist, this involves the possibility of indexing by search engines of Hidden services that may not agree on the possibility of being translated and listed;
Moreover, the possibility of reaching any address can be harmful and dangerous due to the possibility of indexing illegitimate sites.
The Blacklist is not unique but single for each node/subdomain, this non-unanimity involves a substantial difference in the behavior of the entire network which, not being unanimous, in fact has no efficacy and control over the block of malicious or illegitimate activities.

2. Using of subdomains

The actual system involves the translation of Hidden services through non-centralized subdomains, anyone can create their own domain to use it and this condition involves excessive diversification without the possibility of control, filtering and low level of trust for each domain not being official.
This excessive diversification involves the duplication of Hidden services in the search engine indexing being recognized as different domains and the different behavior between various subdomains making it impossible to unify the network.

The solution that I propose for these lacks is a centralized DNS system which, similar to the Tor's Active directories for creating circuits, directs requests to the desired nodes; this system has several advantages as follows.

1. Filtering

A centralized DNS system for the network makes it possible to filter only the Hidden services inclined to participation and therefore to be indexed on the Clear Web, the need for a blacklist for a single node becomes unnecessary and this unification of the filtering creates a balance in translation management.

2. Performance

Through centralization of DNS requests, the load between different nodes can be balanced, and balancing also drastically reduces the possibility of using compromised nodes.
Through the current scheme if a subdomain is compromised (or created for this purpose), all traffic will be under the control of the attacker; although Tor2web is primarily a visibility service, not just a privacy service, but it is important to avoid compromised nodes that may involve traffic monitoring and data collection.

3. Encryption

Implementing SSL Encryption as proposed in #359 would improve security between client and node but with the actual diversification is impossible to test every node under every domain part of the tor2web network.
Like tor does (Bandwidth evaluation with Authority) evaluation is made to find evil or not stable node in the network; testing performance, stability and correct SSL implementation by the node could be possible with this unification.

The implementation of the proposed system takes place through the creation of a NS DNS record for each request to participate in the network as the owner of a Hidden services, the initial DNS record delegates via NS record the translation to the Tor2web server which will respond to the request with an available node for translation.

The participation of a new Hidden services in the network entails as a first step the creation of a unique Domain for that Hidden services and a DNS NS record which, upon arrival of a new DNS Request, will delegate the Tor2web server to perform DNS Response.

When Tor2web server recive a DNS Request will find a node on which to be able to address the request, after having obtained the node it will send a DNS Response to the Client; to better understand the system below an example of integration and request by a Hidden Service:

The Hidden services examplefortor.onion send a partecipation request to the network, the following records are then created:

• DNS NS Record on a public server of the applicant's choice that directs requests to the Tor2web server:

    dns.tor2web.org A 172.0.0.1                _# Entry A called also Glue record_
    example.com NS dns.tor2web.org        _# The domain to which the request is delegated_
  

• Record for Tor2web server

A record will be placed on the server to enable requests for the example.com domain and offer a available node from a database containing all the nodes currently connected and certified as stable.

Many other aspects of the proposed structure such as registration and stability monitoring, the load balancing method between nodes and the implementation of security must be reviewed.
I would be pleased to receive comments and evaluation of the proposal from the community to improve this project.

Useful links:

• PeerFlow
• An Empirical Evaluation of Relay Selection in Tor
• Index full of interesting publications by Tor project!
• TorFlow

[evilaliv3]

Thank you @whoami-burn !

@virgil / @fpietrosanti: What do you think?

I personally invited @whoami-burn to share his feedback as he was looking to the possibilities of contributin to the project and has many interesting ideas.

I've explained already why mainy of this topic impacts on the structure of the project itself that we have till now tried to implement completely decentralized eventually allowing some node federation, but discarding any form of centralization.