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