Opened 22 months ago

Last modified 22 months ago

#23280 new enhancement

Censorship resistant onion sites

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal tor-hs censorship
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Currently HSDir and Introduction Point are in position to block a onion
site if they want. HSDirs just see the site's address in plaintext and
Introduction Point can check the site in HSDirs to find records related
to the site and remove such records from themselves.

So, if all hsdirs OR all Introduction Points want to block the site X,
they can.

prop224 makes onion site names less discoverable, but once discovered,
they can be removed in exactly the same way.

I believe that a system that is resistant to censoring certain sites
must satisfy the following condition: nobody except the client and the
site can distinguish activities related to the site. Not hsdirs, not
Introduction Points, literally nobody.

Here is my proposal of a protocol which seems to satisfy this condition.

Participants:

Operator -- A person running a hidden service

Host, "Server" -- The Tor software run by the operator to provide

a hidden service.

User -- A person contacting a hidden service.

Client -- The Tor software running on the User's computer

Pubsub Point -- A Tor node that accepts anonymous subscription

requests and anonymous publishing requests and translated
all data sent in publishing requests to all subscribers.

Rendezvous Point -- A Tor node to which clients and servers

connect and which relays traffic between them.

Data involved:

Onion site name - a public key for Asymmetric Encryption.


Access Token - one time secret used by between Client Host when

contacting Rendezvous Point. It is used by Rendezvous Point
to match a connection from Client with the corresponding
connection from Host.


Access Key - cryptographic key used by between Client Host when

contacting Rendezvous Point. It is needed to protect data passed
through Rendezvous Point by authenticated encryption.

What Pubsub Point

It has two "methods":

HOST - keep the connection open.
CLIENT - read a piece of data from the connection and send it to
all open HOST connections.

What Rendezvous Point does

It has two "methods":

CLIENT - read Access Token from the connection and keep it open.
HOST - read Access Token from the connection, lookup the CLIENT

connection with this Access Token and connect them.

Client-Host protocol

A hidden service is identified with a public key (not with a fingerprint
as now). A Client can encrypt a message with the public key. The
ciphertext can be decrypted only by the Host. All other parties can not
decrypt it and can't tell the Host (i.e. the public key) from the
ciphertext.

A shared random algorithm (similar to the existing one) is used to
derive a set of Tor nodes from a public key. These nodes are Pubsub
Points.

The Host establishes an anonymous connection to its Pubsub Points
and starts listening.

The Client generates random string to be Access Token.
The Client generates random string to be Access Key.
The Client chooses a random Tor node and connects to it as to
Rendezvous Point using the Access Token.

Then the Client makes tuple (Rendezvous Point pubkey, Access Token,
Access Key), encrypts it with the Host public key.

The Client connects to the Pubsub Points whose pubkeys are derived from
the Host pubkey (see above). The Client sends the ciphertext to the
Pubsub Points.

The Host reads all data from the Pubsub and tries to decrypt it.
If it succeeds, it connects to the Rendezvous Point specified in the
decrypted message with the Access Token specified in the decrypted
message. The Access Key specified in the decrypted message is used
by Host and Client to protect communications from the Rendezvous Point
with authenticated encryption.

The attack on the protocol to censor a particular onion site

The malicious Pubsub Points wants to block a particular onion site.
It makes a Client connection to the site, but sends the ciphertext only
to itself (not to other Pubsub Points) and the Pubsub Point sends it
to only one of the listeners. If the Client succeeds connecting the Host
the Pubsub makes a conclusion that the connection belongs to the Host
and stops sending ciphertexts to that connection.

A Host can protect itself from this kind of attack by opening a new
connection to Pubsub Points from time to time. Also it can open two
connections to the same Pubsub Point and compare results it gets from
them. If some ciphertext is missing in one of connections, it opens
one more connection and so on.

Child Tickets

Change History (4)

comment:1 Changed 22 months ago by cypherpunks

I have a better idea. Both user and server start BitMessage. A user sends a bitmessage message to the server. The server creates a new .onion address for a user and gives it to user. So there is no need to implement own BitMessage in tor.

comment:2 Changed 22 months ago by cypherpunks

The pros here are that you only need to implement the thing using stable BM interface. Tor will benefit from BM updates. Address-requesting messages are mixed with other general-purpose BM messages giving better anonymity.

comment:3 Changed 22 months ago by nickm

Keywords: needs-proposal tor-hs censorship added
Milestone: Tor: unspecified

comment:4 Changed 22 months ago by cypherpunks

I don't think that running BM is practical for that. It is too heavy. My proposed implementation is lighter. Also it is unlikely that BM will be shipped together with tor, so this option will only be used by a subset of users, reducing their anonymity. So I believe any solution of the problem should be a part of the official tor software.

To those who thing that there is no problem here and that the current implementation is censorship resistant: it is not! Many countries have laws powerful enough to block torrent trackers, who serve the same function for torrent protocol that hsdirs serve for tor hidden services protocol. The official reason for shutdown of torrent trackers: those trackers could block torrents with copyrighted content, but failed to do so. Anybody can send registered letters to all hsdir owners in the world informing them about a "bad" site and then try to shutdown all of them who didn't remove the site.

Also many countries have laws criminalizing situations when a person could prevent some other crime and was informed about it, but knowingly didn't do it. That is why it is so important to change the hidden sites protocol in such a way that no participant (including hsdirs) has a technical possibility to blacklist sites.

Note: See TracTickets for help on using tickets.