Onion Services Authentication

Patrick · April 4, 2015, 4:14pm

~~How to use Hidden Service Authentication? - Tor Stack Exchange~~

summertanks · August 5, 2018, 12:37pm

@Patrick - any specific feature you want implemented using this?

Patrick · August 5, 2018, 1:32pm

Key less VNC / SSH?

Onion Services - Whonix

Patrick · December 9, 2019, 2:00pm

Onion Services - Whonix wiki is outdated.

Dec 09 13:32:40 host tor[14798]: Dec 09 13:32:40.800 [warn] Hidden service option HiddenServiceAuthorizeClient is incompatible with version 3 of service in /var/lib/tor/hidden_service/

Dunno what still applies nowadays. Will copy old contents here.

=== Introduction ===
By default Onion Service names are known to the public as they are broadcast to Onion Service directories. This information becomes sequestered in search crawlers allowing anyone to try and connect and probe your Hidden Server even if this wasn't your intention.

To set up a Hidden service in a private mode, only accessible by just you or additionally your trusted associates, there is a little known feature in Tor feature known as Onion Services Authentication. <ref>http://tor.stackexchange.com/questions/219/how-to-use-hidden-service-authentication How to use Onion Service Authentication?</ref><ref>https://gitweb.torproject.org/torspec.git/tree/proposals/121-hidden-service-authentication.txt</ref> When activated, no one (not even the Onion Service Directories) can derive your <code>.onion</code> address from the descriptors nor can they know the introduction points to your server and consequently will not be able to connect to you.

This feature allows the HS operator to generate multiple shared secrets - giving access to different parties which is revocable. Configurable with the <code>stealth</code> auth type used with <code>HiddenServiceAuthorizeClient</code>. Meaning that clients who are banned will no longer know about the HS' introduction points anymore.

<code>HiddenServiceAuthorizeClient</code>:
<blockquote>
This option is only for v2 services; v3 services configure client authentication in a subdirectory of HiddenServiceDir instead (see the Client Authorization section).
</blockquote>

