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