radio24 / TorBox

TorBox is an easy to use, anonymizing router based on Raspberry Pi, which also runs on Debian and Ubuntu based systems.
https://www.torbox.ch
GNU Affero General Public License v3.0
262 stars 27 forks source link

Manage onion services #80

Closed nyxnor closed 3 years ago

nyxnor commented 3 years ago

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

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

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](https://community.torproject.org/onion-services/advanced/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](https://community.torproject.org/onion-services/advanced/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 <meta> 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/<your-website>.conf add the Onion-Location header and the onion service address. For example:

add_header Onion-Location http://.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 <meta> 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 <meta http-equiv="onion-location" content="http://<your-onion-service-address>.onion" /> 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](https://community.torproject.org/onion-services/advanced/opsec/)
  * [TPO Gitlab OpSec](https://gitlab.torproject.org/legacy/trac/-/wikis/doc/OperationalSecurity)
  * 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](https://riseup.net/en/security/network-security/tor/onionservices-best-practices#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!](https://riseup.net/en/security/network-security/tor/onionservices-best-practices#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](https://community.torproject.org/onion-services/advanced/dos/) - Vanguards done, `HiddenServiceExportCircuitID` seems to be the only other plausible solution.
* [Onionscan](https://github.com/s-rah/onionscan/blob/master/doc/what-is-scanned-for.md) - 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 commented 3 years ago

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 https://github.com/radio24/TorBox/blob/eb88bba0744b8ee0ec9bab6f232ce1faa4b16420/bridges_activate_old#L163 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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Tasks

nyxnor commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

CLI

https://user-images.githubusercontent.com/69700936/134138134-c054886d-b921-4d88-ae94-bf9f7795bebb.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.

https://user-images.githubusercontent.com/69700936/134151696-7aeea39c-def8-474d-8197-037e89024ab1.mp4

ghost commented 3 years ago

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

radio24 commented 3 years ago

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:

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

nyxnor commented 3 years ago

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,

nyxnor commented 3 years ago

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.

radio24 commented 3 years ago

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

Not at the moment. Just use a "Hello world" index.html, the README.md or the static index.htm from https://torbox.ch for testing. At the end, the of a publication of a public website shouldn't orient it on https://www.torbox.ch, but just work for a usual html/php website.

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. That sounds interesting and could be another longterm project. OnionShare is a good example what is possible.

nyxnor commented 3 years ago

Ok, got it working with one virtual port, the 80. For virtual port 443 with https on onion, will implement later.

  1. Save the website files inside /var/www/. As an example, the folder will be called torbox.ch. The service will also be called torbox.ch to be easy to remember.

    sudo mkdir -p /var/www/torbox.ch
  2. Create the onion service with unix or tcp socket: SYNTAX: on SOCKET SERVICE VIRTPORT

    sh onionservice-cli on unix torbox.ch 80
  3. Activate the web server (nginx in this case): Note the FOLDER="torbox.ch", no need to write /var/www/torbox.ch cause the script expect to be in this default folder (/var/www) already. SYNTAX: nginx STATYS SERVICE FOLDER_INSIDE_VAR_WWW

    sh onionservice-cli nginx on torbox.ch torbox.ch

Done, that is all you need to activate an onion service and spin up the web server.

  1. Now get the address that was printed from step 2 and open on Tor Browser. :+1:

  2. If you want to test client auth, you need to configure at least one client: SYNTAX: auth HOST STATUS SERVICE

    sh onionservice-cli auth server on torbox.ch alice

    The private key will be printed to the terminal, reload Tor Browser and use the key to access the website.

Notes:

nyxnor commented 3 years ago

Ok, now it is available with nginx or apache2, you can only choose one of course. Also, menu option to activate or deactivate serving a web site (not the hidden service configuration, the web server configuration for that hidden service) set the web server in .onionrc: image Setup the environment with sh setup.sh Call from any folder the onionservice-tui: image image image image image Now copy from the terminal the address selecting the url and Ctrl+Shit+C. Paste on Tor Browser and have fun: image


pardon my html/css page, I am still learning how to do it.

radio24 commented 3 years ago

That looks really great!

nyxnor commented 3 years ago

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

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: image

image

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

image

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 image

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

Try leaving the key field blank or with wrong credentials: image

radio24 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

About the long information first comment https://github.com/radio24/TorBox/issues/80#issue-958601443

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

What are the advantages of dialog over whiptail?

nyxnor commented 3 years ago

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

nyxnor commented 3 years ago

green dialogrc to fit torbox

image

# 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

radio24 commented 3 years ago

@nyxnor How should we treat this thread?

nyxnor commented 3 years ago

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