Manage onion services

[nyxnor]

My old mod: https://github.com/nyxnor/raspiblitz/blob/tor-patch/home.admin/config.scripts/tor.onion-service.sh
New mod: https://github.com/nyxnor/CLI-onion-services/blob/main/tor.onion-service.sh

Currently, the script CREATES, DELETES (optionally purge to delete the onion address), ADD and REMOVE auth, see CREDENTIALS.
My script configure client auth server side, but the client side needs to be configure manually. I explained the commands deeply when running the script with echo, but it should be shortened to only display the string necessary and a guide in torbox page or text/ folder explaining how to do so.

This post was edited for reference.
This is informational material of things to be implemented and reviewed if were. This is more a long term goal than a complete todo list. The texts were extracted from each link mentioned above them, only the most useful information.

Instructions

• Matt Traudt HS Setup

• TPO setup onion service

  • Tip: A good practice to avoid leaking an onion service to a local network is to run onion services over Unix sockets instead of a TCP socket. You will need to edit and put the following two lines in your torrc file:

HiddenServiceDir /var/lib/tor/my-website/
HiddenServicePort 80 unix:/var/run/tor-my-website.sock

(Optional) Step 5: Running multiple onion services

If you want to forward multiple virtual ports for a single onion service, just add more HiddenServicePort lines. If you want to run multiple onion services from the same Tor client, just add another HiddenServiceDir line. All the following HiddenServicePort lines refer to this HiddenServiceDir line, until you add another HiddenServiceDir line:

 HiddenServiceDir /var/lib/tor/onion_service/
 HiddenServicePort 80 127.0.0.1:80

 HiddenServiceDir /var/lib/tor/other_onion_service/
 HiddenServicePort 6667 127.0.0.1:6667
 HiddenServicePort 22 127.0.0.1:22

• If you're running multiple onion sites on the same web server, remember to edit your web server virtual host file and add the onion address for each website. For example, in Nginx and using Tor with Unix sockets, the configuration would look like this:

server {
        listen unix:/var/run/tor-my-website.sock;
        server_name <your-onion-address>.onion;
        access_log /var/log/nginx/my-website.log;
        index index.html;
        root /path/to/htdocs;
}

Or in Apache with Tor service listening on port 80:

     <VirtualHost *:80>
       ServerName <your-onion-address.onion>
       DocumentRoot /path/to/htdocs
       ErrorLog ${APACHE_LOG_DIR}/my-website.log
     </VirtualHost>

• MTigas gist ProPublica with unix socket

# /etc/tor/torrc

# Try to run Tor more securely via a syscall sandbox.
# https://www.torproject.org/docs/tor-manual.html.en#Sandbox
Sandbox 1

# Disable the SOCKS port. Not like anything else on this box is using tor.
SocksPort 0

# Set up the hidden service. propub3r6espa33w.onion -> www.propublica.org
# We're using unix sockets instead of "127.0.0.1:xxxxx". see nginx conf.
# Docs: https://www.torproject.org/docs/tor-manual.html.en#HiddenServicePort

HiddenServiceDir /var/run/tor/pp_www_hidserv
HiddenServicePort 80  unix:/var/run/nginx-pponion-80.sock
HiddenServicePort 443 unix:/var/run/nginx-pponion-443.sock

# /etc/nginx/sites-enabled/propubonion.conf
#
# Note that all of our hostnames listen to a unix socket instead
# of "127.0.0.1:xxxxx".
# Docs: http://nginx.org/en/docs/http/ngx_http_core_module.html#listen

map $http_upgrade $connection_upgrade {
  default  "upgrade";
  "" "";
}

# HTTP BARE ONION
server {
    listen       unix:/var/run/nginx-pponion-80.sock;
    server_name  propub3r6espa33w.onion;
    #allow 127.0.0.1;
    allow "unix:";
    deny all;
    server_tokens off;
    rewrite ^/(.*) http://www.propub3r6espa33w.onion/$1 permanent;
}

# HTTPS BARE ONION
server {
    listen       unix:/var/run/nginx-pponion-443.sock ssl spdy;
    server_name  propub3r6espa33w.onion;
    #allow 127.0.0.1;
    allow "unix:";
    deny all;
    server_tokens off;
    ssl_certificate     www.propub3r6espa33w.onion.pem;
    ssl_certificate_key www.propub3r6espa33w.onion.key;
    rewrite ^/(.*) https://www.propub3r6espa33w.onion/$1 permanent;
}

