[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #16062 [Tor]: Pseudonymous bidirectional user/caller authentication (true P2P)
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs