Rocksolid Light

Welcome to Rocksolid Light

register   nodelist   faq  


rocksolid / rocksolid.shared.tor / Re: Tor client authorization

SubjectAuthor
* Tor client authorizationRetro Guy
+* Re: Tor client authorizationtrw
|`- Re: Tor client authorizationRetro Guy
`* Re: Tor client authorizationtrw
 `* Re: Tor client authorizationRetro Guy
  `* Re: Tor client authorizationRetro Guy
   `- Re: Tor client authorization3483984398

Subject: Tor client authorization
From: Retro Guy@rslight.anon (Retro Guy)
Newsgroups: rocksolid.shared.tor
Organization: Rocksolid Light
Date: Tue, 25 Jun 2019 10:45 UTC
Currently doing some testing with tor v3 client authorization.

I have it working (which took a bit of research) and it looks like a reasonable way to manage peering over tor, but no where near as versatile and informative as i2p.

While we already do peer over tor, this step may make it easier and safer to manage.

More to come later in the week, when I have some time.

Retro Guy
--
Posted on Rocksolid Light



Subject: Re: Tor client authorization
From: trw@anon.com (trw)
Newsgroups: rocksolid.shared.tor
Organization: def5
Date: Thu, 27 Jun 2019 12:43 UTC

I have it working (which took a bit of research)

Can you elaborate a bit on the differences ? I would have expected that it works just like before...

cheers

trw Posted on def4


Subject: Re: Tor client authorization
From: retro_guy@retrobbs.rocksolidbbs.com (Retro Guy)
Newsgroups: rocksolid.shared.tor
Organization: novabbs
Date: Fri, 28 Jun 2019 00:20 UTC
On Thu, 27 Jun 2019 12:43:01+0000
trw <trw@anon.com> wrote:


I have it working (which took a bit of research)

Can you elaborate a bit on the differences ? I would have expected
that it works just like before...


This is for authorizing the tor client to connect (per client), as I do
with i2p. This way I can have a whitelist of clients to connect and no
other connections will succeed. This isn't the connection to inn2, it's
the tor connection itself.

I haven't been doing that with tor clients, just using another method
that I won't mention here to avoid unauthorized clients.

I still need to write up instructions on how to use it.

Retro Guy

--
Posted via novabbs




Subject: Re: Tor client authorization
From: trw@anon.com (trw)
Newsgroups: rocksolid.shared.tor
Organization: def5
Date: Fri, 28 Jun 2019 22:43 UTC

I haven't been doing that with tor clients, just using another method that I won't mention here to avoid unauthorized clients. I still need to write up instructions on how to use it.

Well post them when you are done. Such stuff is always interesting... Posted on def4


Subject: Re: Tor client authorization
From: retro_guy@retrobbs.rocksolidbbs.com (Retro Guy)
Newsgroups: rocksolid.shared.tor
Organization: novabbs
Date: Sat, 29 Jun 2019 04:47 UTC
On Fri, 28 Jun 2019 22:43:36+0000
trw <trw@anon.com> wrote:


I haven't been doing that with tor clients, just using another
method that I won't mention here to avoid unauthorized clients. I
still need to write up instructions on how to use it.

Well post them when you are done. Such stuff is always interesting...

Posted on def4

Matt Traudt has written nice instructions here:
https://matt.traudt.xyz/p/FgbdRTFr.html

Creating Private V3 Onion Services

Posted on 19 Jan 2019 by Matt Traudt
Last upated 08 Feb 2019 at 9:29 am
permalink

This post is about v3 onion services with 56 characters in their name.
For the old post for creating private v2 onion services, see here.

In that old post I talked about some of the great features of Tor onion
services. The features still apply with the new onion services: they
are still end-to-end encrypted, they still assure you that it is
impossible for anyone to modify your traffic, etc.

Regular v3 onions fix the issue that v2 onions had where a malicious
HSDir could snoop and learn about onion services that the owner
literally never advertised. This is great, you no longer have to make
your onion service regular authorization in order to avoid malicious
HSDirs. If you never tell anyone your v3 onion address, no one will
ever know it exists.

Regardless of whether you're okay with people knowing your v3 onion
address or not, what if you still wanted to require people to know a
secret key in order to be allowed to connect to your v3 onion service?
You can do that now.

Here's how you set this up.

    0. Know how to set up an onion service
    1. Generate a key for Alice
    2. Bob tells his Tor about the public key for Alice
    3. Alice tells her Tor about her private key
    4. Done

Alice is the client. Bob runs an onion service and wants to allow Alice
to connect to it. Everyone has Tor 0.3.5.7 or newer. 0. Know how to set
up an onion service

If you don't know how to set up a regular onion service, go figure that
out now. Don't come back until you can connect to it successfully.

Note that all the file and directory paths used her make sense for me,
but may not make sense for you on your computer. Only copy/paste things
intelligently.

I will assume the onion address is
y34f3abl2bou6subajlosasumupsli2oq7chfo3oqfqznuedqhzfr5yd.onion 1.
Generate a key for Alice

Someone needs to generate a key for Alice to use. I don't think it
really matters if Bob generates it for her instead. I will assume it is
Alice. I would like to see Tor produce something themselves (perhaps
inside little-t tor, perhaps a script shipped with its source code,
etc.) but for now you have to figure out how to do it yourself.

I wrote a simple python3 script to generate an x25519 key pair. It
requires PyNaCl.

Record the base32-encoded key pair somewhere. You'll need it soon.
Here's some example output.

public:  MEE25GRMPHS7NKNV3B7MHB6Y46FVGBALIC2OZUOD47CGYQMKQ56A
private: NQ2IJRNRZWPKVJNGWV7N6KJFUS235N27IP5NZ7UAXMXWUMILNLJA

2. Bob tells his Tor about the public key for Alice

Assume Bob already has this torrc snippet.

/etc/tor/torrc

HiddenServiceDir /var/lib/tor/foo_v3_onion/
HiddenServicePort 5248

He should have an authorized_clients directory inside foo_v3_onion/. If
it doesn't already exist, he should figure out what is wrong because
Tor should have made it for him.

Inside authorized_clients/, Bob should make a file ending in .auth; for
example, alice.auth. Inside that file, he should put the following
content.

descriptor:x25519:<base32-encoded-public-key>

Using an example public key ...

/var/lib/tor/foo_v3_onion/authorized_clients/alice.auth

descriptor:x25519:MEE25GRMPHS7NKNV3B7MHB6Y46FVGBALIC2OZUOD47CGYQMKQ56A

Bob should then restart his Tor.

If Bob wants to add more users, he can repeat this process with
additional files in this directory. 3. Alice tells her Tor about her
private key

First she should check that her torrc has a ClientOnionAuthDir option
set. These paths will be significantly different based on if she is
configuring her system's background Tor daemon or if she is configuring
Tor Browser. (T) means an example system Tor daemon path and (TB) means
an example Tor Browser path. Remember, yours may still be different.

(T) /etc/tor/torrc

ClientOnionAuthDir /var/lib/tor/onion_auth

(TB) [Tor Browser folder]/Browser/TorBrowser/Data/Tor/torrc

# In case this path ends up not making sense on your system ...
# The directory I'm aiming for onion_auth to be in is the same
# directory that contains the torrc
ClientOnionAuthDir TorBrowser/Data/Tor/onion_auth

After restarting Tor, if this directory doesn't exist, Alice should
make it with 0700 permissions.

Inside this directory, she then should add a file ending
in .auth_private; for example, bob.auth_private. Inside that file, she
should add the following content.

<onion-address>:descriptor:x25519:<base32-encoded-private-key>

Using an example onion address and private key ...

(T) /var/lib/tor/onion_auth/bob.auth_private

y34f3abl2bou6subajlosasumupsli2oq7chfo3oqfqznuedqhzfr5yd:descriptor:x25519:NQ2IJRNRZWPKVJNGWV7N6KJFUS235N27IP5NZ7UAXMXWUMILNLJA

(TB) [Tor Browser
folder]/Browser/TorBrowser/Data/Tor/onion_auth/bob.auth_private

y34f3abl2bou6subajlosasumupsli2oq7chfo3oqfqznuedqhzfr5yd:descriptor:x25519:NQ2IJRNRZWPKVJNGWV7N6KJFUS235N27IP5NZ7UAXMXWUMILNLJA

Alice should then restart her Tor.

If Alice needs keys for more onion addresses, she can repeat this
process with additional files in this directory.

Notes:

    The .onion suffix in the address is removed in those .auth_private
    files. I haven't actually tried this on Tor Browser, I'm merely
    relaying what a brave Redditor managed to figure out. Tor Browser
    doesn't expect you to edit its torrc, so if you change Tor settings
    graphically in Tor Browser, you may find it has generated a new
    torrc without your changes.

4. Done

If everyone's Tor processes are running without error, then setup
should be complete. Alice should be able to connect, but no one else
should be able to.

Bob can authorize up to about 350 clients per onion service.

--
Posted via novabbs




Subject: Re: Tor client authorization
From: retro_guy@retrobbs.rocksolidbbs.com (Retro Guy)
Newsgroups: rocksolid.shared.tor
Organization: novabbs
Date: Sat, 29 Jun 2019 04:50 UTC
Attachments: unnamed (application/x-shellscript)
Also, here (attached) is a bash script that will create the keys
necessary.

Retro Guy

--
Posted via novabbs




Attachments: unnamed (application/x-shellscript)
Subject: Re: Tor client authorization
From: 3483984398@anon.com (3483984398)
Newsgroups: rocksolid.shared.tor
Organization: def5
Date: Sun, 30 Jun 2019 09:20 UTC

thanks for posting this. it is pretty interesting, and sounds solid. another step of tor in the direction of i2p. me likes !

Posted on def4


1
rocksolid light 0.6.5e
clearnet i2p tor