• Client Auth

  • Client authorization is a method to make an onion service private and authenticated. It requires Tor clients to provide an authentication credential in order to connect to the onion service. For v3 onion services, this method works with a pair of keys (a public and a private). The service side is configured with a public key and the client can only access it with a private key.
  • Note: Once you have configured client authorization, anyone with the address will not be able to access it from this point on. If no authorization is configured, the service will be accessible to anyone with the onion address.

• If you are generating a private key for an onion site, the user does not necessarily need to edit Tor Browser's torrc. It is possible to enter the private key directly in the Tor Browser interface.

• Onion-location

  • Onion-Location is an easy way to advertise an onion site to the users. You can either configure a web server to show an Onion-Location Header or add an HTML meta attribute in the website.
  • Using an HTML attribute

Nginx

To configure an Onion-Location header, the service operator should first configure an Onion service.

Step 1. Create an Onion service by setting the following in torrc:

HiddenServiceDir /var/lib/tor/hs-my-website/
HiddenServiceVersion 3
HiddenServicePort 80 unix:/var/run/tor-hs-my-website.sock

Step 2. Edit website configuration file

In /etc/nginx/conf.d/.conf add the Onion-Location header and the onion service address. For example:

add_header Onion-Location http://<your-onion-address>.onion$request_uri;

The configuration file with the Onion-Location should look like this:

server {
    listen 80;
    listen [::]:80;

    server_name <your-website.tld>;

    location / {
       return 301 https://$host$request_uri;
    }

}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name <your-website.tld>;

    # managed by Certbot - https://certbot.eff.org/
    ssl_certificate /etc/letsencrypt/live/<hostname>/fullchain.pem; 
    ssl_certificate_key /etc/letsencrypt/live/<hostname>/privkey.pem;

    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header Onion-Location http://<your-onion-address>.onion$request_uri;

    # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    access_log /var/log/nginx/<hostname>-access.log;

    index index.html;
    root /path/to/htdocs;

    location / {
            try_files $uri $uri/ =404;
    }
}

server {
        listen unix:/var/run/tor-hs-my-website.sock;

        server_name <your-onion-address>.onion;

        access_log /var/log/nginx/hs-my-website.log;

        index index.html;
        root /path/to/htdocs;
}

Step 3. Test website configuration

sudo nginx -t

The web server should confirm that the new syntax is working:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Step 4. Restart nginx

sudo nginx -s reload

If you get an error message, something has gone wrong and you cannot continue until you've figured out why this didn't work.

Step 5. Testing your Onion-Location

To test if the Onion-Location is working, fetch the web site HTTP headers, for example:

wget --server-response --spider your-website.tld

Look for onion-location entry and the onion service address. Or, open the web site in Tor Browser and a purple pill will appear in the address bar.

• The identical behaviour of Onion-Location includes the option of defining it as a HTML http-equiv attribute. This may be used by websites that prefer (or need) to define an Onion-Location by modifying the served HTML content instead of adding a new HTTP header. The Onion-Location header would be equivalent to a added in the HTML head element of the webpage. Replace <your-onion-service-address.onion> with the onion service that you want to redirect.

• TPO community OpSec

  • TPO Gitlab OpSec
  • As mentioned here, be careful of letting your web server reveal identifying information about you, your computer, or your location. For example, readers can probably determine whether it's thttpd or Apache, and learn something about your operating system.
  • If your computer isn't online all the time, your onion service won't be either. This leaks information to an observant adversary.
  • It is generally a better idea to host onion services on a Tor client rather than a Tor relay, since relay uptime and other properties are publicly visible.
  • The longer an onion service is online, the higher the risk that its location is discovered. The most prominent attacks are building a profile of the onion service's availability and matching induced traffic patterns.
  • Another common issue is whether to use HTTPS on your onionsite or not. Have a look at this post on the Tor Blog to learn more about these issues.
  • To protect your onion service from advanced attacks you should use Vanguards addon, read Tor blog about Vanguards and Vanguards' Security README.

