python-ldap-dev

start_tls = 2 is ignored with LDAP URIs starting with LDAP://

[Andreas B. <bue...@un...>]

Hi,

I've found a strange behaviour of python-ldap when working with TLS encrypted 
connections. I'm not sure if this is a problem of the python bindings or of 
libldap or in my head ;-)

In my first scenario I was trying to set up a TLS encrypted connection with a 
specific CA certificate that was set in the ldap.conf file (TLS_CACERT).

>>> import ldap
>>> l = 
ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention.test:389', 
who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', 
start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>>> l.started_tls
0

In that case the connection is not encrypted. When I replace LDAP:// with 
ldap:// in the URI the connection is encrypted.

>>> l = 
ldap.ldapobject.SmartLDAPObject(uri='ldap://qamaster.windom2008.univention.test:389', 
who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', 
start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>>> l.started_tls
1

It look likes a TLS connection is not set up if the URI starts with LDAP://

In the second scenario I've tried to set up a TLS encrypted connection with a 
CA certificate that was not set in the ldap.conf file.

>>> l = 
ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389', 
who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', 
start_tls=2, 
tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem')
...
ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
failed', 'desc': 'Connect error'}

It seems that the argument tls_cacertfile is ignored, because if I set the CA 
certificate file with the set_option function the connection works and is 
encrypted.

ldap.set_option( 
ldap.OPT_X_TLS_CACERTFILE, '/etc/univention/connector/ad/ad_cert_20091221_153053.pem' )
l = 
ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389', 
who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', 
start_tls=2 )
>>> l.started_tls
1

software versions:

python 2.4.6
libldap 2.4.15
python-ldap 2.3.5

Is there any mistake in my reasoning or is this a known behaviour?

best regards
Andreas

-- 
Andreas Büsching
Open Source Software Engineer

Univention GmbH
Linux for your business
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99

<bue...@un...>
http://www.univention.de

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Re: start_tls = 2 is ignored with LDAP URIs starting with LDAP://

[Andreas B. <bue...@un...>]

Hi,

Has anyone an idea?

thanx in advance
Andreas

Am Freitag 08 Januar 2010 09:39:40 schrieb Andreas Büsching:
> I've found a strange behaviour of python-ldap when working with TLS
> encrypted connections. I'm not sure if this is a problem of the python
> bindings or of libldap or in my head ;-)
>
> In my first scenario I was trying to set up a TLS encrypted connection with
> a specific CA certificate that was set in the ldap.conf file (TLS_CACERT).
>
> >>> import ldap
> >>> l =
>
> ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention.
>test:389',
> who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='
>univention', start_tls=2,
> tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>
> >>> l.started_tls
>
> 0
>
> In that case the connection is not encrypted. When I replace LDAP:// with
> ldap:// in the URI the connection is encrypted.
>
> >>> l =
>
> ldap.ldapobject.SmartLDAPObject(uri='ldap://qamaster.windom2008.univention.
>test:389',
> who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='
>univention', start_tls=2,
> tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>
> >>> l.started_tls
>
> 1
>
> It look likes a TLS connection is not set up if the URI starts with LDAP://
>
> In the second scenario I've tried to set up a TLS encrypted connection with
> a CA certificate that was not set in the ldap.conf file.
>
> >>> l =
>
> ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univ
>ention.test:389',
> who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='u
>nivention', start_tls=2,
> tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem')
> ...
> ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed', 'desc': 'Connect error'}
>
> It seems that the argument tls_cacertfile is ignored, because if I set the
> CA certificate file with the set_option function the connection works and
> is encrypted.
>
> ldap.set_option(
> ldap.OPT_X_TLS_CACERTFILE,
> '/etc/univention/connector/ad/ad_cert_20091221_153053.pem' ) l =
> ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univ
>ention.test:389',
> who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='u
>nivention', start_tls=2 )
>
> >>> l.started_tls
>
> 1
>
> software versions:
>
> python 2.4.6
> libldap 2.4.15
> python-ldap 2.3.5
>
> Is there any mistake in my reasoning or is this a known behaviour?
>
> best regards
> Andreas


-- 
Andreas Büsching
Open Source Software Engineer

Univention GmbH
Linux for your business
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99

<bue...@un...>
http://www.univention.de

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

**** Besuchen Sie uns auf der KOMCOM NORD in Hannover 
vom 9.-10.02.2010 in der Eilenriedehalle, Stand H 03 ****

Re: start_tls = 2 is ignored with LDAP URIs starting with LDAP://

[Michael S. <mi...@st...>]

Andreas,

sorry for my late reply. I'm quite busy at the moment.

Andreas Büsching wrote:
> I've found a strange behaviour of python-ldap when working with TLS encrypted 
> connections. I'm not sure if this is a problem of the python bindings or of 
> libldap or in my head ;-)
> 
> In my first scenario I was trying to set up a TLS encrypted connection with a 
> specific CA certificate that was set in the ldap.conf file (TLS_CACERT).
> 
>>>> import ldap
>>>> l = 
> ldap.ldapobject.SmartLDAPObject(uri='LDAP://qamaster.windom2008.univention.test:389', 
> who='uid=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', 
> start_tls=2, tls_cacertfile='/etc/univention/ssl/ucsCA/CAcert.pem')
>>>> l.started_tls
> 0
> 
> In that case the connection is not encrypted. When I replace LDAP:// with 
> ldap:// in the URI the connection is encrypted.

