Opened 5 years ago

Closed 5 years ago

#16062 closed enhancement (duplicate)

Pseudonymous bidirectional user/caller authentication (true P2P)

Reported by: vynX Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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. 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.

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.

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.

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.

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.
– An API for hidden services to access the pseudonymous authentication data when provided.

Child Tickets

Change History (3)

comment:1 in reply to:  description ; Changed 5 years ago by ioerror

Replying to 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.

comment:2 in reply to:  1 Changed 5 years ago by yawning

Replying to ioerror:

(snip)

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.

The relevant tickets for this functionality would be #15588 and #16059. I'm tempted to not-a-bug this because the 2 tickets would cover everything in this ticket, but as usual, others are free to disagree with me.

comment:3 Changed 5 years ago by vynX

Resolution: duplicate
Status: newclosed

Thank you @ioerror for the exhaustive reply and @yawning for the apparently very pertinent tickets. So it looks like the featureset needed either already exists or is being coded in these very minutes. Thus I take my hat and close this ticket! Thank you for enlightening me some more!

Note: See TracTickets for help on using tickets.