• Riseup OpSec - Leaking the real server

  • A common misstep here is server signatures, for example it is easy to determine if a webserver is thttpd or Apache, or learn about your operating system because the banner tells the version of the running service and operating system.
  • Another way that your onion address will get out is via the referrer header in browsers when a client browses a hidden service website and then clicks on a clearnet/hidden service link. The Tor browser has taken care of many of these tiny leaks, so be sure to encourage your users to use an up-to-date tor browser instead of using their own browser with Tor.
  • If the server running the onion service is also exposed to the clearnet, make sure that when you connect to either the clearnet service or the onion service, you cannot specify in the host header the other service and get a response. You should ensure the onion service is only listening on the internal IP and your external service is only listening on the external IP address. The easiest way to ensure there are no failures here is this is to run your service on a machine that has no external IP address.
  • Make sure the time on your server is correct, and is corrected automatically by NTP, so that time skews do not help identify your server.
  • Make sure you are not inadvertently exposing information, for example with PHP you may disclose the server’s real name/address if you leak phpinfo() or $_SERVER, or expose error messages!
  • Look into protecting yourself against Server Side Request Forgery (SSRF). This attack works by getting the server to perform an external connection (DNS lookup, etc.) which can expose your machine’s real location. Strict egress firewalling is one way to mitigate against this problem.
  • The longer an onion service is online, the higher the risk that its location is discovered. The most prominent attacks are building a profile of the onion service’s availability and matching induced traffic patterns.
  • There are currently ways in the protocol that a bad relay can learn about your onion address, even if you don’t tell anybody. Follow the discussion on the subject if you want to stay on top of how the Tor project is working on fixing these issues.

• Riseup OpSec - Be careful of localhost bypasses!

  • You should take very careful care to not accidentally expose things on your server that are restricted to the local machine. For example, if you provide /server-status in apache (from mod_status which is enabled per default in debian’s apache) to monitor the health of your apache webserver, that will typically be restricted to only allow access from 127.0.0.1, or you may have .htaccess rules that only allow localhost, etc.
  • There are a few ways you can solve this problem:
    • different machine: consider running the onion service on a different machine (real or virtual) than the actual service. This has the advantage that you can isolate the service from the onion service (a compromise of one doesn’t compromise the other) and helps with isolating potential information leaks
    • isolation: similarly to the above, you can also isolate Tor and the service so it will run on a different network namespace than the service. Tails uses a Tor-or-fail packet filter.
    • public ip: configure the onion service to connect to the public IP address of the service instead of localhost/127.0.0.1, this should make Tor not pick 127.0.0.1 as the source address and avoid most misconfigurations. For example like this:

HiddenServiceDir /var/lib/tor/hidden/ftp/
HiddenServicePort 80 192.168.1.1:81

• Note: This makes your server and vhost potentially reachable to an external entity. There has been a growing number of attempts to discover the true location of sites behind cloudflare that are badly configured because they still expose their true httpd on a public IP address. People regularly use masscan and zmap to scan the entire ipv4 address space and try to connect to a publicly exposed httpd and request “high-value” onion addresses from the httpd to see if they send a Host header and make the site serve their probed vhosts content.
• Binding to a port that is different from the “true” port is a source of a potential leak on Apache. If there is a directory, e.g. foo.onion/css/ then a request to foo.onion/css will cause apache to emit a 301 redirect, but when it does issue it, it will include the port that it thinks the service is listening on. Instead of sending a 301 to foo.onion/css/ it would send a 301 for foo.onion:81/css/ this both breaks the website and reveals the port the httpd is really running on.
  • unix socket: consider using unix socket support instead of a TCP socket (requires 0.26 or later Tor) – if you do this, then the onion service will be running on the same server as the service itself. With a socket approach, you should be able to run with privatenetwork=yes in systemd unit which gets you some really great isolation, for example:

HiddenServicePort 80 unix:/etc/lighttpd/unix.sock

• But then the service itself needs to support unix sockets, otherwise you have to setup some socat redirection from tcp <→ unix (nginx, twisted, lighttpd all support this).

• audit carefully: carefully audit, and regularly re-audit your system for configurations that allow localhost/127.0.0.1, but prohibit everywhere else and configure those to work around the problem (for example make /server-status operate on a different IP; make the webserver listen on a different port for /server-status; make it password protected, etc.).

• DoS Guidelines - Vanguards done, HiddenServiceExportCircuitID seems to be the only other plausible solution.

• Onionscan - Search for vulnerabilities in the HS

  • We want to help operators of hidden services find and fix operational security issues with their services. We want to help them detect misconfigurations and we want to inspire a new generation of anonymity engineering projects to help make the world a more private place.
  • Secondly we want to help researchers and investigators monitor and track Dark Web sites. In fact we want to make this as easy as possible. Not because we agree with the goals and motives of every investigation force out there - most often we don't. But by making these kinds of investigations easy, we hope to create a powerful incentive for new anonymity technology (see goal 1)

Special note for TorBox as it acts as a relay

It is generally a better idea to host onion services on a Tor client rather than a Tor relay, since relay uptime and other properties are publicly visible.

