<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<div class="moz-cite-prefix">On 14/3/19 16:00, Jeremy Laidman wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACO=ejyKfGTAEqgLqsvQ1EMOq9LfdqeGOQRrTJnu5U7UPy47BQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div dir="ltr">On Wed, 13 Mar 2019 at 10:57, Adam Goryachev <<a
href="mailto:mailinglists@websitemanagers.com.au"
target="_blank" moz-do-not-send="true">mailinglists@websitemanagers.com.au</a>>
wrote:<br>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">IMHO, when using
"security" tools, we really need to make sure we rely <br>
on a third party "library" to do this, security/encryption
is a fast <br>
moving area, and we really don't want to be using something
5 years old <br>
because nobody understood how to update it from TLS1.1 to
TLS1.2 or from <br>
using 3DES to using AES or whatever the issue becomes.</blockquote>
<div><br>
</div>
<div>I'm not sure I agree that encryption is fast-moving in
all areas, or even most of them. Yes, there are bugs found
in encryption software, short-cuts found in brute-forcing
hashes, new algorithms every now and then, and the
occasional implementation problem (wep, wpa, ssl); all of
these scenarios require some kind of upgrade. However, the
math(s) behind the basic crypto primitives is fundamentally
sound (well-vetted and in some cases proven), particularly
around simple use cases. Even with deprecated hashes (MD5,
SHA1) they're not considered insecure, just that a
well-resourced, and highly motivated and patient actor can
brute-force them in time. With careful selection of hashing,
encipherment and session key management algorithms, a good,
strong solution can be implemented using >20-year-old
crypto.</div>
<div><br>
</div>
<div>However, there's other value in being able to use a
separate library, and allow upgrades to the library to
improve security or squash bugs, without having to recompile
Xymon.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"> Also, xymon may <br>
not be updated as easily/quickly as what other system
libraries might, <br>
so again, better to let the OS (system) provide the relevant
tools to do <br>
this, and we just become another consumer.<br>
</blockquote>
<div><br>
</div>
<div>Agreed.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
As such, an obvious choice would be openssl, or something
similar, where <br>
it is widely supported across many platforms, well
maintained, and <br>
likely to be well maintained in the future.<br>
</blockquote>
<div><br>
</div>
<div>Not to mention, OpenSSL is already used by Xymon for
things like https checks.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">I think there are two
separate requirements when referring to encryption:<br>
1) Encrypt the content so anyone listening can't see your
log file <br>
</blockquote>
<div><br>
</div>
<div>Yep.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">2) Signature - ie,
ensuring the message actually came from "one of my <br>
clients" or taking this further it came from "this specific
client".</blockquote>
<div><br>
</div>
<div>Yep.</div>
<div><br>
</div>
<div>And there are situations where only signing is required.
This not only ensures no tampering, but it also ensures that
a large message has not been truncated by some process. On
some systems, I often get a red "procs" test because the
[ps] or [netstat] sections were so long that the data
message was truncated. I'd prefer to skip a truncated
message entirely than to react to conclusions based on
incomplete data, at least in this case. A [signature]
section at the end of the message (or heck, even just an
[end] section) and appropriate handling in xymond, would fix
this.</div>
<div><br>
</div>
<div>Having encryption also gives us signing, and having
signing also ensures no tampering. If encryption and signing
aren't required, the overhead of managing keys makes it
burdensome to detect truncated messages. But if we bake in
encryption, we get everything. If we use x509 certificates,
we get all of this, plus potentially PKI (federated trust,
revocation, expiry). It's a hierarchy, and the higher up we
go, the harder it is to implement (both in the code, and
rolling it out to nodes), but the more features we get.</div>
<div><br>
</div>
<div>(As an aside I like the idea that an x509 certificate can
be used to tie a client data message to an entry in
hosts.cfg, either allowing the commonName field to override
the value in the client data message, or having a "CN" tag
in the hosts.cfg file to match the client message to.)</div>
<div><br>
</div>
<div>Also, key management needs to be considered. It's a
different task to encrypt traffic between a xymonproxy
server and xymond server, to rolling out encryption to 500
devices each running a Xymon client.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">- Do we need full PGP
security for this? At least during setup, we can <br>
easily start with a known good/clean connection, or rely on
the admin to <br>
ensure that some "shared secret" is valid on both ends.<br>
</blockquote>
<div><br>
</div>
<div>So, like bootstrapping the key rollout procedure. This
could leverage the existing "download" client message type.
The client should know when her certificate is soon to
expire, and can just ask for a new one with: "xymon download
/meta/clientcert.x509" and the xymond process could sign a
new cert on-the-fly and send it down the wire.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
- We can already send data back to the client after the
client <br>
successfully delivers data to the server. If the "current"
data the <br>
client is sending is considered "clean/secure" then we can
easily send <br>
back a renewed "certificate".<br>
</blockquote>
<div><br>
</div>
<div>Yep, that's another option.</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">So...<br>
a) Start with a simple shared secret that the admin can
create (or is <br>
auto-generated) on server install.<br>
b) The admin configures this secret onto each client that is
added, <br>
along with adding the hostname to the server (xymon-hosts
file).<br>
</blockquote>
<div> </div>
<div>b1) admin configures ssh public key on client</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
c) When the client connects to the server, it uses the SSH
"encryption" <br>
to protect the conversation, sends the shared key plus the
normal "1st <br>
set of data reports". The server responds with a client
"certificate".<br>
d) When the client next connects to the server, it uses the
SSH <br>
"encryption" to protect the conversation, and signs the data
with the <br>
certificate it received from the server. If the certificate
is due to <br>
expire in X days (configurable on server) then the server
will provide <br>
an updated certificate to the client. The client can
continue to use the <br>
"old" certificate until expiry, but should allow plenty of
time to <br>
transition to the new one. In reality, this could be one or
two days <br>
only, since most clients report every 5 mins.<br>
</blockquote>
<div><br>
</div>
<div>e) Delete the shared secret.</div>
<div><br>
</div>
<div>I think there's too much going on here, but not sure
where. It seems to me that there's already an authentication
process going on using asymmetric keys via the ssh
authentication mechanism. It would seem that an extra key to
authenticate the client is redundant, because the client has
already authenticated itself.</div>
</div>
</div>
</blockquote>
<p>Actually, I was suggesting the SSH style encryption which would
be used for encryption only, not signing, in my mind that was a
separate process which works with the contents. In my thought
process, the SSH encryption is kind of like HTTPS, where any
client can connect to the server (without authentication) but
still ensure that the content is encrypted/protected.</p>
<p>Within this, there would be another signature to sign the content
which is used to confirm it came from client abc and not random
unknown, nor from known client xyz.<br>
</p>
<blockquote type="cite"
cite="mid:CACO=ejyKfGTAEqgLqsvQ1EMOq9LfdqeGOQRrTJnu5U7UPy47BQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Also, could the shared key be a problem if it gets out?
Let's say I have 50 devices all using certs, but still with
the shared key still in place, just in case of certificate
corruption requiring a new bootstrapping procedure. Now,
let's say someone hacks into one of the devices and
retrieves the shared key. That key can now be used to
bootstrap any new device to trust a rogue certificate
authority, or at least to sign reports that are rejected by
Xymon for being signed by the wrong certificate. Perhaps
this could be used as part of a man-in-the-middle attack?</div>
</div>
</div>
</blockquote>
I think the shared key is only enough to "add" a client, and only if
that client is already listed in the xymon-hosts file. So, the value
of this shared key is pretty low. Worst case, it could allow a rogue
client to get a valid certificate for a host that is listed but
doesn't use encryption/certificates, either because it is a old
client that doesn't support it, or it is a platform that isn't
supported, etc...<br>
<blockquote type="cite"
cite="mid:CACO=ejyKfGTAEqgLqsvQ1EMOq9LfdqeGOQRrTJnu5U7UPy47BQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I think I'd be more comfortable if the shared key was
unique to each device. But ultimately, I think it shouldn't
be required, because the ssh keys are per-device keys, and
should be sufficient to give the same effect.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Or... we could configure
a shared secret in the xymon-hosts file for <br>
each client (different "password" for each client) and the
client simply <br>
encrypts all data it returns with this shared secret.
Advantage is <br>
"simplicity" disadvantage is much less secure.<br>
</blockquote>
<div><br>
</div>
<div>Why less secure? I'm not disagreeing, just want to
understand why.</div>
</div>
</div>
</blockquote>
From my (limited) understanding, a lot of crypto attacks are based
on dictionary attacks. Since pretty much 100% of our content is
plain text, and a lot of that will be "recent dates, repeated a lot
throughout the content", ie, log files... then it would make it
easier to find out the "key" if you know (or can guess) the plain
text that was encrypted. My understanding is that this is less
relevant when you use some of the more modern encryption processes
along with PKI. I guess everyone can know the content of the
index.html that a user will get over https, so I assume that https
encryption processes are able to overcome this issue.<br>
<blockquote type="cite"
cite="mid:CACO=ejyKfGTAEqgLqsvQ1EMOq9LfdqeGOQRrTJnu5U7UPy47BQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Another option is to do the ssh host key thing, where the
first time a connection is made to a host, everyone just
accepts the new host key into their known_hosts file
(presumably after checking the fingerprint out-of-band,
lol).</div>
<div><br>
</div>
<div>So one way to do this for the Xymon client would be to
have the client fetch its unique key the first time it
connects to the server, and use it to sign from then on. I
think this much the same as the "a" through "e" steps you
outlined above, except not necessarily using certificates -
but it could be a certificate, or a private key, or both
client private key and server public key, or a unique
per-client shared key, or a one-for-all-clients shared key.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
Right, it could even be that some tool on the client connects to the
server and requests the certificate, and you a second interactive
tool on the server will receive/process that request, once the admin
approves it, then the response is sent back to the client. I mean,
who doesn't have two ssh sessions open (one client and one server)
when adding a new client?<br>
<blockquote type="cite"
cite="mid:CACO=ejyKfGTAEqgLqsvQ1EMOq9LfdqeGOQRrTJnu5U7UPy47BQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>A few more comments to consider.</div>
<div><br>
</div>
<div>* It's easy to do crypto badly. Whatever is done here (if
anything), we shouldn't be rolling our own crypto, and
instead we need to use standard crypto primitives provided
by a well-known and highly-regarded library such as OpenSSL.
Even that is not sufficient; one could choose the wrong type
of cipher (eg a block cipher where a stream cipher is
appropriate), or use a hash function that requires
sufficient source data volume to properly initialise, to has
a password that could be only 8 characters. There are
standardised ways of doing crypto that are recognised as
optimal, or at least sound, such as PBKDF2 for deriving
robust keys, salting hashes, and so on. If it's going to be
built in, it needs to be done right.</div>
<div><br>
</div>
<div>* Certificates don't need to be x509. Secure shell (ssh)
can support certificates for authentication, but they aren't
x509 certs, and from what little I've read, their use seems
to be further away from the "full-blown PKI" end of the
spectrum and closer to simple asymmetric key pairs. The one
thing that ssh's certs cannot do is revocation. This means
if I use the same cert on all boxes I login to, and my
private key is exposed, I need to change my key on each and
every one of those boxes. One solution to this is suitable
key management, eg storing my private key on an HSM or
Yubikey; another is to use a unique key for each box I want
to authenticate to (essentially giving myself multiple
identities). This problem isn't necessarily relevant to the
discussion about securing client data messages, but it
highlights the fact that this is complex, and different
requirements may benefit from having quite different
solutions available.</div>
<div><br>
</div>
<div>* Certs give us the <i>potential </i>to use PKI, but to
get all the benefits of PKI one also needs ancillary
services such as an OCSP or CRL server and proper key
management. However, many organisations don't have PKI
infrastructure, so the benefits of PKI such as revocation
lists, don't warrant the overhead, and self-signed certs or
other forms of key pair technology, should be available for
those who aren't able to afford or run a complete PKI
solution. Non-PKI essentially becomes mutual authentication
between pairs of nodes (one always being the Xymon server).
If a client key is compromised, both ends need remediation.
If a server key is compromised, all clients need
remediation. This is usually good enough for most smaller
organisations.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<p>I mostly understand, and think I agree with most of the above. At
the end of the day, the solution needs to be:</p>
<p>a) backwards compatible, so you can still accept plain, unsigned,
unencrypted connections from the coffee maker in the corner</p>
<p>b) simple to install and maintain, and robust. If it's too hard
to install or maintain, then people won't want to use it.<br>
</p>
<blockquote type="cite"
cite="mid:CACO=ejyKfGTAEqgLqsvQ1EMOq9LfdqeGOQRrTJnu5U7UPy47BQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>* I see no reason why we can't support ssh just with
sufficient documentation. The same goes for or stunnel,
IPSec, OpenVPN, etc. They're all useful to people in
different circumstances. This just requires documenting each
one. There may be cases where a script or two would benefit
these different methods (an extreme case is
xymon-rclient.sh, which IMHO is waaaay too big to be
included as a simple "helper" script for one of these
methods).</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<p>Possibly we could run the existing 1984 listener in a wrapper
which handles all the "encryption", and then within xymon itself,
there are a small number of additional "types" that can be sent
from client, or returned to the client to add the additional
certificate/signing stuff.</p>
<p>So, if we can easily add a command line flag that says enable
"STARTSSL" command, that in itself would be a huge step forward.
IMAP and POP and I think SMTP can all do this, so it should be a
pretty well defined protocol, and should be well supported in
common libraries.</p>
<p>Again, lets not try and jump and touch the moon, one step at a
time...<br>
</p>
<blockquote type="cite"
cite="mid:CACO=ejyKfGTAEqgLqsvQ1EMOq9LfdqeGOQRrTJnu5U7UPy47BQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>* If we are to do this right, we should include support
for both client-side and server-side authentication.</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">PS, as for IPv6, I am yet
to see any decent level of support here, I <br>
tried to start using it years ago, and it just never
happened. Turns my <br>
routers (Cisco Meraki: <a href="http://www.meraki.com"
rel="noreferrer" target="_blank" moz-do-not-send="true">www.meraki.com</a>
details at <br>
<a
href="https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility</a>)
<br>
still don't support IPv6 either, so it still doesn't seem to
be as <br>
important as claimed by everyone 10+ years ago when they
said we would <br>
run out of IPv4 addresses.... It's hard to "change the
world", I mean, <br>
we still have SMTP and DNS ;)<br>
</blockquote>
<div><br>
</div>
<div>Yep, this is true, overall IPv6 take-up continues to be
slow. However, the thing about Xymon is, it needs to be able
to monitor a wide range of devices and services. So if you
have 1000 nodes to monitor, and just one of them runs IPv6,
your Xymon has to support IPv6 in order to detect a service
outage. This is the situation I'm in. My work-around is to
disable "conn" checks for such hosts, and run a script that
does a ping6 and creates the "conn" status messages. Also,
certain sectors of the industry are likely to have a
relatively large IPv6 footprint, such as telcos, and IoT
network providers.</div>
</div>
</div>
</blockquote>
<p>True, there are many Meraki customers requesting IPv6, I'm just
acknowledging that it is a much slower process than it seemed to
be advertised. It originally seemed like we would all be forced to
IPv6 within a couple of years.</p>
<p><br>
</p>
</body>
</html>