On Mon, August 14, 2023 19:55, Jeremy Laidman wrote:
I agree with others on the need for SSL/TLS these days, or at least some form of encryption. Many organisations now require comms to be encrypted, or at least authenticated, using robust, modern cryptography. In my case, we're periodically asked about our comms, and receive raised eyebrows when we respond.
I am also sympathetic to the notion that if we have to rely on encryption on our network, then we have bigger problems. But there are still reasons why encryption is desirable. For example, when monitoring a device connected via someone else's network. Or even just to slow down an attacker that has made her way onto our network, and perhaps even set off alarm bells when she tries to talk BB in cleartext and without authenticating, with the attempts generating log messages. Another way to view it is, "perfect is the enemy of good". I'd prefer to have encryption and authentication on a network that has an APT ferreting around, than not.
I tend to agree with this as well. Although the interaction is what it is, having anything unencrypted on networks can be a red flag and a barrier to implementation.
The work-arounds are not ideal for a few reasons. But I suspect the main one is that there is no consistent and standardised workaround, that every deployment that requires it tends to use. If everyone simply used the stunnel solution, then it would end up being well supported by the community, with lots of help, documented experiences, how-tos and best practice guides. But I find myself not wanting to make a poor choice, so I haven't made any choice. I suspect the stunnel option is probably the best option, but I have a feeling there will be a performance impact.
Indeed. Performance comes into play with all the options here.
- Setup and teardown for small TCP connections hitting xymond directly
- Signing and authenticating messages received asynchronously (combo messages, xymonproxy, or messages read in from the BFQ), which should be tossed if invalid
As it currently stands, xymon is already very efficient, so it's worth pointing out that the complexity really doesn't have to come in until you start hitting things at scale. If you're on a modern core and handling 90 msg/s, xymond is going to be just fine. If you're trying to push 9000 msg/s, more needs to be taken into consideration.
Furthermore, ensuring that one-way messages are submitted asynchronously to the daemon means that SSL termination and/or authentication can still pretty easily be off-loaded architecturally, even while SSL features are still in development. (HTTPS message submission in particular, with apache handling the ugly part.)
I think a community solution and best practices can be drawn up, but it probably calls for something of a working group among those who are pushing the limits now (or still) and have already worked through some of the kinks in their SSL implementation.
(Memories of stunnel-wrapping qmail-smtpd coming into play here...)
Not wanting to de-rail the conversation, the main point is that encryption/authentication is an important factor for me, and the missing feature is present in alternatives to Xymon. Some of the proposed alternatives are inadequate, but are still given credence due to the ticking the "security" boxes. If Xymon had this one feature built-in (or standardised), and had the occasional bug fix, then it would be treated with much less scepticism.
Agreed.
-jc