[nyxnor]

Let's say I have a set of hidden services I want to add a set of clients,
I can tick in a checklist the services I want to add clients, as well as well as add multiple clients at the same time, separated by a comma like this

TorBox/bridges_activate_old

Line 163 in eb88bba

# Activate only selected bridges

And if I loose trust a set of clients and want to remove them from the authorized list of multiple services, this should be done too.

Some scripts are required to be run with the debian-tor user, as it reads the /var/lib/torto check if service or client exists. I don't think there is a way to avoid that.

[ghost]

also Please Add option to import and export hidden services and torrc file from home directory, because directly to /var/lib/tor cannot copy files from scp an example, and export too, need special rights., for my is complicated, because, need to edit torrc file.

[nyxnor]

@connected201 Thank you for this.
import and export functions will be integrated to preserve onion addresses after flashing the sd card to update major versions of torbox, as well as importing previous services data from another computer.

Process should be to tar the folders /var/lib/tor/onion_auth and /var/lib/tor/services, define remote host (ip, user, path) to scp (maybe store these variables).
A whiptail inputbox to register data and whiptai menu to click to export or import data.

[nyxnor]

Tasks

• Error handling, skip if looping, not exit in every situation
• when renewing addresses, save clients name before deleting all auths and replace them with the new data with the same name
• mv part of the menu-onion-credentials, menu-onion-auth, menu-onion-renew, menu-onion-create, menu-onion-delete to be inside tor.onion-service.sh. Each menu has for now 100 lines each (counting 20 from the verbatim), so it is 80x5=300 more lines in the tor.onion-service.sh, also great part of the code is duplicated on those scripts, will pass them to torbox.lib or tor.onion-service.sh. I will remove instance and vanguards option from that script as it is not needed there for now. Total estimate is 600 lines in the tor.onion-service.sh. I am trying to keep it very short, no duplicate code there, functions and loops to refer too.
• Import and export functionality with scp https://www.linode.com/docs/security/authentication/use-public-key-authentication-with-ssh/ (40% done, need to complete the text and test more)
• Change LOCAL PORT to SOCKET? TPO guide and ProPublica - Mtigas guide. It is recommended to avoid leaking an onion service to a local network is to run onion services over Unix sockets instead of a TCP socket. (Useful but more difficult to implement as need to change nginx config for the server and not mess up)
• Intersection from the problem below is solved after pain.

[nyxnor]

Current problem I need help to bypass.
When selecting the option client auth from the menu, user can select multiple services. When that happens, I want to show the intersection of the authorization files with the same name that are present on different services dir.

ssh/authorized_clients/alice.auth
ssh/authorized_clients/bob.auth

test/authorized_clients/alice.auth

If selecting ssh and test service, I want to display only alice.
Keyworkds to search bash/shell, intersection, multiple, files, directories/folders, find, compare.

https://en.wikipedia.org/wiki/Intersection_(set_theory)

I need to do with bash the intersection of multiple sets.

---

Okay, this seems to help https://stackoverflow.com/a/28161520

echo ${array1[@]} ${array2[@]} ${array3[@]} | tr ' ' '\n' | sort | uniq -c

count number of arrays and math with values that represent the same number.
Concatenating arrays would also serve.

[radio24]

Taking the official documentation about setting up an Onion Service as a reference, are these files necessary for the client authorisation? If I understand it right, with it, the owner of the server can decide who can access it and who not. How is it with a public server - let's say torbox.ch on an onion address? Does such a server need these .auth files too?

[nyxnor]

Yes, those files are necessary for servers with client auth. 2019 guide and the clean community guide.

The nomenclatures I use for clarification:
Hidden server - just known to user or to select group that was shared
Public server - normally used with onion location, to be known and seen by anyone

Hidden servers are appropriate to set up Client Authorization to manage who can view the service and access it, without the client key, the service page does not even load, protecting the privacy and against DOS attacks.

torbox.ch is supposed to be seen and used by anyone, so it should not require a client key. I know it is hard to grasp without testing, but I did a lot of improvements to the script and will try to release them soon after enough testing.

More about client auth:
The script I made automatically saves to the server authorized clients the pub key of each client, it echos the private key in the right format to be used in the torbrowser or to be saved to onion_auth/alice.auth_private, this is manual step by the client, you just need to pass them the key and directions, which will be done with infomation displayed with text/onion-auth-explanation-save-client-key

[nyxnor]

Take a look here https://github.com/nyxnor/onion-cli
The checklist option for whiptail is too ugly, it is using that but with dialog checklist commented if needed to change.

