Don't send debug log in clear-text

In advanced/Scripts/piholeDebug.sh, the finalWork() function uploads a plaintext version of the debug log to tricorder.pi-hole.net:9999. Specific code is:

tricorder=$(cat /var/log/pihole_debug.log | nc tricorder.pi-hole.net 9999)

This seems pretty unsecure. I would like to suggest using a REST API over HTTPS instead of opening a raw connection to port 9999.

Calling @DanSchaper so he can comment on this.

Nice feature, not sure what the attack vector is with the netcat send unless someone is sniffing the wire. Would have to totally rewrite tricorder though. So unless there is a drop in replacement for fiche it's probably a long way from implementation.

The idea is to not transmit the debug log at all, and have the process self-contained, and that's what I'm working as priority now.

Is it possible to replace "nc" with "openssl s_client -connect" somehow ?
Other side would need "openssl s_server" of course.
Would need a cert though for tricorder.pi-hole.net (could even be a self signed one).
Or if pi-hole.net cert is a SAN one, add as alternate name.

I don't think it's possible in the current implementation, since the server listening at tricorder.pi-hole.net:9999 doesn't support SSL (at least that's what I gathered from the source code of fiche).

The solution I was thinking of is putting fiche behind a reverse proxy (I'm currently working on a PoC of this), but if the debug log parsing will be self-contained soon as @DanSchaper mentioned, then it might not be worth implementing at this point.

Edit: @deHakkelaar Whoops just saw your "would require openssl s_server" edit now.

Whoops was about to say something else :smiley:
But yeah a proxy might do the trick catching SSL or whatever.

Ps. whats fiche ?

Ask your favored search engine :slight_smile:

In case you don't find it, try to search for "github fiche". If you still don't find it you will have to change the search engine you prefer!

Link for the lazy?

Quick! We need to get @deHakkelaar to the burns unit!

Basically, Fiche is what is listening on this end to recieve the debug logs.

I think I need google training as I really tried searching but got lost on pages in French and then decided to give up :slight_smile:

https://duckduckgo.com/?q=fiche
https://duckduckgo.com/?q=fiche+linux

And am lost again :frowning:

https://duckduckgo.com/?q=burns+unit

But i did have a bit of luck googling openssl & c++:

But how to merge that code with fiche is beyond my capabilities.
Most advanced ever me coding in c++ was to merge two lists into a balanced binary search tree :wink:

in your defense fiche is the french word for record as in a data record

I was able to get hitch working on the server-side, sending data from a local openssl s_client. This doesn't appear to validate the server certificate, so perhaps using gnutls-cli is preferred over openssl s_client (I wasn't able to test the former though, since I used a self-signed cert for testing).

It works as follows: hitch listens on port 8443 (this port should be externally accessible). SSL termination between clients and the hitch server use port 8443. Once the SSL/TLS connection is established, the connection behaves just like netcat with the raw socket; clients then send plaintext, and hitch sends the data to its configured backend as a raw TCP connection. In my test, I used the default host/port (localhost:6081) for the backend server port, and started up a netcat listener on port 6081 to emulate the tricorder server.

The netcat listener on port 6081 received the plaintext data as expected.

So a potential solution (that wouldn't require too many client/server-side changes) would be to put hitch in front of the "tricorder" server, and modify the client so that it uses openssl s_client or gnutls-cli instead of nc to upload the logs to the server.

1 Like

Sweet.
Nice project this hitch and need to remember whenever I want something uncrypted crypted.

EDIT: Found the syntax for trusted certs:

openssl s_client -connect tricorder.pi-hole.net:8443 -CAfile /etc/ssl/certs

But need to make sure the clients have latest installed eg:

sudo apt-get install ca-certificates

Na doesnt work.
I was still able to connect to my self signed https server.

I implemented an alternative upload solution using SSL. We are currently testing it and will make it the preferred option when we are sure that it is working reliable. The non-encrypted method (using netcat) will stay available for fallback.

3 Likes