NRPE vs. check_by_ssh

[Kevin Keane]

Michael Medin wrote:
> 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?
I stand corrected.

Interesting... DH stands for Diffie Hellman (usually, that refers to the 
Diffie Hellman Key Agreement algorithm). I didn't know that openssl 
supported ADH (the A stands for anonymous), and I wonder how many other 
SSL implementations have it, since ADH really doesn't make much sense. 
According to the openssl documentation, ADH is actually the one cipher 
not included in the default list of ciphers. And with good reason, 
because, you are right, it does not do any kind of authentication, and 
therefore actually provides no security (not even from eavesdropping, 
because a man-in-the-middle attack is trivial).

Diffie Hellman is actually used for most SSL connections, but in a 
different form.

Basically, the idea behind DH is that both parties agree on two 
pre-shared large prime numbers. In the case of ADH, these same numbers 
are known to everybody in the world. In other forms of DH cipher, these 
two numbers are only known to the two parties exchanging information - 
that's what actually gets encrypted with the public/private encryption 
based on the keys from the certificates.

When client and server want to communicate, both separately generate 
random numbers. These numbers truly are secret. The client then applies 
some mathematical magic between the random number and the two primes, 
and the server does the same on its end. Then the server sends the 
result of this magic to the client, and vice versa. Finally, both of 
them multiply the result of the other side's magic with their own random 
number. In the end, both sides end up with the same result, even though 
neither ever sent its random number. This final result is the key. I 
used to teach a network security class that included the math behind DH, 
but I still can't remember the details. Diffie and Hellman must have 
been brainiacs to come up with that. It basically is a very tricky way 
to get obscure the random numbers.

Yes, it would indeed work without any certificate. You could think of it 
as a certificate with a zero-length public/private key (and with 
zero-length everything else, too).

openssl does have a key store, in the form of a certificate store. 
Creating and installing proper certificates is not difficult. You can 
probably use self-signed certificates here. Since you have control over 
both clients and servers, trusting the certificate shouldn't be an issue.

-- 
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 at 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