<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Kevin Keane skrev: <blockquote cite="mid:49CA8AAF.70007@kkeane.com" type="cite"> <pre wrap="">Michael Medin wrote: </pre> <blockquote type="cite"> <pre wrap="">Kevin Keane skrev: </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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... </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> 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 <blockquote cite="mid:49CA8AAF.70007@kkeane.com" type="cite"> <pre wrap=""> 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). </pre> </blockquote> </body> </html>