EFForg
HTTPS for the server
Given the sensitive nature of the data in our qmdl and pcap files, it'd be good to get TLS support on the webserver. Looks like there's a few certs already on the device, though they don't look particularly useful for this:
/etc/client.crt
/var/www/certs/self.crt
Hiya! 👋🏻 I don't have a lot of the context, but I'm guessing the device is a hotspot in this case? And you'd connect to its webserver from a laptop?
There are two basic approaches for this kind of device that doesn't naturally have a publicly-resolvable DNS name:
- Operate a service to give a unique name to each device, e.g.
w5ivplxr.devices.net, and have that service help each device with doing a DNS-01 ACME challenge to get a cert. - Generate a locally trusted root, and issue a cert for the device from that root. https://github.com/FiloSottile/mkcert is pretty good for this (though it won't fully automate installing the device's cert).
haha sorry jsha, we were gonna chat w/ you later with more helpful context. but you did hit the nail on the head, and both of those suggestions are great! i'll look for any rust crates that seem similar, since i think ideally the rayhunter daemon would generate/install the cert itself
For (1) you can look at https://words.filippo.io/how-plex-is-doing-https-for-all-its-users/. But for a project like this I suspect (2) is better. The tricky part is that you need to do some things on the laptop (generating and installing the root cert; generating the end entity cert) and some things on the device (installing the end entity cert). But that could be somewhat automated with a laptop-size script, if you have SSH or similar access to the device.
ahh, i did sorta assume that for (2) we could get by with the unpleasant user experience of clicking through the untrusted cert warning in their browser.
Are we still interested in implementing TLS with a trust-on-first-use device certificate? We could generate the root cert during the install process.
If we're trying to protect the confidentiality of the qmdl file download (the output of /dev/diag), this stops someone who can read wifi but can't make a request to the web interface from reading the contents.
yea thinking about this further I'm not actually sure what issue this solves, If you can read wifi packets then you are already on the network so you could just download the QMDL yourself, I guess the only thing this does is prevent someone on the same network from MITMing the connection and inserting a malicious qmdl file but that seems like a pretty esoteric attack
This would be useful if you provide for authentication between the user and the webserver before downloading the QMDL; it would protect the authentication data.
there is no authentication as of now since we are using access to the wifi (wpa protected) as our security model.
I think a more realistic threat would be malicious apps or websites trying to scan for Rayhunter without the user knowing. there, auth can be useful. not sure about TLS