[https://www.torproject.org/docs/tor-manual.html.en Tor manual]

=== Server Setup ===
On {{gateway_product_name}}.

{{Open /usr/local/etc/torrc.d/50_user.conf}}

See the following example. Adjust it for your purposes and add it.

{{CodeSelect|code=
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 22 127.0.0.1:22
HiddenServicePort 5900 127.0.0.1:5900
HiddenServiceVersion 3
## syntax:
## HiddenServiceAuthorizeClient auth-type client-name,client-name,…
## 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.
## Valid client names are 1 to 16 characters long and only use characters in A-Za-z0-9+-_ (no spaces). 
HiddenServiceAuthorizeClient stealth 1234567890123456
}}

Save.

{{Reload Tor}}

To get your Tor onion service url and password, run.

{{CodeSelect|code=
sudo cat /var/lib/tor/hidden_service/hostname
}}

Should show something like this.

<pre>
xxxxxxxxxxxxxxxx.onion 0123456789012345678901 # client: 1234567890123456
</pre>

This is the authentication cookie that was generated by Tor that should be shared with the one supposed being allowed to connect,

* preferably face-to-face or,
* or via OpenPGP encrypted e-mail or OTR encrypted chat over Tor involving both parties.

Note that you can generate a unique authentication cookie for every individual or group you grant access to. This gives you the ability to revoke access if the need arises. It is an all or none rule for granting access to an onion service. If you want to limit that on a subdomain level you are advised to implement it by compartmentalizing your services under different onion service addresses running on a Multiple Workstation setup.

Patrick · December 9, 2019, 3:07pm

Please re-add whatever is still applicable. @HulaHoop

Wiki updated just now.

Specifically:

v2 onion services authentication no longer documented to keep that already complicated wiki page more easy. Still available in the wiki history if someone badly needs it.
v3 onion services authentication unfortunately is quite a bit more complicated.

Could you try please if these instructions work for you and adjust any inaccuracies?

HulaHoop · December 9, 2019, 3:12pm

OK

nitpick:
The main point of authentication for v3 is revocable access while keeping the service address the same for other remaining users.

v3 addresses are not enumerated by onion service dirs so this threat is no longer relevant if you never publicly share the v3 address.

HulaHoop · December 10, 2019, 2:40pm

There are now scripts for automating all these steps. This bash script was used by ageis who works at the Freedom of the Press Foundation:

gist.github.com

https://gist.github.com/mtigas/9c2386adf65345be34045dace134140b

onion-svc-v3-client-auth.sh

#!/bin/bash

# needs openssl 1.1+
# needs `basez` https://manpages.debian.org/testing/basez/base32hex.1.en.html
#   (but something else that decodes the base64 and re-encodes the raw key bytes
#    to base32 is probably fine too)

##### generate a key

openssl genpkey -algorithm x25519 -out /tmp/k1.prv.pem

This file has been truncated. show original

output-example.txt

X25519 Private Key:
BBBEAUAO3PIFAH7SBGBI6A2QFAZBXG2NVN7HMBXFCZENJVF6C5AQ

X25519 Public Key: (give this to the onion service)
SUCXD2A4YRK4JQ37QCIAQXGASQWVLFH45XENCC5YDZFR6RIT6ETA

=====
Tor client configuration
=====
Make sure you have ClientOnionAuthDir set in your torrc. In the

This file has been truncated. show original

What if we include a modified version of it in a package on the GW and simply refer user to run it as one command on the wiki? It could be part of a multi script package to improve HS usability.

If you agree. I can test that instead.

Here are other versions of the same script in python and rust:

github.com

pastly/python-snippits/blob/master/src/tor/x25519-gen.py

#!/usr/bin/env python3
import base64
try:
    import nacl.public
except ImportError:
    print('PyNaCl is required: "pip install pynacl" or similar')
    exit(1)


def key_str(key):
    # bytes to base 32
    key_bytes = bytes(key)
    key_b32 = base64.b32encode(key_bytes)
    # strip trailing ====
    assert key_b32[-4:] == b'===='
    key_b32 = key_b32[:-4]
    # change from b'ASDF' to ASDF
    s = key_b32.decode('utf-8')
    return s

This file has been truncated. show original

https://kushaldas.in/posts/setting-up-authorized-v3-onion-services.html

Patrick · December 10, 2019, 3:01pm

Yes. Please test. Could you compare please the manually created files with the files created by this script? Except for hostnames and random strings (keys) they should look the same. If yes, we can go for that.

HulaHoop · December 11, 2019, 5:12pm

Script needed basez to work. It did what it was supposed to, but I find the whole process of what to do next with the generated pub/priv key pair very confusing. The wiki and script differ in naming and terminology of the same thing and I’m not understanding it.

Problem: tor can’t restart with the changes in torrc.d and no onionv3 is ever created. I think the instructions for generating a plain v3 onion are broken. journalctl logs are useless here.

HulaHoop · December 11, 2019, 7:06pm

EDIT:

plain v3 works. There is no need to make an authorized client folder as there is one in hidden_service

HulaHoop · December 11, 2019, 7:13pm

I’m just not seeing the usecase to justify all the complexity when one can just generate unique onions and hand them out to different parties and delete the ones no longer permitted to access?

Patrick · December 11, 2019, 8:36pm

Maybe it’s based on incorrect assumptions? Maybe finding an onion through trying to connect randomly to them is conceivable? Chances are? I am speculating under the assumption that Tor Project wouldn’t have gone through the complexity of implementing this if there is no gain. Maybe we can find a rationale for this feature or maybe ask upstream?

HulaHoop · December 11, 2019, 9:34pm

Asked:

https://lists.torproject.org/pipermail/tor-dev/2019-December/014105.html

HulaHoop · December 12, 2019, 5:02pm

https://lists.torproject.org/pipermail/tor-dev/2019-December/014106.html

Reply summary:

Guessing it is as likely as guessing the correct key that has 2^256 entropy.
The only advantage I’m seeing is that it has less resource load than the multi onion approach, but then again if you have a authenticated access scenario, how many parties do you hope to manage before it becomes out of hand? The security argument is moot when malware can just steal the auth cookie. Also you can take v3 service keys offline for extra security. Another argument for authenticated access is it makes webserver configuration more manageable than in the multi onion scenario.

https://lists.torproject.org/pipermail/tor-dev/2019-December/014107.html

Another suggestion is to use it to protect a publicly accessible bookmark that you refer to, but I would archive the info all offline because it gives more peace of mind.

Thoughts on this?

HulaHoop · December 13, 2019, 3:56pm

Current wiki instructions are broken. Tor can’t reload:

Main PID: 784 (tor)
Tasks: 1 (limit: 540)
Memory: 19.6M
CGroup: /system.slice/system-tor.slice/tor@default.service
└─784 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defau…

Dec 13 15:47:47 host Tor[784]: Read configuration file “/etc/tor/torrc”.
Dec 13 15:47:47 host Tor[784]: Included configuration file or directory at…onf".
Dec 13 15:47:47 host Tor[784]: Included configuration file or directory at…onf".
Dec 13 15:47:47 host Tor[784]: Included configuration file or directory at…onf".
Dec 13 15:47:47 host Tor[784]: You configured a non-loopback address '10.1…nted.
Dec 13 15:47:47 host Tor[784]: You configured a non-loopback address '10.1…nted.
Dec 13 15:47:47 host Tor[784]: Permissions on directory /var/lib/tor/hidde…sive.
Dec 13 15:47:47 host Tor[784]: Failed to parse/validate config: Failed to …ails.
Dec 13 15:47:47 host Tor[784]: Reading config failed–see warnings above. …y -h.
Dec 13 15:47:47 host Tor[784]: Restart failed (config error?). Exiting.

Patrick · December 16, 2019, 9:22am

Patrick · December 16, 2019, 9:26am

These lines are truncated.

sudo systemdctl --no-pager status tor@default
sudo journalctl --no-pager -u tor@default

Tor Documentation for Whonix Users

anon-verify

Need to read the full error message. For got this step?

Fix owner permissions.

sudo chown --recursive debian-tor:debian-tor /var/lib/tor/hidden_service

HulaHoop · December 16, 2019, 2:30pm

No, but I’ll take another crack and report logs properly.

HulaHoop · December 17, 2019, 4:17pm

This important setting was missing from the documentation:

ClientOnionAuthDir /var/lib/tor/hidden_service/authorized_clients/

Error still there but it’s a permissions thing:

Dec 17 :12 host systemd[1]: Reloading Anonymizing overlay network for TCP.
Dec 17 :12 host systemd[1]: Reloaded Anonymizing overlay network for TCP.
Dec 17 :12 host Tor[1093]: Received reload signal (hup). Reloading config and resetting internal state.
Dec 17 :12 host Tor[1093]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Dec 17 :12 host Tor[1093]: Read configuration file "/etc/tor/torrc".
Dec 17 :12 host Tor[1093]: Included configuration file or directory at recursion level 2: "/usr/local/etc/torrc.d/40_tor_control_panel.conf".
Dec 17 :12 host Tor[1093]: Included configuration file or directory at recursion level 2: "/usr/local/etc/torrc.d/50_user.conf".
Dec 17 :12 host Tor[1093]: Included configuration file or directory at recursion level 1: "/etc/torrc.d/95_whonix.conf".
Dec 17 :12 host Tor[1093]: You configured a non-loopback address '10.152.152.10:5300' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 17 :12 host Tor[1093]: You configured a non-loopback address '10.152.152.10:9040' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 17 :12 host Tor[1093]: Permissions on directory /var/lib/tor/hidden_service/ are too permissive.
Dec 17 :12 host Tor[1093]: Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Dec 17 :12 host Tor[1093]: Reading config failed--see warnings above. For usage, try -h.
Dec 17 :12 host Tor[1093]: Restart failed (config error?). Exiting.
Dec 17 :13 host systemd[1]: tor@default.service: Main process exited, code=exited, status=1/FAILURE
user@host:~$ 



user@host:~$ anon-verify
/===================================================================\
|                      Report Summary                               |
\===================================================================/
Your Tor config files contain at least one error.
Tor verify exit code: 1
/===================================================================\
|                    Tor Concise Report                             |
\===================================================================/
Below warns and errors must be fixed before you can use Tor:
Dec 17 :40.099 [warn] Permissions on directory /var/lib/tor/hidden_service/ are too permissive.
Dec 17 :40.099 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Dec 17 :40.099 [err] Reading config failed--see warnings above.
/===================================================================\
|                      Tor Full Report                              |
\===================================================================/
Dec 17 :40.085 [notice] Tor 0.4.1.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Dec 17 :40.085 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 17 :40.086 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Dec 17 :40.086 [notice] Read configuration file "/etc/tor/torrc".
Dec 17 :40.097 [notice] Included configuration file or directory at recursion level 2: "/usr/local/etc/torrc.d/40_tor_control_panel.conf".
Dec 17 :40.097 [notice] Included configuration file or directory at recursion level 2: "/usr/local/etc/torrc.d/50_user.conf".
Dec 17 :40.097 [notice] Included configuration file or directory at recursion level 1: "/etc/torrc.d/95_whonix.conf".
Dec 17 :40.098 [notice] You configured a non-loopback address '10.152.152.10:5300' for DNSPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 17 :40.098 [notice] You configured a non-loopback address '10.152.152.10:9040' for TransPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Dec 17 :40.099 [warn] Permissions on directory /var/lib/tor/hidden_service/ are too permissive.
Dec 17 :40.099 [warn] Failed to parse/validate config: Failed to configure rendezvous options. See logs for details.
Dec 17 :40.099 [err] Reading config failed--see warnings above.
/===================================================================\
|                 Used Tor Configuration Files                      |
\===================================================================/
5 files are used as Tor configuration files: 
/usr/share/tor/tor-service-defaults-torrc /etc/tor/torrc /etc/torrc.d/95_whonix.conf /usr/local/etc/torrc.d/40_tor_control_panel.conf /usr/local/etc/torrc.d/50_user.conf
=====================================================================
user@host:~$

Patrick · December 17, 2019, 4:47pm

Try these two commands. One.

sudo chown --recursive debian-tor:debian-tor /var/lib/tor

Two.

sudo chmod --recursive o-rwx /var/lib/tor

Otherwise please show

ls -la /var/lib/tor
ls -la /var/lib/tor/hidden_service/

It is here: Onion Services - Whonix