You are right. A trusted list of server names at the client (hard coded in a config file) would be sufficient. The only downside of it would be for the domain admin to touch up this file each time he/she modifies the LDAP SRV list in DNS. Also note that we have absolutely no control on what goes into server certificates. Each site may issue certificates differently and all sites may not oblige to incorporate a new property into the server certificates.
Thanks, Sandeep On Tue, Aug 24, 2010 at 1:26 PM, Steffen DETTMER < steffen.dett...@ingenico.com> wrote: > Hi! > > * sandeep kiran p wrote on Wed, Aug 11, 2010 at 20:36 -0700: > > 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. > > I think this is a common pitfall: the server connected to is > authenticated (i.e. it really is ldap.malicious.com) but it is not > checked if the peer is /authorized/ to get the credentials. > > It is like asking someone to show his passport, verifying if the > passport is authentic, but neither checking the name written on the > passwort nor checking if it is on the guest list at all... > > If not everyone is authorized, I think you need some definition > of permissions, like an association of DN and permissions or a > white list. Don't know if major public CAs offer this, but maybe > you also could define a dedicated property in the certificate > (but all CAs you trust must guarantee to use this properties ONLY > for this case - I guess it will become at least very expensive). > But maybe some hostname white list is sufficient. This list must > be authentic (hardcoded, local config file or dynamic file which > is cryptographically signed), so non-DNSSEC'd TXT records won't > help of course. > > > > But if you do not want to communicate with everyone, why rely on > PKI, maybe you just want to have a local list of the certificates > of authorized peers? PKI is good to authenticate everyone, > without knowing in advance, but seems you do not want this, but > just want to communicate with someone known/trusted/authorized in > advance. Sometimes PKI seems to me like a hammer making every > problem looking like a nail, but in turn it has to advantage that > a well researched crypto system is used. > > Also it should be noted that in case of MITM the link from LDAP > client to ldap.malicious.com IS secured! Only the attacker can > read the traffic, ensured cryptographically! > > oki, > > Steffen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --[ end of mail > ]-------------------------------------------------->8======= > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
