openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by quanah＠symas.com 09 Oct '18

09 Oct '18

--On Tuesday, October 09, 2018 10:02 AM +0000 nanmor(a)126.com wrote: > We can get the result, but from Wireshark result, we find that they used > TLS1.2 to negotiated. I do not find this to be the case with OpenLDAP 2.4.46. > The openSSL is support for TLS1.3,however openldap-2.4.46 is still used > TLS1.2 by default. Need some parameters to specify TLS1.3 in openldap > configuration? Nope. > By the way, I have tested that other application can negotiated with > TLS1.3 by default when the client and server both use openssl-1.1.1. That is the behavior I see. OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client and server: 5bbcb282 connection_read(14): checking for input on id=1001 TLS trace: SSL_accept:TLSv1.3 early data TLS trace: SSL_accept:SSLv3/TLS read finished TLS trace: SSL_accept:SSLv3/TLS write session ticket TLS trace: SSL_accept:SSLv3/TLS write session ticket Perhaps the ldapsearch you picked up was not the one linked to OpenSSL 1.1.1. You may also want to read the slapd.conf(5) or slapd-config(5) man pages on how to set a minimum required TLS protocol version. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8924) Installed openldap2.4.46 and openssl1.1.1, the client and server still used TLS1.2 to negotiated
by nanmor＠126.com 09 Oct '18

09 Oct '18

Full_Name: Nancy Mo Version: openldap-clients-2.4.46 OS: Redhat 7, ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.38.0.87) openldap Client: Ubuntu 16.04.4 LTS/ openldap 2.4.46/ openssl-1.1.1 openldap Server: redhat 7, Linux 3.10.0-327.13.1.el7.x86_64 #1 SMP Mon Feb 29 13:22:02 EST 2016 x86_64 x86_64 x86_64 GNU/Linux openldap2.4.46/ openssl-1.1.1 In Client, configure ldap.conf: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com URI ldap://mydomain.com:389 ldaps://mydomain.com:636 ssl start_tls TLS_CACERTDIR /usr/local/etc/openldap/cacerts TLS_CACERT /usr/local/etc/openldap/cacerts/cacert.pem TLS_REQCERT never #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never SASL_NOCANON on BASE cn=localhost debug 9 local4.* /var/log/ldap.log In server: configure the slapd.conf (some important configuration) database mdb maxsize 1073741824 suffix "dc=mydomain,dc=com" rootdn "cn=Manager,dc=mydomain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA}srNLpYqpwEpRTw94IV79Myw5YO6rn0Ym # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/openldap.2.4.46/var/openldap-data TLSCACertificateFile /usr/local/openldap.2.4.46/etc/openldap/cacerts/cacert.pem TLSCertificateFile /usr/local/openldap.2.4.46/etc/openldap/ldap.crt TLSCertificateKeyFile /usr/local/openldap.2.4.46/etc/openldap/ldap.key >From client connect to server: ldapsearch -x -H ldaps://mydomain.com:636 -D cn=Manager,dc=mydomain,dc=com -w passw0rd -b "" -s base objectclass=* We can get the result, but from Wireshark result, we find that they used TLS1.2 to negotiated. The openSSL is support for TLS1.3,however openldap-2.4.46 is still used TLS1.2 by default. Need some parameters to specify TLS1.3 in openldap configuration? By the way, I have tested that other application can negotiated with TLS1.3 by default when the client and server both use openssl-1.1.1. Thanks a lot. Best regards, nancy Mo

1 0

