While I agree that secure defaults are preferable, even if only to provide a good example to operators and prove that we as a project are doing all we can to keep them and their users safe, from what I've seen in the field most will be disinterested in running a CA or purchasing and tracking certificates for the various bits of hardware to which these drivers are communicating.
The additional complexity and liability of spontaneous breakage from certificate expiration often outweighs concerns over attacks by malicious entities infiltrating an isolated management network in ways which internal server-to-server and driver-to-hardware HTTPS might mitigate.
I appreciate the degree to which our developers already make security a priority in our software, and recognize that sometimes user demands for other fixes and features pragmatically outweigh some particular security improvements in the absence of specific developers focused on driving and implementing the latter.
While I agree that secure defaults are preferable, even if only to provide a good example to operators and prove that we as a project are doing all we can to keep them and their users safe, from what I've seen in the field most will be disinterested in running a CA or purchasing and tracking certificates for the various bits of hardware to which these drivers are communicating.
The additional complexity and liability of spontaneous breakage from certificate expiration often outweighs concerns over attacks by malicious entities infiltrating an isolated management network in ways which internal server-to-server and driver-to-hardware HTTPS might mitigate.
I appreciate the degree to which our developers already make security a priority in our software, and recognize that sometimes user demands for other fixes and features pragmatically outweigh some particular security improvements in the absence of specific developers focused on driving and implementing the latter.