Hi. I'm not an expert, but I'm wondering if you used a Public/Private key pair to replace the username/password login to your servers would it help with your security. If you can control the distribution of the public key to restrict it to your servers (where it is stored in the user's file space, not the systems overall space) the compromise by the intruder is downgraded from complete control of the account to a Denial of Service. I'm thinking of how Putty controls remote logins using a public and private key pair rather than username/password. As I understand it, the public key is not transmitted during the authentication, it is only used at the server end to set up the secure session. [please correct me if I'm wrong here!] David Richardson.
________________________________ From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of sandeep kiran p Sent: August 12, 2010 07:58 To: openssl-users@openssl.org Subject: Re: SSL/TLS with server names picked from DNS We dont have any control on how the server generates its certificates. As said earlier, we only control the client portion of SSL/TLS. Sites where our client application runs, is handed over the location where trusted CA certs are stored and thats all we have. Secondly, as you pointed out, if we were to maintain a list of legitimate server certs, we could have as well maintained a list of server names at the client. The advantage with using DNS SRV RR is, a domain admin can add or remove servers without having to make any changes to the affected client applications. Thanks. Sandeep On Thu, Aug 12, 2010 at 6:04 PM, Scott Gifford <sgiff...@suspectclass.com> wrote: On Wed, Aug 11, 2010 at 11:36 PM, sandeep kiran p <sandeepkir...@gmail.com> wrote: [ ... ] Client would then blindly establish an SSL/TLS connection with that server and would end up handing over the user credentials to it. Note that, as part of the SSL handshake, the malicious serve would provide a certificate signed by the same CA that signed a genuine server certificate. Meaning to say, verification of the malicious server certificate would pass at the client. If you still want to know how, I can explain further. Also note that the malicious server is hosted on a machine with host name similar to the value of SubjectName's "cn" attribute of the certificate it offers. One possible solution would be to use OpenSSL's CA scripts to establish your own CA (the scripts make it fairly simple), and only accept certificates signed by your own CA. You would need to install that CA public certificate as a trusted certificate in all the clients. If this works for you, a nice bonus is that it saves money and time getting the certificates. Another would be to maintain a database of legitimate certificates or their fingerprints and only accept certificates with a matching fingerprint. Of course, if you're going to maintain this database, you could just as well maintain the list of hosts locally and use that instead of DNS, which could be another solution. Hope this helps. ------Scott.
