This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Overview:
Over the course of this cycle, we have implemented a working mTLS authentication system in the Herd management system, which allows agents to verify that they are talking to the genuine controller/backend, and the backend to verify that the same endpoint is checking in.
Specific Tools Used and Implementation:
Our certificates are standard RSA-based SSL certificates, generated by the backend for itself, the management web interface, and the endpoint agents. We chose these because it allows us to use standard libraries for each of the three programming languages used for each of the Herd components, while securing their communication back and forth between each other.
To ensure that endpoints can seamlessly enroll with the backend, the backend also exposes a plain HTTP endpoint for agents to register themselves and receive a certificate.
We find this to be an acceptable compromise, as an attacker would gain no benefit from allowing their endpoint (or API clone) to be controlled by the backend server issuing commands. Additionally, the management API (by which administrators add tasks to be executed) is restricted to localhost by default, as it is expected in most deployments that the backend and management UI are run on the same host system.1
One current limitation of our system is that we have not yet implemented a cert roll-over functionality, so if the agent version gets upgraded, it may no longer trust the backend’s certificates. In the future, this will be fairly trivial to fix, by instructing the backend to issue a warning to all agents that it is being upgraded, and then for the agents to re-request a certificate using the enrollment HTTP endpoint after a certain period of time.
Proof of Work/Documentation:
This screenshot shows certs.py, the helper file that uses the hashlib and cryptography python modules to generate new certs, and you can see on the left-hand side the certificate files and their matching key files in the certs/ directory.
(Functions are minimized so that all signatures can fit into one screenshot, you can see the whole file here).
This screenshot shows the backend running, loading its existing certificates, and then receiving an enrollment request from the agent shown in the bottom right-hand corner. Then, the agent is exited with Control+C, and we show that the received certificate has been placed in /etc/herd/certs.
-
If they are not, it is fairly easy to change the backend’s config to accept a different IP for the management program, and to copy the
operator.keyandoperator.crtthat the backend requires onto whatever system runs the management UI, for all management-related API routes to work. ↩︎
Capped Stone Wiki
FA25 Content
Planning & Literature Review
Progress Reports
SP26 Content
The stones are capped....