[tor-bugs] #16062 [Tor]: Pseudonymous bidirectional user/caller authentication (true P2P)

[Tor Bug Tracker & Wiki]

#16062: Pseudonymous bidirectional user/caller authentication (true P2P)
-----------------------------+-----------------
     Reporter:  vynX         |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+-----------------

Comment (by ioerror):

 Replying to [ticket:16062 vynX]:
 > One big deal that differentiates Tor from all of the P2P networks is
 that Tor cannot easily be used for true peer-to-peer applications.

 How do you decide that? Every client can publish a globally (inside of
 Tor) reachable address, eg: foo.onion - anyone can thus reach that client,
 if they wish to use that address. Every client can choose their route
 through the network and connect to any .onion and any ipv4 or ipv6
 address.

 In what way is that not allowing for so-called "true peer-to-peer
 applications" exactly?

 > I assume the reason is there is no way to authenticate an incoming
 circuit other than by doing some XMPP-like dialback mumbo jumbo. This to
 me sounds like an unnecessary deficit.

 There is a way to do AAA for incoming connections - Please read the manual
 page:

        HiddenServiceAuthorizeClient auth-type client-name,client-name,...
            If configured, the hidden service is accessible for authorized
            clients only. The auth-type can either be 'basic' for a
            general-purpose authorization protocol or 'stealth' for a less
            scalable protocol that also hides service activity from
            unauthorized clients. Only clients that are listed here are
            authorized to access the hidden service. Valid client names are
 1
            to 16 characters long and only use characters in A-Za-z0-9+-_
 (no
            spaces). If this option is set, the hidden service is not
            accessible for clients without authorization any more.
 Generated
            authorization data can be found in the hostname file. Clients
 need
            to put this authorization data in their configuration file
 using
            HidServAuth.

 That is exactly a way to ensure that a connection is from a specific user.
 It won't matter which circuit is used at all - rather the specific streams
 will all be tied to the user. I'm not sure how you'd get that it was alice
 vs bob (assuming both have an auth token) - I think you can get that from
 the control port but I'm not sure. You may be able to do something cool
 with UnixSockets for example but I think no one has done that as of yet.

 >
 > It should be an option for Tor users or applications to store the key
 used in end-to-end communications with a hidden service such that they can
 pseudonymously reappear as the same entity when reconnecting at a later
 time.

 That is a higher application level thing in my view if the auth token
 above doesn't work for your use. That is - your HTTPS server behind a Tor
 Hidden Service can use client certificates or some other application level
 thing. There is no reason a client can't generate a keypair and use it for
 each request (assuming an http like protocol, for example).

 Or I guess something like this might work with a Tor Hidden Service out of
 the box: https://sipb.mit.edu/doc/apache-client-certs/

 >
 > They could also have the ability to use the identity of their own hidden
 service in outgoing calls, making it thus trivial for any receiver to call
 back.

 So in this case, you've designed some application that runs on top of a
 Tor Hidden Services and sure, it would be possible for clients to have a
 .onion, for servers to connect to that .onion and for servers to issue a
 per client .onion too. There is some care that needs to be taken here or
 you will be generating a lot of connections or generating a lot of
 .onions...

 It could be that a user generates a certificate, includes their own .onion
 in the cert and perhaps even an auth token to be passed to Tor, for
 example.

 >
 > Use cases are not only all sorts of P2P applications such as Tor-based
 instant messengers, chat and social networking systems, but even the mere
 manageability of users on forum-like hidden websites. Instead of forcing
 visitors to go through the terrible procedures of name registration,
 captcha compliance and password storage, they could simply be identified
 by their pseudonymous identity and possibly gain privileges on the site by
 time spent or other interaction criteria. In other words, pseudonymous
 authentication would play out systemic strengths of Tor's public-key-based
 routing in a way that makes websites more pleasurable to use than with the
 regular Internet.

 If I understand your idea for an application design, I don't think
 anything needs to change inside of Tor except that a given authorized user
 needs to have a hint attached to a socket (tcp or unix). I may not fully
 understand it though...

 >
 > From my humble understanding of the Tor architecture, only two changes
 are needed:
 > – An API for apps and users to classify the interaction with certain
 onions as pseudonymous rather than anonymous.

 If you want that - you can give a client an authorized hidden service -
 the .onion and the token are unique per user. In addition, you can use the
 stealth (rather than basic) mode for a higher level of security (at a
 cost).

 > – An API for hidden services to access the pseudonymous authentication
 data when provided.

 You can use SETCONF to generate hidden services on the fly. I believe you
 can use that to generate hidden services that require authentication.
 Either way, the higher level application needs to talk to the Tor
 Controller, I think. I believe that the Tor Controller will tell you that
 you have an incoming connection from user alice and then you can patch
 that data to your higher level application.

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