On Mar 22, 2004, at 2:36 PM, Bernhard Froehlich wrote:
GoochRules! schrieb:
Greetings,[...]
I'm a newbie with this ssl stuff, what I know I learned from using ssh, so please correct me where my assumptions are wrong.
I'm attempting to create a client/server environment where the identity of the server must be verified, but the identity of the client does not matter. So, I figure the server should have a private key, and each client has the corresponding public key.
I think you should take a look at the sample code from the OpenSSL book (http://www.opensslbook.com/code.html, and I can recommend reading the book also). The code how to check a certificate is included in the files client?.c and common.c.
Thanks for the link, this is exactly what I've been looking for.
There is one fundamental difference between the SSH way of doing things (explicitly tell the client which is the public key of the server) and the way SSL usually works (using a Public Key Infrastructure).
Using the SSL protocol the server sends his public key to the client during the handshake and adds a certificate which proves, that this key indeed belongs to it. The client checks this certificate against a list of trusted "Certification Authorities" (so called CAs) to verify it.
This is a bit more complicated then the SSH approach for a single client-server pair, but once you are working with many (and probably unknown) servers explicit distribution of public keys is at least difficult if not impossible...
I am not working with many possibly unknown servers (I have multiple clients that will connect to a single server), so perhaps OpenSSL is simply too complicated a solution for my problem. Allow me to illustrate:
Two quick points:
1) The private-to-public key is a one-to-many relationship, that is, for any private key, many public keys can/may exist.
2) A message encrypted with a public key can only be decrypted with the corresponding private key, and messages encrypted with the private key can only be decrypted with the corresponding public key.
As I understand it, in the ssh model, each client has a unique private key, and the server has all (trusted) clients' public keys. This allows for the server to know & trust who the clients are, so clients can't be spoofed. The clients know & trust the server by default (I suppose hoping/assuming that no one is spoofing the server).
Unfortunately this is not what I want to do. In my environment it is not important for the server to trust the clients. However, the clients do need to verify the server's identity. This matches the model in 1), as the server-to-client is also a one-to-many relationship (similarly, in ssh it makes sense for the client to have the private key for it may connect to multiple ssh servers) So, given 2), there is no need (in my environment) for a CA. The client trusts the server simply because he can decrypt the message that was sent to him.
Once again I'd recommend some reading about Public Key Infratructure, since this concept is not explained in few sentences (or even lines of code).
After reading up on PKI, I'm concerned that OpenSSL is not a solution to my problem. I suppose all I really need is a mechanism to encrypt/decrypt messages based upon public/private keys. Does OpenSSL do anything like this?
Again, please correct my assumptions where they are incomplete/incorrect.
--Matthew Peltzer
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