Re: (ITS#8650) EAGAIN from gnutls_handshake not respected
by ryan＠nardis.ca 04 Oct '18

04 Oct '18

On Tue, Sep 18, 2018 at 10:55:50PM -0700, Ryan Tandy wrote: >There is some EAGAIN handling conditional on LDAP_USE_NON_BLOCKING_TLS >which itself is behind LDAP_DEVEL. However this code is meant for >non-blocking sockets, and in my case it ends up stuck in poll() >waiting for a notification that never arrives. This turned out to be because the fd and timeout fields are only initialized when timeout is configured and the non-blocking behaviour was triggered because of it. Otherwise the code simply doesn't anticipate EAGAIN could be returned and the behaviour is more or less undefined; it ends up calling poll() with fd = -1 and a garbage timeout. >It's possible that what I actually want here is a (ret > 0) case in >ldap_int_tls_start for when LDAP_USE_NON_BLOCKING_TLS is absent and >ldap_int_tls_connect returns 1. (I'd also need to adapt the >non-blocking path to be able to handle a blocking socket as well.) More precisely, what I actually want is a (ret > 0) case that is used unless both USE_NON_BLOCKING_TLS is true and a timeout is configured. If we added to ber_sockbuf_ctrl() the ability to query whether the socket is non-blocking, for GnuTLS at least we could bypass poll() and go straight back into ldap_int_tls_connect(). However I don't see a lot of benefit to this as long as calling poll() on a blocking socket has no downside.

1 0

(ITS#8923) compare op with dynlist returns wrong code when requested DN is in scope but doesn't exist
by quanah＠openldap.org 03 Oct '18

03 Oct '18

Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) In a situation where a dynamic group has been created and a compare operation is run with a DN that doesn't exist but is within the scope of the dynamic group URI, the ldapcompare operation will incorrectly return an error 80 instead of error 5 (compare FALSE). For example, if I have: dn: cn=planning,ou=Groups,dc=example,dc=com objectClass: groupOfURLs cn: planning memberURL: ldap:///ou=planning,dc=example,dc=com??sub?(objectClass=inetorgpers on) and I do an ldapcompare with: ldapcompare -x -H ldap://anvil2.rb.symas.net -D dc=example,dc=com -w secret cn=planning,ou=Groups,dc=example,dc=com "member:cn=Ramakant Wolow,ou=Planning,dc=example,dc=com" (i.e., this entry doesn't exist in the DB), I get: Compare Result: Other (e.g., implementation specific) error (80) UNDEFINED This appears to be due to the fact that in this scenario, slapd attempts to find the DN in the underlying DB and it doesn't exist, so an err=32 is returned back. This is incorrectly interpreted as an unknown error, thus the err=80 result. Instead it should be treated as "not a member of the group".

1 0

Re: (ITS#8922) tls_o bug with OpenSSL 1.1.1
by norm.green＠gemtalksystems.com 01 Oct '18

01 Oct '18

Thank you Michael, you are correct. Somehow I missed the 2.4.46 release. This issue may be closed. Norm Green On 10/1/2018 2:38 AM, Michael Ströder wrote: > On 10/1/18 6:18 AM, norm.green(a)gemtalksystems.com wrote: >> Full_Name: Norman Green >> Version: 2.4.45 >> >> Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL >> 1.1.1 and the static initialization is now incorrect: > CHANGES of release 2.4.46 contains this: > > -------------------------- snip -------------------------- > OpenLDAP 2.4.46 Release (2018/03/22) > [..] > Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) > -------------------------- snip -------------------------- > > So your report might be a duplicate of this: > > https://www.openldap.org/its/index.cgi?findid=8791 > > Ciao, Michael.

1 0

Re: (ITS#8922) tls_o bug with OpenSSL 1.1.1
by michael＠stroeder.com 01 Oct '18

01 Oct '18

On 10/1/18 6:18 AM, norm.green(a)gemtalksystems.com wrote: > Full_Name: Norman Green > Version: 2.4.45 > > Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL > 1.1.1 and the static initialization is now incorrect: CHANGES of release 2.4.46 contains this: -------------------------- snip -------------------------- OpenLDAP 2.4.46 Release (2018/03/22) [..] Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) -------------------------- snip -------------------------- So your report might be a duplicate of this: https://www.openldap.org/its/index.cgi?findid=8791 Ciao, Michael.

1 0

(ITS#8922) tls_o bug with OpenSSL 1.1.1
by norm.green＠gemtalksystems.com 30 Sep '18

30 Sep '18

Full_Name: Norman Green Version: 2.4.45 OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.53.145.234) in tls_o.c, the function tlso_sb_setup has this code on line 833: bio = BIO_new( &tlso_bio_method ); which uses a statically allocated BIO_METHOD. Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL 1.1.1 and the static initialization is now incorrect: static BIO_METHOD tlso_bio_method = { ( 100 | 0x400 ), /* it's a source/sink BIO */ "sockbuf glue", tlso_bio_write, tlso_bio_read, tlso_bio_puts, tlso_bio_gets, tlso_bio_ctrl, tlso_bio_create, tlso_bio_destroy }; In 1.1.1, this (internal) SSL struct looks like this: struct bio_method_st { int type; char *name; int (*bwrite) (BIO *, const char *, size_t, size_t *); int (*bwrite_old) (BIO *, const char *, int); int (*bread) (BIO *, char *, size_t, size_t *); int (*bread_old) (BIO *, char *, int); int (*bputs) (BIO *, const char *); int (*bgets) (BIO *, char *, int); long (*ctrl) (BIO *, int, long, void *); int (*create) (BIO *); int (*destroy) (BIO *); long (*callback_ctrl) (BIO *, int, BIO_info_cb *); };

1 0

Re: (ITS#8918) sasl.c:326: possible bad assignment ?
by quanah＠symas.com 26 Sep '18

26 Sep '18

--On Saturday, September 22, 2018 11:11 AM +0000 dcb314(a)hotmail.com wrote: > Full_Name: David Binderman > Version: 2.4.46 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.65.83.114) Thanks for the report, this has been fixed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8921) Content Sync Refresh Required when provider accesslog is empty
by au＠hcsd.de 26 Sep '18

