LabNotes: Adding TLS to Pyminder
Last Updated: 2021-04-16 22:00:00 -0500
While it started as a one-day-build (itself taking several saturday afternoon livestreams), Pyminder is quickly becoming an Actual Project, at least in the sense of needing iterative refinement. I’m not sure anything I’ve ever written - code or otherwise - has stood without revision, so I suppose I should not be surprised. One of those improvements - perhaps the most pressing - has been updating the pyminder code to support the use of TLS.
TLS may seem redundant if the service, monitor, and all jobs are running against localhost. In fact, for good reason, many CA’s won’t issue you a cert for localhost. Such certificates are dangerous, and require some careful construction and handling. I originally created pyminder without TLS support specifically because I do not consider the use of generally-trusted certificates for local host viable or sane.
However, there are a great many use cases where running at least the helpers-based jobs on other hosts will be helpful, or achieve functions not available by running them solely on the raspberry pi. In that situation traffic might be sniffed across the lan, including the shared secret. At present, spoiling the secret spoils access to every message stored in the DB. The intention is not to store sensitive information in these alerts, but all the same, I’d prefer to avoid the egg-on-face.
Considerations
There’s two main drivers for deciding how to implement TLS, beyond whether or not it’s practical for the effort involved versus the security gained in this narrow use case:
- Whatever solution is implemented should allow for user-created certs, and;
- Whatever solution is implemented should allow those who have access to proper certification chains disable that functionality.
Lab environments are, by design, closed off from the world. In my case, I have a trusted CA cert stored locally that I can use to sign other TLS certificates, allowing me to incorporate a very narrow band of projects into a generic trust environment. Some people may not have that. Others may have actually obtained one or more domains and be able to get those certified using normally-trusted certs. It’s all relative.
The implementation itself was actually extremely straight-forward (a nice break after weeks of redesigning this site as a jekyll template): import ssl, create some contexts, and change references to http connections to https connections. What made things complicated was adding logic to allow the user to specify a specific root trust cert - if desired - and adding flags in certain locations to allow the user to go one further and bypass cert validation.
OH GOD WHY
Yeah, that’s what I said.
This application is extremely useful in development contexts. Creating a new x509 certificate is a one-liner operation in openssl and such self-signed certs can be used quickly for iterative development tasks.
There is, however, a better way
What you should actually implement
If at all possible, implement one of the following:
- Register a domain - even if the service itself doesn’t live there - and have an actual CA like LetsEyncrypt issue a certificate for it. Use those certs and keys. Build automation of some kind around the renewal process.
- Create your own CA cert and use it to sign off on other certs, with many of the same considerations.
In either case, I would recommend actually associating the service itself with a FQDN in your configuration of jobs and the monitor, and use hosts entries on any device that needs to connect with the service to tell it where it is, signing the certs against that common name rather than localhost.
This works well, and is representative of how I deal with most of my webservice hosts throughout my lab network, both the virtual network and the LAN.
Pyminder, like all Arcana Labs projects, is being designed as FOSS, intended for use with readily-available microcomputing hardware. However, if you would like to support the development of any of our freely-available software and hardware projects, and you wanted to show your support financially, your best avenue is via my Github Sponsors account or by making a one-time donation to Kensho Security Labs via Ko-Fi.com. There are other financial- and non-financial support options available on our website..