[tor-bugs] #23280 [Core Tor/Tor]: Censorship resistant onion sites

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Aug 19 19:39:31 UTC 2017


#23280: Censorship resistant onion sites
------------------------------+--------------------
     Reporter:  cypherpunks   |      Owner:  (none)
         Type:  enhancement   |     Status:  new
     Priority:  Medium        |  Milestone:
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+--------------------
 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23280>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list