Kevin Keane skrev:
Michael Medin wrote:
Kevin Keane skrev:
Wouldn't the SSL certificates provide authentication comparable to
SSH keys? I'm not familiar with how NRPE uses SSL, but I would assume
that you could also use client certificates?
I am no expert but AFAIK it merely encrypts the traffic ie, no
certificates at all. If someone knows hoe to use certificates please
feel free to let me know so I can add it to NSClient++ but what I have
seen it is not possible...
No, that wouldn't be possible. Encryption always requires some form of
key or another. In SSL, the key is embedded in the server's certificate.
The client certificate is optional; it also contains a second encryption
key. If you use client certificates, in effect the traffic is doubly
encrypted.
Humm.
The cipher used is ADH which is "anonymous DH cipher suites" in addition
to a "pre shared *known* secret" (read un-secret). Again I am no expert
but I always interpreted the "secret key" (DH) thingy as a key and not a
certificate but mayhap I got it all wrong? (in which case it might be
possible to use proper certificates?)
And I am actually using openssl but mayhap it has a built-in keystore as
well?
// Michael Medin
You almost certainly *are* using certificates in NSClient++. But if you
are using the standard Windows API functions, Windows transparently
hides most of that complexity from you; the MSXML object and its ilk
take care of it. You would be using the certificates from the Internet
Explorer key store.
Actually, when I described how the SSL connection can use single or
double encryption, I lied. It is more complicated than that. The SSL
keys are extremely long (1024, 2048 bits or more), and they have to be
because by nature they don't change over years. SSL keys in the
certificates are also the public keys of a public/private key pair.
These factors make using the SSL key for encryption *extremely* slow.
That is why in reality, public key encryption is only used for extremely
short messages (measured in bytes, not kilobytes).
To work around that, the client and the server generate yet another
random key, this time a symmetric key (which has to be kept secret from
anybody). This symmetric key is usually 128 bits or 256 bits. Unlike
public-key encryption, symmetric encryption can be implemented very
fast. This key is sent using the slow public-key encryption. The actual
traffic is then encrypted using this second key, which will be thrown
away after the connection ends.
Incidentally, SSH works basically the same way. The only substantial
difference is that the public keys comes from the authorized_keys file
instead of a certificate.
Both SSL and SSH actually allow you to use various different encryption
algorithms and mechanisms for exchanging keys under the hood. You may,
for instance, see DHE for the key exchange, RSA for the public/private
encryption, and AES for the symmetric encryption and SHA for hashing
(which I haven't even touched on).
------------------------------------------------------------------------------
_______________________________________________
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