Everything there has a reason, if it does not sound right, ask me.
Manual inputs only happen 2 times, when creating a hidden service, cause it is necessary to type the service name and ports, the 2nd time it occurs is when adding clients, user need to give a name for them.
Menu does almost everything that the tor.onion-service.sh does but with CLI it is limited, I think I reached 90% of what the menu does. What is missing is purging services after deleting their configuration or purging all clients from selected services (but this last can be done by selecting the desired services one by one and their clients).
Purging the service data dir can be implemented with a warning: "Do you want to preserve the onion address or purge?", default to not delete.
Will adapt this to whiptail:

    echo "Client Private key for ${SERVICE}"
    echo
    echo "RAW:"
    echo
    echo "Address = "${TOR_ADDRESS}
    echo "Key     = "${PRIV_KEY}
    echo "Conf = "${TORRC_CLIENT_KEY}
    echo
    echo
    echo "EXPLAINED:"
    echo
    echo " BROWSER -> Typing the key in the GUI"
    echo " * In the browser, enter the service address       = "${TOR_ADDRESS}
    echo " * A small window will be prompted, enter the key  = "${PRIV_KEY}
    echo
    echo " BROWSER and DAEMON 2 -> Adding the key to torrc to be read automatically"
    echo " * Add the line containing ClientOnionAuthDir to the torrc file accordingly to your setup (remove identation):"
    echo "   - Browser = [Tor_Browser_folder]/Browser/TorBrowser/Data/Tor/torrc"
    echo "      ClientOnionAuthDir TorBrowser/Data/Tor/onion_auth"
    echo "   - Daemon  = /etc/tor/torrc"
    echo "      ClientOnionAuthDir /var/lib/tor/onion_auth/"
    echo
    echo " * Add the private key (note: same content for Browser and Daemon but different paths):"
    echo "   - Browser =  [Tor_Browser_folder]/Browser/TorBrowser/Data/Tor/onion_auth/bob.auth_private"
    echo "   - Daemon  = /var/lib/tor/onion_auth/bob.auth_private"
    echo "     "${TORRC_CLIENT_KEY}
    echo
    echo " * Restart the instance"
    echo "   - Browser = Close and open again the Tor Browser Bundle"
    echo "   - Daemon  = Reload the daemon = $ sudo pkill -sighup tor"
    echo
    echo " * Go to the service address = "${TOR_ADDRESS}

[nyxnor]

The cleanest guide to understadn client auth: https://matt.traudt.xyz/posts/creating-private-v3-FgbdRTFr/
and the cleanest to host an onion service https://matt.traudt.xyz/posts/website-setup/

[nyxnor]

Updated repo https://github.com/nyxnor/onion-cli
It is very simple, the .md files are there cause I am planning on adding them to instructional part of the menu.
Onion-Location is just a guide.
Backup functionality such as export and import are not finished yet and need this to be complete (but not only this, constant bugs trying to solve). is now finished but I need to test thoroughly if it does not lead to bugs, this is the most crucial part, making sure to save the hs secret keys.

I recently started using Qubes-Whonix and it enhances the security of the system overall, a lot for onion services. Some parts of the scripts may not work on whonix (HiddenServicePort target as unix:path do not work because it is a VM), but I am using them as a security guide, even though debian is no whonix, we can harden debian too. Take a look here https://www.whonix.org/wiki/Onion_Services#Security_Recommendations

I made onion-cli in a way it can be just git cloned and run, no installation of software (beside vanguards if requested). So it can be cloned to TorBox if needed. If you plan to make changes, please commit directly so I can better the software.

Demonstration video of some of the functionalities: https://twitter.com/nyxnor/status/1434033535678091270

[nyxnor]

CLI

onion-video.mp4

---

TUI

Overall view of the TUI, it just calls the cli script.
Also if you notice, on the TUI, it only appears more options that required a onion service if you have at least one configured.
lib + tui + cli = 1500 lines of code, which is short to review.

tui-onion.mp4

[ghost]

very nice, it will be implement in next release of torbox?

[radio24]

Regarding the implementation, my idea is to do it in several steps:

