On 12-08-2010 05:36, sandeep kiran p wrote:
Hi,
Ours is an LDAP client application that fetches LDAP server names on the fly
using DNS SRV Resource Records. We then randomly pick one the servers
returned from DNS, establish an SSL/TLS connection with that server and then
perform a bind operation using user credentials (DN and password). User
credentials are protected since everything goes encrypted between the client
and server.
Recently we discovered that such a mechanism could be vulnerable to a DNS
spoofing attack where an attacker could modify (or drop) the server list
returned by the DNS and inject his/her own malicious directory server name.
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.
In such a case, how can I stop this attack? Is it against SSL/TLS philosophy
to fetch server names on the fly as we do above using DNS as it defeats the
very essence of matching hostnames with the "cn" attribute? Or is there way
at the SSL/TLS level for the client to identify that it's talking to a bad
server? Or, as a last option should I put some check in the client
application itself that would identify the bad server?
The problem is that SSL/TLS assumes the server name used by the client
comes from a trusted source. Unfortunately, unsigned DNS records don't
provide that. A web browser equivalent would be to go to a "http://";
URL to get the desired "https://"; URL and then wondering how to protect
against spoofing of the "http://"; reply to point to the wrong "https://";
server.
An alternative solution is to replace the use of SRV records by the more
traditional "role names" scheme. That is to get a web server, request
www.example.com, to get an ftp server ftp.example.com, to get a DNS
server dns1.example.com dns2.exeample.com, to get a foo server, look up
foo1.example.com foo2.example.com foo3.example.com etc. As the
certificates would be for the systematic names, SSL/TLS will check that
the name is as expected, while the client code will only supply "machine
names" that are correct for the task, it would not ask for or accept
foo1.example.net if it should have been looking for foo1.example.com.
PS: DNSSEC is not an option for me.
Too bad, as that would be a good solution
Thanks,
Sandeep
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