Well, that's because of the stupid handling in SmartLDAPObject.__init__().
Line 900 should check the lower-cased uri:

    if start_tls>0 and uri[:5].lower()=='ldap:':

Well, SmartLDAPObject is not well tested nor documented and should probably be
removed anyway...

> In the second scenario I've tried to set up a TLS encrypted connection with a 
> CA certificate that was not set in the ldap.conf file.
> 
>>>> l = 
> ldap.ldapobject.SmartLDAPObject(uri='ldap://win-64q6lq48z7a.windom2008.univention.test:389', 
> who='cn=Administrator,cn=users,DC=windom2008,DC=univention,DC=test',cred='univention', 
> start_tls=2, 
> tls_cacertfile='/etc/univention/connector/ad/ad_cert_20091221_153053.pem')
> ...
> ldap.CONNECT_ERROR: {'info': 'error:14090086:SSL 
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify 
> failed', 'desc': 'Connect error'}

Well, tls_cacertfile is simply not used in SmartLDAPObject.__init__(). The
reason is that OpenLDAP libs 2.3 were not able to set connection-specific SSL
options. It should work with OpenLDAP 2.4 under some circumstances but I never
got it working.

=> please either don't use SmartLDAPObject or contribute fixes for it
Personally I'd vote for removing it.

Ciao, Michael.

ldap.ldapobject.SmartLDAPObject removed

[Michael S. <mi...@st...>]

Michael Ströder wrote:
> Well, SmartLDAPObject is not well tested nor documented and should probably be
> removed anyway...
> [..]
> Well, tls_cacertfile is simply not used in SmartLDAPObject.__init__(). The
> reason is that OpenLDAP libs 2.3 were not able to set connection-specific SSL
> options. It should work with OpenLDAP 2.4 under some circumstances but I never
> got it working.
> 
> => please either don't use SmartLDAPObject or contribute fixes for it
> Personally I'd vote for removing it.

In CVS HEAD I've removed the untested and undocumented wrapper class
ldap.ldapobject.SmartLDAPObject completely. Upcoming release 2.3.11 will not
contain it anymore. It never worked robustly like intended and it's not worth
the effort to fix it.

Ciao, Michael.

Re: ldap.ldapobject.SmartLDAPObject removed

[Andreas B. <bue...@un...>]

Hi Michael,

Am Freitag 05 Februar 2010 13:34:32 schrieb Michael Ströder:
> Michael Ströder wrote:
> > Well, SmartLDAPObject is not well tested nor documented and should
> > probably be removed anyway...
> > [..]
> > Well, tls_cacertfile is simply not used in SmartLDAPObject.__init__().
> > The reason is that OpenLDAP libs 2.3 were not able to set
> > connection-specific SSL options. It should work with OpenLDAP 2.4 under
> > some circumstances but I never got it working.
> >
> > => please either don't use SmartLDAPObject or contribute fixes for it
> > Personally I'd vote for removing it.
>
> In CVS HEAD I've removed the untested and undocumented wrapper class
> ldap.ldapobject.SmartLDAPObject completely. Upcoming release 2.3.11 will
> not contain it anymore. It never worked robustly like intended and it's not
> worth the effort to fix it.

Thanx for the information. We will replace in SmartLDAPObject in one of our 
next releases of the software.

best regards
Andreas

-- 
Andreas Büsching
Open Source Software Engineer

Univention GmbH
Linux for your business
Mary-Somerville-Str.1
28359 Bremen
Tel. : +49 421 22232-0
Fax : +49 421 22232-99

<bue...@un...>
http://www.univention.de

Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

**** Besuchen Sie uns auf der KOMCOM NORD in Hannover 
vom 9.-10.02.2010 in der Eilenriedehalle, Stand H 03 ****