1. Implementation of a public website (for example torbox.ch, which doesn't require any client authentication).
2. Implementation of private websites od "shares", which requires a client authentication.

How about the time table
To-do for the next 2-3 weeks:

• We will first fix some bugs in the current configuration, like the one described in issue #88.
• We will also explorer the possibility to deactivate SSH as described in issue #83 and issue #84.
• Some of the installed python modules and compiled packages (for example snowflake) are not automatically updated with the Update and Reset sub-menu - we will try to change that.

After completing the above points, we will start with the implementation of the hidden services.

[nyxnor]

Can you make a github repo of the torbox.ch website so I can test publishing it? I see it is wordpress and they use cloudflare (curl --head https://torbox.ch).

Note that publishing a website is just one of the utilities one can do with onion domain. I use for instant messaging communication with XMPP an onion domain.

Note that implementing a website with or without client auth won't differ much, few clicks with the menu or some arguments with the CLI, which is way fast than doing manually.

My timetable is difficult to estimate,

• I have being trying to fix all bugs that could cause incorrect torrc configuration (critical cause they make tor fail and need manual edit if occurs), then after it is stable (my script tries to stop any incorrect configuration before inserting into torrc. I can't skip this step, it is necessary.
• Error handling on auth server list when there is not client in there. This is not an error per se, it just does not output anything meaningful saying there is not client, and I want that to be very clear to the user.
• Nginx configuration sample that don[t require user configuration, the script should handle inserting the tcp or unix path for the listen parameter. I havent started this yet. (Apache maybe if someone send me a apache configuration sample). Nginx resources from MTigas ProPublica with Unix socket and a Single config for Tor and plainnet and Raspiblitz TCP socket with Separate config for Tor and local

[nyxnor]

If one just want to publish a website via terminal, there is onionshare-cli, I like what they do but I am not sure it fits TorBox because it saves all information to a single chosen file, so they do not modify local torrc and HiddenServiceDir. Anyway, onionshare-cli is really helpful for setting a website to chat, send and receive files, publish a webpage and can add client auth on top of each previous action.

[nyxnor]

But now you want just a you and select clients to access that page, add client auth on your server:

Lets generate a key pair a this is an example, but if the client gave you only his pub key, select the option below of course:

Lets add alice and bob, possible combinations for clients are: alice bob, alice,bob, alice, bob`. Comma or space separated.

Important line for Tor Browser is CLIENT_PRIV_KEY=KABLUFI3AMAY62OPOZL3PFHXKMFRE5XCBXBDVLHHAA5V7RNEWZWA
Important line for tor (daemon) is
CLIENT_PRIV_KEY_CONFIG=sjyyyi6y3hqszp4myx3ytghdjpe6gavldymkbwj62wvhsxxs2lg7njqd:descriptor:x25519:KABLUFI3AMAY62OPOZL3PFHXKMFRE5XCBXBDVLHHAA5V7RNEWZWA

Lets copy the browser key option. Reload the Browser page and try again

Now it is authenticated, you need a key to access it.

Try leaving the key field blank or with wrong credentials:

[radio24]

Unfortunately, it will take me a little longer to integrate it into TorBox. My job (the one that pays my bills) is putting me under a bit of workload again.

[nyxnor]

No problem, with that I have more time to test and to find a job :)
The warning on the readme to not trust the repo is because it was only reviewed by myself and developers can be blind on the code they wrote. Also the backup technique needs to be improved, it does its job but I will always want a better backup to be safe.

About you integrating into TorBox, note that you just need to clone and follow the steps on the readme, maybe add one option on the menu to redirect to onion services menu. There is no secret.

But if you really decide to go deep and integrate each option your way, that is okay but I tried to integrate TorBox to Raspiblitz and it worked the first time, but with each new commit and release of TorBox, it becomes harder to keep upgrading individually the files I've changed. The same goes for integrating OnionService to TorBox. (The end result is that I am still building a custom script to change hardcoded paths of TorBox with sed and try to not break things when bulking with sed, which is difficult when dealing with multiple files).

[nyxnor]

About the long information first comment #80 (comment)

I have completed all it is possible to do scripting for an onion service. The rest is OpSec that depends on the operator such as:

different machine: consider running the onion service on a different machine (real or virtual) than the actual service. This has the advantage that you can isolate the service from the onion service (a compromise of one doesn’t compromise the other) and helps with isolating potential information leaks
isolation: similarly to the above, you can also isolate Tor and the service so it will run on a different network namespace than the service. Tails uses a Tor-or-fail packet filter.

OpSec recommendation to use unix domain as the HiddenServicePort VIRTPORT TARGET is done already for example.

[radio24]

I didn't decide yet on which approach I will integrate onionservice-cli and onionservice-tui into TorBox. At first sight, it seems that I can take onionservice-cli as it is but have to (re-)write my version of onionservice-tui.

One reason I will not only copy your work without understanding the code is that I will also try to contribute to your work. I already did a fork of your project, and if I find something I can contribute, I will make a pull request.

Anyway, great work!

[nyxnor]

Feel honored, thanks for the fork. Having any questions about why I did something just say it, because the documentation is more about what the result of a combination of command will be, instead of why and how it is doing that.

Also the TUI problem is the color (that you can set with .dialogrc) or because I use dialog instead of whiptail?
I am asking this because I tried to make the most configurable possible so anyone that wants to use it won't have trouble modifying the scripts, if you explain what is lacking I can do enhance.

[radio24]

What are the advantages of dialog over whiptail?

[nyxnor]

FreeBSD's dialog man (read whiptail section in there also)

• Whiptail is dialog with a less boxes options
• with dialog I can move between options with the first letter, so it is faster to navigate than just arrow keys
• dialog centers lists within the window. whiptail typically puts lists against the left margin. I think centering is better.
• I did not like that whiptail highlights in red stopping at the last character, with dialog, it highlights the whole line
• color choice, does not need to be dark, can be green for TorBox editing .dialogrc.
• I just discovered there is dselect and fselect with dialog, which I can delect directories and files.

[nyxnor]

green dialogrc to fit torbox

# Run-time configuration file for dialog
#
# Types of values:
#
# Number     -  <number>
# String     -  "string"
# Boolean    -  <ON|OFF>
# Attribute  -  (foreground,background,highlight?,underline?,reverse?)
#
#
# Colors:
#
# Interpret embedded "\Z" sequences in the dialog text by the following character,
# which tells dialog to set colors or video attributes: 0 through 7 are the ANSI
# used in curses: black, red, green, yellow, blue, magenta, cyan and white
# respectively. Bold is set by 'b', reset by 'B'. Reverse is set by 'r', reset by 'R'.
# Underline is set by 'u', reset by 'U'. The settings are cumulative, e.g., "\Zb\Z1"
# makes the following text bold (perhaps bright) red. Restore normal settings with "\Zn".
#
# 0 = black
# 1 = red
# 2 = green
# 3 = yellow
# 4 = blue
# 5 = magenta
# 6 = cyan
# 7 = white
#
# b = bold (set)
# B = bold (unset)
# r = reverse (set)
# R = reverse (unset)
# u = underline (set)
# U = underline (unset)
# n = default (restore)
#
# Source: https://github.com/openoms/joininbox/blob/v0.6.0/scripts/.dialogrc

# Set aspect-ration.
aspect = 0

# Set separator (for multiple widgets output).
separate_widget = ""

# Set tab-length (for textbox tab-conversion).
tab_len = 0

# Make tab-traversal for checklist, etc., include the list.
visit_items = OFF

# Shadow dialog boxes? This also turns on color.
use_shadow = OFF

# Turn color support ON or OFF
use_colors = ON

# Screen color
screen_color = (WHITE,GREEN,ON)

# Shadow color
shadow_color = (BLACK,BLACK,ON)

# Dialog box color
dialog_color = (BLACK,WHITE,ON)

# Dialog box title color
title_color = (BLACK,WHITE,ON)

# Dialog box border color
border_color = (BLACK,WHITE,ON)

# Active button color
button_active_color = (WHITE,GREEN,ON)

# Inactive button color
button_inactive_color = dialog_color

# Active button key color
button_key_active_color = button_active_color

# Inactive button key color
button_key_inactive_color = (GREEN,WHITE,OFF)

# Active button label color
button_label_active_color = (WHITE,GREEN,ON)

# Inactive button label color
button_label_inactive_color = (GREEN,WHITE,ON)

# Input box color
inputbox_color = dialog_color

# Input box border color
inputbox_border_color = dialog_color

# Search box color
searchbox_color = dialog_color

# Search box title color
searchbox_title_color = title_color

# Search box border color
searchbox_border_color = border_color

# File position indicator color
position_indicator_color = title_color

# Menu box color
menubox_color = dialog_color

# Menu box border color
menubox_border_color = border_color

# Item color
item_color = dialog_color

# Selected item color
item_selected_color = button_active_color

# Tag color
tag_color = title_color

# Selected tag color
tag_selected_color = button_label_active_color

# Tag key color
tag_key_color = button_key_inactive_color

# Selected tag key color
tag_key_selected_color = (RED,GREEN,ON)

# Check box color
check_color = dialog_color

# Selected check box color
check_selected_color = button_active_color

# Up arrow color
uarrow_color = (GREEN,BLACK,ON)

# Down arrow color
darrow_color = uarrow_color

# Item help-text color
itemhelp_color = (BLACK,WHITE,OFF)

# Active form text color
form_active_text_color = button_active_color

# Form text color
form_text_color = (BLACK,WHITE,ON)

# Readonly form item color
form_item_readonly_color = (GREEN,BLACK,ON)

# Dialog box gauge color
gauge_color = title_color

# Dialog box border2 color
border2_color = dialog_color

# Input box border2 color
inputbox_border2_color = dialog_color

# Search box border2 color
searchbox_border2_color = dialog_color

# Menu box border2 color
menubox_border2_color = dialog_color

[radio24]

I studied the code of the "onionservice" scripts, and I'm starting to implement some of the features in TorBox v.0.4.3.

"onionservice" gives users the possibility to use "tcp socket" or "UNIX socket". Because "UNIX socket" is the more secure way, I ask myself if I should use this selection as default in TorBox. Are there some disadvantages if "UNIX socket" is used instead of "tcp socket"?

[nyxnor]

I have nothing to complain about unix socket.

There is an old bug with nginx unix socket but was fixed. Just drop below if interested.

There was a problem of it not being removed when [using SIGQUIT for the nginx process](https://trac.nginx.org/nginx/ticket/952), but it was fixed 17 months ago according to [this commit](https://trac.nginx.org/nginx/changeset/7cbf6389194b9170514e514ca7ee495369c9c8ac/nginx). I am saying this because this issue stood unfixed for more than 6 years since the issue was opened and people still refer to it for not using unix socket and not search it was closed, maybe trauma.

[nyxnor]

git pull my main branch, I fixed a bug that was implemented here https://github.com/radio24/onionservice/commit/85f95ba6961c01eeb9a1352dc698947c2ac9f20e, fix here nyxnor/onionjuggler@3958e6d

[radio24]

@nyxnor How should we treat this thread?

• Keep it open under issue?
• Close it?
• Move it to discussions (archive)?

[nyxnor]

discussions, there will be always something new to add and other people to report their experiences

[nyxnor]

Git over Tor

• guide pastly
• guide orionwl
  Instead of using plainnet

git clone https://github.com/bitcoin/bitcoin

let's maintain anonymity with

torsocks git clone http://nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion/git/bitcoin.git
## or resolve with the built-in git proxy:
#git -c http.proxy=socks5h://127.0.0.1:9050 clone http://nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion/git/bitcoin.git
cd bitcoin

continue with:

git config --add remote.origin.proxy "socks5h://127.0.0.1:9050" ## make sure that pulls go through the proxy.

If you already have the repository:

git remote add orionwl http://nxshomzlgqmwfwhcnyvbznyrybh3gotlfgis7wkv7iur2yj2rarlhiad.onion/git/bitcoin.git
git config --add remote.orionwl.proxy "socks5h://127.0.0.1:9050" ## make sure that pulls go through the proxy.

now after editing the files, adding or removing them, committing the changes, the git commands that requests that host will resolve through the proxy, the commands being clone, fetch and pull.

git fetch orionwl

If you want all hosts to resolve through the tor proxy to that git repository:

cd bitcoin
git config http.proxy 'socks5://127.0.0.1:9050' 

If you want all git repositories to use that proxy:

git config --global http.proxy 'socks5://127.0.0.1:9050' 

SSH over Tor

• guide
• ssh config

Instead of using the 56-char.onion to reach for the host,

torsocks ssh torbox@5rraorbx5dd3cuutxcue36cp4oschvlmltzzelzlr7yokf2m77h5vgyd.onion

alias it.

printf "
Host tor-router
    User torbox
    HostName 5rraorbx5dd3cuutxcue36cp4oschvlmltzzelzlr7yokf2m77h5vgyd.onion
    IdentityFile ~/.ssh/id_ed25519
    ProxyCommand nc -X 5 -x localhost:9050 %h %p
" | tee -a ~/.ssh/config

now you only need to

ssh tor-router

Notes:

• ssh_config
• IdentityFile -> Only if you authenticate with your public key. Read this guide
• ProxyCommand -> Only if you don't want to use torsocks and use netcat instead
• Command line option weighs more than config file, so if using the sam host but another User, IdentityFile, specify it as in:

ssh -o "User=root" tor-router

To ignore all options from the config file, use:

ssh -F /dev/null torbox@5rraorbx5dd3cuutxcue36cp4oschvlmltzzelzlr7yokf2m77h5vgyd.onion