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