> As for the approach I'm sketching, I was under the impression that SSL > could function as easy as that, where the server has got a self-signed > certificate with a public and secret key, and then whatever client, > with a certificate on their own, could connect to the server with SSL > and get an encrypted connection. Am I wrong?
Dangerously wrong! > Also, is my model naive considering this: > > At the server side I don't care that any client can connect. Whoever > connects still has to supply a username/password that is matched with > a back-end database to grant them access to the service. So you need to make absolutely sure that the client sends this username and password TO THE SERVER and not to an adversary. You *need* a way for the client to ensure that it's actually talking to the server. > As for the client side, all servers will reside within our network, > and the clients will connect to our IP-numbers (not domain names). > Either they trust us when we hand them an IP to connect to, or they > don't. > > Is it still any need for certificates for authentication? Then what's the need for encryption? In this case, both the encryption and the certificate serve the same end -- to make sure the username and password go to the server only. How can you need one and not the other? DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
