Hi there: It would seem that the solution to this is inherent in how you built this. If the client is in control of which trust anchors are used (and uses a restricted set, instead of the "anything goes" list that you get with most distributions and or Operating systems), then you SHOULD be able to trust that your CA (or set of CAs) will only issue certificates to legitimate hosts and do proper DNS authority validation (does the requestor have a legitimate authority to request a certificate for that domain?).
This is NOT a programming problem, but a policy one. If you wanted to go one up from that, you could require in your user community that all server certificates be issued according to a particular policy that would make the type of DNS attack you mentioned highly unlikely to succeed (such as encoding the SRV and IP address value in the subjectAltName, and making the server holder protect the private key correctly), and then check for that policy value in your client. At that rate, I can see that there would only be an attack vector by a malicious insider at the server's company that was able to attack the DNS, and request a certificate on behalf of that company, which is quite hard to guard against, without going to rather onerous levels. Have fun. Patrick. On August 12, 2010 09:58:15 am sandeep kiran p wrote: > 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. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
