MQTT - securing communication by configuring passwords

[t-fine]

As it stands the mqtt service is currently using the unencrypted port 1883 for communication, so it would be a nice first step to be able to configure mosquitto.conf to use passwords based authentication while sending messages to at lease have one level of security barring any random message from being sent on a given topic.

Some more information can be found under Step 2 — Configuring MQTT Passwords here:
https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-the-mosquitto-mqtt-messaging-broker-on-debian-10

With that in mind, this should be done in a way that makes it simple for users to accomplish. For instance there could be a shell script would collect these values from environment variables, and write the mosquitto.conf file, then launch the broker with that config file.

With a mechanism like this in place, that should pave the way for additional mosquitto.conf options to be exposed in the future.

As this issue has security in mind, perhaps as a stretch goal here, enabling the use of the encrypted 8883 port using SSL/TLS and the use of certificates and keys could be looked into.

[clementkng]

@MegaMosquito I believe you originally discussed securing mqtt communication with Troy, and I was able to get some password-based authentication (Step 2 in the securing mqtt tutorial he linked above). However, to add SSL we would need some prerequisites as detailed in that link, including a domain name pointed to our server and an autorenewable Let's Encrypt SSL certificate for that domain and mqtt. I'm not too sure how we would be able to obtain those prereqs, so I was wondering if you had any ideas?

[TheMosquito]

@clementkng Personally, my request was to enable others to use the full breadth of all of the features in the broker, not to have you create a domain, a cert, etc. and do everything for them. I just want you to enable them to do anything and everything that anyone might want to do with the broker. Perhaps you could expose features using "userInput" variables, or perhaps it would be better to just expose the broker config file and tell them to edit that file as they wish before building the service and publishing it.

[clementkng]

@TheMosquito I'm leaning towards exposing the broker config file and telling the users to edit for now, at least as an incremental step, and then perhaps we can investigate using "userInput" to make it more clear that SSL is supported.

[TheMosquito]

@clementkng The config file plan sounds good to me.