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