Federated multi-domain/multi-server support

[fpietrosanti]

In order to increase resiliency of Tor2web, it would be required to have different persons running different tor2web networks over different domains names.

To be researched and defined on a consensus basis which would be the best way to implement distributed tor2web network.

Uniquely random Access is described on #33
Torweb Directory #41

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/14807288-federated-multi-domain-multi-server-support?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github).

[fpietrosanti]

This feature require documentation / definition of a broader schema to transform tor2web from standalone server to distributed network.

[fpietrosanti]

First idea coming from 2011:

Here are the notes of the discussion on tor2web, they are a bit
confused, they need some cleaning up, but here it goes:

Let there be two Tor2web nodes, call them Node A and Node B.

The main goals of the new tor2web design is:

* Distribute responsibility across multiple actors
* Minimize the probability of takedown of a tor2web node

The scenarios that we are hoping to solve are:

1) A spammer sends a message containing a tor2web link. When the link is
clicked, the user is presented with the malicious page. This web page is
hosted as a hidden service, so the cost of setting up a new website is
very low (blocklisting is not feasable).
The ISP receives a notification that the link is associated with illegal
content, he visits the page and verifies immediately that the content is
there and that it is under his address space. The node gets shut down.

2) Somebody is hosting illegal content on a hidden service. He is able
to spread this link and the content is served immediately. This means
that authorities are able to verify immediately that the content is in
fact there and may not be able to immediately understand that it is
served from the Tor network.

Solution:
Node A does directly serve the content, but functions only as a landing
page to the actual content.
Node B serves the real content and is able to verify that the link to
it's site has been used only once and it has been verified by the user
requesting it.

The onion address the user wishes to visit is:
http://1234567890abcdef.onion/
The tor2web link he receives is: http://1234567890abcdef.tor2web.org/

The user visits the tor2web link. This link connects him to the landing
page on Node A. This page contains a disclaimer warning him that the
content being served by Node B is not being hosted on Node B, but it is
directly fetched from the Tor Hidden Service network. The user is also
discouraged from connecting to HS from tor2web because he is disclosing
his identity to the tor2web Nodes A and B.

The user then either clicks on a checkbox stating he has taken note of
the agreements or the link to Node B is served directly. This link
contains an encoded string that has various properties.

1) It can only be clicked on once
So a direct link to Node B cannot be distributed to multiple parties
2) It can only be clicked on by the user who generated it
So a malicious user cannot generate various links to Node B and then
distribute them to their target users (this makes sense if malory is a
spammer)
3) It can only be generated by a Node A type t2w node
So that there is not a way to craft a link to a Node B t2web node binded
to a specific user, without being a Node A t2web node.
4) It contains the address of the HS
So the tor2web node B will be able to determine the address of the HS

One solution could be to have the nonce generated by the Hidden Service.

== Cookie option
Node A writes a cookie to the user containing H(nonce + timestamp +
ip_address_of_user + onion_address)
Where H() is a one way hash function.

Node A then contacts Node B informing him of the address of the onion
URL that the client requested and the nonce that was provided to the user.

Node A displays in text the address of Node B, the user is required to
copy and paste this link into his browser. Once he connects to Node B,
his cookies are inspected and from their content Node B is able to
determine if the the connection is legitimate and valid.

Node B serves up content to the client.

== URL option
To achieve this the address to Node B is build in the following way:

/1234567890abcdef.onion/nonce + H(nonce + timestamp + ip_address_of_user
+ onion_address)

Where H() is a one way hash function, and the nonce is generated by Node
A and distributed to a centralized server.

Node B receives this and is able to verify if it is a valid request, by
looking up the nonce corresponding to the current timestamp


== Alternative solution

Node B type nodes have a sort of cache descriptor that list the onion
address that can be reached through them. It is sort of like a
ExitPolicy where you can specify either blacklist of whitelists.

The descriptor should contain the hash of the hash of the blocklisted
.onion, this is to avoid disclosing the list of blocked .onion's directly.

Node A contacts the directory service and checks which Node B's are able
to serve the target .onion. He requests the .onion directly and the
directory service responds with a list of the ones that are able to
provide that HS. Node A then generates a link with one of these type B
nodes at random.


A.