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.
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). -- Kevin Keane Owner The NetTech Find the Uncommon: Expert Solutions for a Network You Never Have to Think About Office: 866-642-7116 http://www.4nettech.com This e-mail and attachments, if any, may contain confidential and/or proprietary information. Please be advised that the unauthorized use or disclosure of the information is strictly prohibited. The information herein is intended only for use by the intended recipient(s) named above. If you have received this transmission in error, please notify the sender immediately and permanently delete the e-mail and any copies, printouts or attachments thereof. ------------------------------------------------------------------------------ _______________________________________________ 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