26 Sep '18

Full_Name: Stephan Austerm.hle Version: 2.4.46 OS: Linux (Debian unstable) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.20.232.53) Consumer slapd emits endless 5babd9c4 do_syncrep2: rid=001 (4096) Content Sync Refresh Required messages when the provider has an empty accesslog (because it was freshly setup and nothing has been added/updated since then). This issue was mentioned back in 2013 (see http://www.openldap.org/lists/openldap-technical/201301/msg00229.html) already but it looks like it was not reported. The provider likewise logs 5babd9cf conn=1000 op=60677 SRCH base="dc=company,dc=com" scope=2 deref=0 filter="(objectClass=*)" 5babd9cf conn=1000 op=60677 SRCH attr=* + 5babd9cf conn=1000 op=60677 SEARCH RESULT tag=101 err=0 nentries=0 text= for every attempt from the consumer to lookup records in the accesslog.

1 0

Re:Re: (ITS#8920) OpenLDAP
by nanmor＠126.com 26 Sep '18

26 Sep '18

------=_Part_106754_1961220656.1537947199160 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgUXVhbmFoo6wKVGhhbmtzIGEgbG90IGZvciB5b3VyIGhlbHAuIEkgd2lsbCB1cGdyYWRlIG15 IG9wZW5sZGFwIHRvIDIuNC40NiB2ZXJzaW9uIHRoZW4gaGF2ZSBhIHRyeS4gdGhhbmtzIGFnYWlu LgoKCmJlc3QgcmVnYXJkcywKbmFuY3kKCgoKCgpBdCAyMDE4LTA5LTI1IDA4OjU5OjIxLCAiUXVh bmFoIEdpYnNvbi1Nb3VudCIgPHF1YW5haEBzeW1hcy5jb20+IHdyb3RlOj4tLU9uIFR1ZXNkYXks IFNlcHRlbWJlciAyNSwgMjAxOCAxOjQ2IEFNICswMDAwIG5hbm1vckAxMjYuY29tIHdyb3RlOgo+ Cj4+IEZ1bGxfTmFtZTogTmFuY3kgTW8KPj4gVmVyc2lvbjogb3BlbmxkYXAtY2xpZW50cy0yLjQu NDQtMTUuZWw3XzUueDg2XzY0Cj4+IE9TOiBSZWRoYXQgNwo+PiBVUkw6IGZ0cDovL2Z0cC5vcGVu bGRhcC5vcmcvaW5jb21pbmcvCj4+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICgxMDYuMzguMC44 NykKPgo+SGVsbG8sCj4KPlRoZSBJVFMgc3lzdGVtIGlzIGZvciBidWcgcmVwb3J0cyBvbmx5LiAg UGxlYXNlIGRpcmVjdCB1c2FnZSBxdWVzdGlvbnMgdG8gCj50aGUgb3BlbmxkYXAtdGVjaG5pY2Fs IGxpc3QuICBJIHdpbGwgbm90ZSB0aGF0IEkndmUgdGVzdGVkIE9wZW5MREFQIDIuNC40NiAKPndp dGggYm90aCBzdGFydFRMUyBhbmQgTERBUFMgdXNpbmcgVExTIDEuMyB3aGVuIGNvbXBpbGVkIG9u IGJvdGggdGhlIHNlcnZlciAKPmFuZCBjbGllbnQgc2lkZSB3aXRoIE9wZW5TU0wgMS4xLjEgYW5k IGl0IHdvcmtlZCBjb3JyZWN0bHkuICBZb3Ugd2lsbCBuZWVkIAo+dG8gcHJvdmlkZSBzaWduaWZp Y2FudGx5IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgeW91ciBjb25maWd1cmF0aW9uL3NldHVwIAo+ d2hlbiBjb250YWN0aW5nIHRoZSBvcGVubGRhcC10ZWNobmljYWwgbGlzdCBmb3IgYW55IGZ1cnRo ZXIgYXNzaXN0YW5jZS4KPgo+SSB3b3VsZCBhbHNvIG5vdGUgdGhhdCBvZmZpY2lhbCBzdXBwb3J0 IGZvciBPcGVuU1NMIDEuMS4wIGFuZCBsYXRlciB3YXMgbm90IAo+YWRkZWQgdW50aWwgdGhlIE9w ZW5MREFQIDIuNC40NSByZWxlYXNlLCB3aXRoIGZ1cnRoZXIgZml4ZXMgaW4gdGhlIE9wZW5MREFQ IAo+Mi40LjQ2IHJlbGVhc2UuICBUaHVzIEkgd291bGQgYWR2aXNlIGEgZmlyc3Qgc3RlcCBvZiB1 cGdyYWRpbmcgdG8gT3BlbkxEQVAgCj4yLjQuNDYuCj4KPldhcm0gcmVnYXJkcywKPlF1YW5haAo+ Cj4KPi0tCj4KPlF1YW5haCBHaWJzb24tTW91bnQKPlByb2R1Y3QgQXJjaGl0ZWN0Cj5TeW1hcyBD b3Jwb3JhdGlvbgo+UGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0 aW9ucyBwb3dlcmVkIGJ5IE9wZW5MREFQOgo+PGh0dHA6Ly93d3cuc3ltYXMuY29tPgo= ------=_Part_106754_1961220656.1537947199160 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgUXVhbmFoo6w8L2Rpdj48ZGl2PlRoYW5rcyBhIGxv dCBmb3IgeW91ciBoZWxwLiBJIHdpbGwgdXBncmFkZSBteSBvcGVubGRhcCB0byAyLjQuNDYgdmVy c2lvbiB0aGVuIGhhdmUgYSB0cnkuIHRoYW5rcyBhZ2Fpbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PmJlc3QgcmVnYXJkcyw8L2Rpdj48ZGl2Pm5hbmN5PGJyPjwvZGl2Pjxicj48YnI+PGJyPjxk aXYgc3R5bGU9InBvc2l0aW9uOnJlbGF0aXZlO3pvb206MSI+PC9kaXY+PGRpdiBpZD0iZGl2TmV0 ZWFzZU1haWxDYXJkIj48L2Rpdj5BdCAyMDE4LTA5LTI1IDA4OjU5OjIxLCAiUXVhbmFoIEdpYnNv bi1Nb3VudCIgJmx0O3F1YW5haEBzeW1hcy5jb20mZ3Q7IHdyb3RlOiZndDstLU9uIFR1ZXNkYXks IFNlcHRlbWJlciAyNSwgMjAxOCAxOjQ2IEFNICswMDAwIG5hbm1vckAxMjYuY29tIHdyb3RlOgo8 cHJlPiZndDsKJmd0OyZndDsgRnVsbF9OYW1lOiBOYW5jeSBNbwomZ3Q7Jmd0OyBWZXJzaW9uOiBv cGVubGRhcC1jbGllbnRzLTIuNC40NC0xNS5lbDdfNS54ODZfNjQKJmd0OyZndDsgT1M6IFJlZGhh dCA3CiZndDsmZ3Q7IFVSTDogZnRwOi8vZnRwLm9wZW5sZGFwLm9yZy9pbmNvbWluZy8KJmd0OyZn dDsgU3VibWlzc2lvbiBmcm9tOiAoTlVMTCkgKDEwNi4zOC4wLjg3KQomZ3Q7CiZndDtIZWxsbywK Jmd0OwomZ3Q7VGhlIElUUyBzeXN0ZW0gaXMgZm9yIGJ1ZyByZXBvcnRzIG9ubHkuICBQbGVhc2Ug ZGlyZWN0IHVzYWdlIHF1ZXN0aW9ucyB0byAKJmd0O3RoZSBvcGVubGRhcC10ZWNobmljYWwgbGlz dC4gIEkgd2lsbCBub3RlIHRoYXQgSSd2ZSB0ZXN0ZWQgT3BlbkxEQVAgMi40LjQ2IAomZ3Q7d2l0 aCBib3RoIHN0YXJ0VExTIGFuZCBMREFQUyB1c2luZyBUTFMgMS4zIHdoZW4gY29tcGlsZWQgb24g Ym90aCB0aGUgc2VydmVyIAomZ3Q7YW5kIGNsaWVudCBzaWRlIHdpdGggT3BlblNTTCAxLjEuMSBh bmQgaXQgd29ya2VkIGNvcnJlY3RseS4gIFlvdSB3aWxsIG5lZWQgCiZndDt0byBwcm92aWRlIHNp Z25pZmljYW50bHkgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCB5b3VyIGNvbmZpZ3VyYXRpb24vc2V0 dXAgCiZndDt3aGVuIGNvbnRhY3RpbmcgdGhlIG9wZW5sZGFwLXRlY2huaWNhbCBsaXN0IGZvciBh bnkgZnVydGhlciBhc3Npc3RhbmNlLgomZ3Q7CiZndDtJIHdvdWxkIGFsc28gbm90ZSB0aGF0IG9m ZmljaWFsIHN1cHBvcnQgZm9yIE9wZW5TU0wgMS4xLjAgYW5kIGxhdGVyIHdhcyBub3QgCiZndDth ZGRlZCB1bnRpbCB0aGUgT3BlbkxEQVAgMi40LjQ1IHJlbGVhc2UsIHdpdGggZnVydGhlciBmaXhl cyBpbiB0aGUgT3BlbkxEQVAgCiZndDsyLjQuNDYgcmVsZWFzZS4gIFRodXMgSSB3b3VsZCBhZHZp c2UgYSBmaXJzdCBzdGVwIG9mIHVwZ3JhZGluZyB0byBPcGVuTERBUCAKJmd0OzIuNC40Ni4KJmd0 OwomZ3Q7V2FybSByZWdhcmRzLAomZ3Q7UXVhbmFoCiZndDsKJmd0OwomZ3Q7LS0KJmd0OwomZ3Q7 UXVhbmFoIEdpYnNvbi1Nb3VudAomZ3Q7UHJvZHVjdCBBcmNoaXRlY3QKJmd0O1N5bWFzIENvcnBv cmF0aW9uCiZndDtQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExEQVAgc29sdXRp b25zIHBvd2VyZWQgYnkgT3BlbkxEQVA6CiZndDsmbHQ7aHR0cDovL3d3dy5zeW1hcy5jb20mZ3Q7 CjwvcHJlPjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVhc2Vmb290ZXIiPjxwPiZuYnNw OzwvcD48L3NwYW4+ ------=_Part_106754_1961220656.1537947199160--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs