Howard Chu wrote:

Hi Howard,
Many thanks for your reply.

>> By default, openldap API now searches in referrals too.

> That's not true. Referral chasing is disabled by default in all OpenLDAP
> releases, it has never been enabled by default. If you're seeing it happen
> here, that means you have an ldap.conf or ldaprc somewhere telling it to do so
>- and you should probably change that.

I know you're THE openldap guru, but I'm afraid I do not agree:
- There's no REFERRALS settings in any of my system/user configuration files.
- wireshark'ing the curl ldap connection shows it does chase referrals.
- In openldap's libraries/libldap/init.c there is an initialization statement "LDAP_BOOL_SET(gopts, LDAP_BOOL_REFERRALS);".
- ldap.conf man page says:
REFERRALS <on/true/yes/off/false/no>
              Specifies if the client should automatically follow
              referrals returned by LDAP servers. The default is ON.

But in any case, this is not the real problem. curl should work even if referrals chasing were enabled by configuration.

>> One very easy solution would be to disable automatic referrals chasing
>> (LDAP_OPT_REFERRALS LDAP_OPT_OFF). The drawback would be we will not receive
>> entries from referrals.

> Unfortunately, this would of course break things for someone who has
> explicitly configured referral chasing ON.

Agreed. But in the current state of curl, attempting this fails (i.e.: stalls). Thus IMHO setting it to OFF is preferable (as a middle-term limitation).

> At the very least, you must supply a rebind callback, otherwise the referrals
> are chased anonymously. Note that all of this is quite a can of worms - in the
> default case, you need to make sure you're talking to a trustworthy server.
> Since a Simple Bind sends a plaintext username and password, it's a trivial
> matter for an attacker to intercept a referral and capture your client
> credentials. Defining what a "trustworthy server" is is an open question.

Thanks for the hint. I tried it successfully (in a local update of curl sources). But we cannot use asynchronous bind here.
By saying "successfully", I mean wireshark shows the binds have succeeded, but curl still stalls, because it never sees there's some new data available (they do not come on the main socket descriptor).

I also discovered we can grab secondary socket descriptors at creation and deletion using LDAP_OPT_CONNECT_CB. This should probably be used by curl if it were able to monitor (i.e.: poll) several descriptors for a single easy channel. I don't think it's currently easy to do that, and that is the real problem.

> Ideally you should only chase referrals using secure credentials such as an
> X.509 certificate or a Kerberos ticket. More ideally, you should never chase
> referrals at all, a proper directory server will chain your requests for you
> and never send referrals to a client.

Totally agreed too. But if you want to grab info from a M$ active directory, you have to deal with a non-frendly server and there is no alternative :-(

In short:
- if we want to properly support referrals chasing in curl, single-easy-channel multi-socket monitoring MUST be implemented.
- curl's openldap should be upgraded to support alternative authentication methods.
- a rebind callback must be implemented,

Patrick

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2016-01-23