Raspiblitz: List Hidden services

[openoms]

Thought:
should create a file on the HDD to list the different Hidden Services to be displayed form the GUI.
eg.: HiddenServices.info

There could be two options (or mix):

• every service gets a different .onion:PORT - as it is currently

• could use one Tor directory (same .onion) for most services
  and list them on different ports, just like when using the LAN IP.

Might be better to keep them separate despite the added complexity so services can be shared individually. Tor v3 adrresses are not memorable anyway.

[rootzoll]

Why make a seperate file? If its a config thing that should survive updates I would recommend to put this info into the raspiblitz config file. Or can you give more context why this is usefull?

[openoms]

Why make a seperate file? If its a config thing that should survive updates I would recommend to put this info into the raspiblitz config file. Or can you give more context why this is useful?

Sure, we could use the raspiblitz.conf. It already contains sensitive information like the dropbox API key, publicIP etc.

Question is if it is even useful to record the Hidden Service addresses separately or just use something like
echo "$(sudo cat /mnt/hdd/tor/HIDDEN_SERVICE_DIR/hostname):PORT" ?

The main idea here is just to add an entry to the GUI where the available services can be shown maybe with a QR option too to help communicating to Tor Browser on mobile.

[rootzoll]

If the information about the Hidden Services can get gained from the running system that should be done that way. Putting the info into the raspiblitz config file would only make sense if those services are a special config that should get re-installed during a update or recovery.

[openoms]

for BTC-RPC-Explorer and RTL the Hidden Service is set up to forward to the port 80, so only the individual .onion need to be used, no need to input the port to the Tor Browser: https://github.com/rootzoll/raspiblitz/pull/867/commits/5693f3891767503087befebc1646eb78c81b4aa9

For electrs the ports 50001/50002 will be used with Tor as well to avoid the confusion with Electrum.

[openoms]

now BTC-RPC-explorer and RTL displays the Hidden Service address too on installation when Tor is active.

@rootzoll do you know how could we make the address from the dialog box copyable without using a http:// prefix?
A problem with that is that clicking it would open the Hidden Service address in the normal browser leading to an error and possibly information leakage.

For now can be displayed again with:
sudo cat /mnt/hdd/tor/btc-rpc-explorer/hostname
and
sudo cat /mnt/hdd/tor/RTL/hostname

I think an added menu option for TOR would be a right way to show these again in the terminal on-demand, maybe with a QR too for mobile.

[openoms]

This is addressed in https://github.com/rootzoll/raspiblitz/pull/896 so closing.

Found that using whiptail rather than dialog makes the Tor addresses (and any text) possible to copy from the messagebox.

[bitcoinheiro]

Hi @openoms - before the update, I set the hidden service only with port 50002 as per your guide and the electrs guide (if I'm not mistaken). Now I see that 1.4 sets both ports 50001 and 50002 to the same hidden service.

HiddenServiceDir /mnt/hdd/tor/electrs
HiddenServiceVersion 3
HiddenServicePort 50002 127.0.0.1:50002
HiddenServicePort 50001 127.0.0.1:50001

What is the difference between them? I cannot find any info online.
With this change I can only access the hidden service with my electrum wallet using the 50001:t port and not 50002:s port as before.

Thanks for your help on this

[openoms]

The difference is that 50001 is the TCP (unencrypted connection before Tor)
and the 50002 is SSL which is passed through Nginx before Tor.
Test if your Nginx is functional with:
sudo nginx -t

Found that Electrum mobile requires SSL even through Tor (50002).

If connecting with the desktop app either port is ok through Tor as it deals with the encryption itself.

[bitcoinheiro]

Yes, this is the issue probably. Just updated from 1.3 with manual electrs to 1.4...
Created a new cert key using the script at home/admin/config.scripts/internet.selfsignedcert.sh
Certs test ok now.

But I still cannot connect through port 50002:s via onion after a restart and wait to sync. 50001:t works... I can connect to port 50002:s if I use my local network.

Problem seems to be with the onion routing of that port - What could it be?

[openoms]

@bitcoinheiro 50001:t becomes 50002:s by being SSL encrypted by Nginx.
What does:
sudo nginx -t
show?
And:
sudo systemctl status nginx?

[bitcoinheiro]

@bitcoinheiro 50001:t becomes 50002:s by being SSL encrypted by Nginx.
What does:
sudo nginx -t
show?

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

And:
sudo systemctl status nginx?

nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2020-02-23 12:08:32 GMT; 6h ago
Docs: man:nginx(8)
Main PID: 600 (nginx)
Tasks: 5 (limit: 4915)
Memory: 9.5M
CGroup: /system.slice/nginx.service
├─600 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─601 nginx: worker process
├─603 nginx: worker process
├─604 nginx: worker process
└─605 nginx: worker process

Feb 23 12:08:31 bitcoinheiro systemd[1]: Starting A high performance web server and a reverse proxy server...
Feb 23 12:08:32 bitcoinheiro systemd[1]: Started A high performance web server and a reverse proxy server.

I still cannot connect through port 50002:s via onion after a restart and wait to sync. 50001:t works... I can connect to port 50002:s if I use my local network.

Problem seems to be with the onion routing of that port - What could it be?

Thanks

[bitcoinheiro]

Additional info, the Electrum status option from the main menu prints:

##### STATUS ELECTRS SERVICE
configured=1
serviceInstalled=1
serviceRunning=1
isSynced=1
localIP='192.168.XXX.XXX'
publicIP='XXX.XXX.XXX.XXX'
portTCP='50001'
localTCPPortActive=1
publicTCPPortAnswering=0
portHTTP='50002'
localHTTPPortActive=1
publicHTTPPortAnswering=0
TORrunning=1
TORaddress='XXXXX.onion'

[openoms]

Tor provides strong encryption so there is no.need to use 50002 over Tor.
The Electrum wallet on Android needs SSL even through Tor, but cannot deal with chaning certificates. Need to change the Tor address or reinstall the app.
Is your Tor functional otherwise?
sudo systemctl status tor
sudo systemctl status tor@default

Check for a suplicate entry of 50002 in:
sudo nano /etc/tor/torrc

[bitcoinheiro]

Tor seems to be functional. All fine with other services. Even with port 50001.
There's an error message about /run/tor not being owned by the user (bitcoin, 1002) - but by debian-tor (111) - but this was always there (previous versions) as far as I recall.

No duplicates for port 50002.

The issue is probably the cert key that's not associated with the keyfile for the onion service.
Is there a way to restart only the electrs tor hidden service?

[openoms]

To restart Tor:
sudo systemctl restart tor

to create a new Tor address for electrs:
sudo rm -rf /mnt/hdd/tor/electrs
and restart tor as above.

[bitcoinheiro]

Great success! Now it works.

If anyone else experiences this when upgrading from previous version and nginx is not functional because of missing key.

1. Test if your Nginx is functional with:
   sudo nginx -t

If missing key (self-signed), then:

1. Create a new cert key for nginx using the available script:
   cd /home/admin/config.scripts/
./internet.selfsignedcert.sh

2. Create a new Tor address (and keyfile) by removing old:
   sudo rm -rf /mnt/hdd/tor/electrs

and restart Tor for changes to take effect and new address to be created:
sudo systemctl restart tor

Thanks for your support!

PS. In hindsight and analyzing the local Electrum Wallet files, I could have probably fixed this without doing step 2 above by removing the certificate associated with the onion address located at (\Electrum\certs) local config folder (next to the folder where the wallets are stored by default) - and reconnecting. The problem was probably the local cert not matching with the remote one.