openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(ITS#8925) Please remove the entry for mirror.switch.ch from the Download page
by switchmirror＠switch.ch 11 Oct '18

11 Oct '18

Full_Name: Thomas Lenggenhager Version: 2.4.9 OS: Solaris URL: Submission from: (NULL) (2001:620:0:44:12dd:b1ff:fed3:e027) I already sent twice a message to info(a)openldap.org, but no action or answer received. So I try it on this channel. Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the Download web page: http://www.openldap.org/software/download/ Here the message I sent: ------------ The SWITCHmirror service hosted on mirror.switch.ch will be decommissioned soon. Could you please remove the entry for mirror.switch.ch from your list of mirror sites and notify us once accomplished? Thereafter, we will stop the mirroring of this package and drop it from our repository. PS: See http://mirror.switch.ch for details on the decommissioning. BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely disappeared, there is no DNS entry for it anymore.

1 0

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

10 Oct '18

--Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Quanah, I=E2=80=99m afraid that the message will be encoded so that you can not = see, so send again.=20 After I set a parameter in server: TLSProtocolMin 3.4, restart the ldap = server, it works that the server will not negotiated with lower TLS = version. I set the parameter in client: TLS_PROTOCOL_MIN 3.4, the client still = start a client hello with TLS1.2, i doubt that the parameter not work in = my configuration. here is my ldap.conf: ssl start_tls TLS_CACERTDIR /usr/local/etc/openldap/cacerts TLS_CACERT /usr/local/etc/openldap/cacerts/cacert.pem TLS_REQCERT never TLS_PROTOCOL_MIN 3.4 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never SASL_NOCANON on BASE cn=3Dlocalhost debug 9 local4.* /var/log/ldap.log I used "openssl s_client -connect mydomain.com:636 = <http://mydomain.com:636/> -tls1_3" to connect the same server from = the same client, it will used TLS1.3 successfully. I think the openssl = for TLS1.3 works well.=20 How can I make sure our client and server link to the openssl ? And = could you please show your configuration about TLS in ldap.conf and = slap.conf to me, if you are convenient.=20 Thanks a lot. best regards=20 nancy > On Oct 9, 2018, at 9:56 PM, Quanah Gibson-Mount <quanah(a)symas.com> = wrote: >=20 > --On Tuesday, October 09, 2018 10:02 AM +0000 nanmor(a)126.com wrote: >=20 >> We can get the result, but from Wireshark result, we find that they = used >> TLS1.2 to negotiated. >=20 > I do not find this to be the case with OpenLDAP 2.4.46. >=20 >> 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? >=20 > Nope. >=20 >> 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. >=20 > That is the behavior I see. >=20 > OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client and = server: >=20 > 5bbcb282 connection_read(14): checking for input on id=3D1001 > 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 >=20 > Perhaps the ldapsearch you picked up was not the one linked to OpenSSL = 1.1.1. >=20 > 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. >=20 > Regards, > Quanah >=20 > -- >=20 > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> --Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">Hi = Quanah,</div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">I=E2=80=99m afraid that the message will be = encoded so that you can not see, so send again. </div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D""><br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D"">After I set a parameter in server:  TLSProtocolMin 3.4, = restart the ldap server, it works that the server will not negotiated = with lower TLS version.<br class=3D""></div><div style=3D"font-family: = Arial; font-size: 14px;" class=3D"">I set the parameter in client: = TLS_PROTOCOL_MIN 3.4, the client still start a client hello with TLS1.2, = i doubt that the parameter not work in my configuration.</div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">here is my = ldap.conf:</div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D"">ssl start_tls<br class=3D"">TLS_CACERTDIR  = /usr/local/etc/openldap/cacerts<br class=3D"">TLS_CACERT = /usr/local/etc/openldap/cacerts/cacert.pem<br class=3D"">TLS_REQCERT = never<br class=3D"">TLS_PROTOCOL_MIN 3.4<br = class=3D"">#SIZELIMIT      12<br = class=3D"">#TIMELIMIT      15<br = class=3D"">#DEREF          = never<br class=3D"">SASL_NOCANON    on<br class=3D"">BASE = cn=3Dlocalhost<br class=3D"">debug 9<br = class=3D"">local4.*         &= nbsp;  /var/log/ldap.log</div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">I used "openssl s_client -connect <a = href=3D"http://mydomain.com:636" = class=3D"">mydomain.com:636</a> -tls1_3"   to connect the same = server from the same client, it will used TLS1.3 successfully. I think = the openssl for TLS1.3 works well. <br class=3D""></div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D""><br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D"">How can I make sure our client and server link to the openssl = ?  And could you please  show your configuration about TLS in = ldap.conf and slap.conf to me, if you are convenient. <br = class=3D""></div><div style=3D"font-family: Arial; font-size: 14px;" = class=3D""><br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">Thanks a lot.</div><div style=3D"font-family:= Arial; font-size: 14px;" class=3D""><br class=3D""></div><div = style=3D"font-family: Arial; font-size: 14px;" class=3D"">best = regards <br class=3D""></div><div style=3D"font-family: Arial; = font-size: 14px;" class=3D"">nancy<br class=3D""></div><br = style=3D"font-family: Arial; font-size: 14px;" class=3D""><div = style=3D"font-family: Arial; font-size: 14px; position: relative; zoom: = 1;" class=3D""></div><div id=3D"divNeteaseMailCard" style=3D"font-family: = Arial; font-size: 14px;" class=3D""></div><div><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D"">On Oct 9, 2018, at 9:56 PM, = Quanah Gibson-Mount <<a href=3D"mailto:quanah@symas.com" = class=3D"">quanah(a)symas.com</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">--On = Tuesday, October 09, 2018 10:02 AM +0000 <a href=3D"mailto:nanmor@126.com"= class=3D"">nanmor(a)126.com</a> wrote:<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">We can get the result, = but from Wireshark result, we find that they used<br class=3D"">TLS1.2 = to negotiated.<br class=3D""></blockquote><br class=3D"">I do not find = this to be the case with OpenLDAP 2.4.46.<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">The openSSL is support = for TLS1.3,however openldap-2.4.46 is still used<br class=3D"">TLS1.2 by = default. Need some parameters to specify TLS1.3 in openldap<br = class=3D"">configuration?<br class=3D""></blockquote><br = class=3D"">Nope.<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D"">By the way, I have tested that other application can = negotiated with<br class=3D"">TLS1.3 by default when the client and = server both use openssl-1.1.1.<br class=3D""></blockquote><br = class=3D"">That is the behavior I see.<br class=3D""><br = class=3D"">OpenLDAP 2.4.46 linked to OpenSSL 1.1.1 for both the client = and server:<br class=3D""><br class=3D"">5bbcb282 connection_read(14): = checking for input on id=3D1001<br class=3D"">TLS trace: = SSL_accept:TLSv1.3 early data<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS read finished<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS write session ticket<br class=3D"">TLS trace: = SSL_accept:SSLv3/TLS write session ticket<br class=3D""><br = class=3D"">Perhaps the ldapsearch you picked up was not the one linked = to OpenSSL 1.1.1.<br class=3D""><br class=3D"">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.<br class=3D""><br class=3D"">Regards,<br = class=3D"">Quanah<br class=3D""><br class=3D"">--<br class=3D""><br = class=3D"">Quanah Gibson-Mount<br class=3D"">Product Architect<br = class=3D"">Symas Corporation<br class=3D"">Packaged, certified, and = supported LDAP solutions powered by OpenLDAP:<br class=3D""><<a = href=3D"http://www.symas.com" class=3D"">http://www.symas.com</a>><br = class=3D""></div></div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_A57FFFE0-FA22-44A6-A24D-07E9ADC17D6A--

1 0

Re:Re: (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

------=_Part_53823_903760140.1539140876552 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 SGkgUXVhbmFoLAoKCkFmdGVyIEkgc2V0IGEgcGFyYW1ldGVyIGluIHNlcnZlcjogIFRMU1Byb3Rv Y29sTWluIDMuNCwgcmVzdGFydCB0aGUgbGRhcCBzZXJ2ZXIsIGl0IHdvcmtzIHRoYXQgdGhlIHNl cnZlciB3aWxsIG5vdCBuZWdvdGlhdGVkIHdpdGggbG93ZXIgVExTIHZlcnNpb24uCgpJIHNldCB0 aGUgcGFyYW1ldGVyIGluIGNsaWVudDogVExTX1BST1RPQ09MX01JTiAzLjQsIHRoZSBjbGllbnQg c3RpbGwgc3RhcnQgYSBjbGllbnQgaGVsbG8gd2l0aCBUTFMxLjIsIGkgZG91YnQgdGhhdCB0aGUg cGFyYW1ldGVyIG5vdCB3b3JrIGluIG15IGNvbmZpZ3VyYXRpb24uCmhlcmUgaXMgbXkgbGRhcC5j b25mOgoKc3NsIHN0YXJ0X3RscwpUTFNfQ0FDRVJURElSICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRh cC9jYWNlcnRzClRMU19DQUNFUlQgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2FjZXJ0cy9jYWNl cnQucGVtClRMU19SRVFDRVJUIG5ldmVyClRMU19QUk9UT0NPTF9NSU4gMy40CiNTSVpFTElNSVQg ICAgICAxMgojVElNRUxJTUlUICAgICAgMTUKI0RFUkVGICAgICAgICAgIG5ldmVyClNBU0xfTk9D QU5PTiAgICBvbgpCQVNFIGNuPWxvY2FsaG9zdApkZWJ1ZyA5CmxvY2FsNC4qICAgICAgICAgICAg L3Zhci9sb2cvbGRhcC5sb2cKSSB1c2VkICJvcGVuc3NsIHNfY2xpZW50IC1jb25uZWN0IG15ZG9t YWluLmNvbTo2MzYgLXRsczFfMyIgICB0byBjb25uZWN0IHRoZSBzYW1lIHNlcnZlciBmcm9tIHRo ZSBzYW1lIGNsaWVudCwgaXQgd2lsbCB1c2VkIFRMUzEuMyBzdWNjZXNzZnVsbHkuIEkgdGhpbmsg dGhlIG9wZW5zc2wgZm9yIFRMUzEuMyB3b3JrcyB3ZWxsLgoKCgpIb3cgY2FuIEkgbWFrZSBzdXJl IG91ciBjbGllbnQgYW5kIHNlcnZlciBsaW5rIHRvIHRoZSBvcGVuc3NsID8gIEFuZCBjb3VsZCB5 b3UgcGxlYXNlICBzaG93IHlvdXIgY29uZmlndXJhdGlvbiBhYm91dCBUTFMgaW4gbGRhcC5jb25m IGFuZCBzbGFwLmNvbmYgdG8gbWUsIGlmIHlvdSBhcmUgY29udmVuaWVudC4KCgoKVGhhbmtzIGEg bG90LgoKCmJlc3QgcmVnYXJkcwoKbmFuY3kKCgoKCkF0IDIwMTgtMTAtMDkgMjE6NTY6MjMsICJR dWFuYWggR2lic29uLU1vdW50IiA8cXVhbmFoQHN5bWFzLmNvbT4gd3JvdGU6Cj4tLU9uIFR1ZXNk YXksIE9jdG9iZXIgMDksIDIwMTggMTA6MDIgQU0gKzAwMDAgbmFubW9yQDEyNi5jb20gd3JvdGU6 Cj4KPj4gV2UgY2FuIGdldCB0aGUgcmVzdWx0LCBidXQgZnJvbSBXaXJlc2hhcmsgcmVzdWx0LCB3 ZSBmaW5kIHRoYXQgdGhleSB1c2VkCj4+IFRMUzEuMiB0byBuZWdvdGlhdGVkLgo+Cj5JIGRvIG5v dCBmaW5kIHRoaXMgdG8gYmUgdGhlIGNhc2Ugd2l0aCBPcGVuTERBUCAyLjQuNDYuCj4KPj4gVGhl IG9wZW5TU0wgaXMgc3VwcG9ydCBmb3IgVExTMS4zLGhvd2V2ZXIgb3BlbmxkYXAtMi40LjQ2IGlz IHN0aWxsIHVzZWQKPj4gVExTMS4yIGJ5IGRlZmF1bHQuIE5lZWQgc29tZSBwYXJhbWV0ZXJzIHRv IHNwZWNpZnkgVExTMS4zIGluIG9wZW5sZGFwCj4+IGNvbmZpZ3VyYXRpb24/Cj4KPk5vcGUuCj4K Pj4gQnkgdGhlIHdheSwgSSBoYXZlIHRlc3RlZCB0aGF0IG90aGVyIGFwcGxpY2F0aW9uIGNhbiBu ZWdvdGlhdGVkIHdpdGgKPj4gVExTMS4zIGJ5IGRlZmF1bHQgd2hlbiB0aGUgY2xpZW50IGFuZCBz ZXJ2ZXIgYm90aCB1c2Ugb3BlbnNzbC0xLjEuMS4KPgo+VGhhdCBpcyB0aGUgYmVoYXZpb3IgSSBz ZWUuCj4KPk9wZW5MREFQIDIuNC40NiBsaW5rZWQgdG8gT3BlblNTTCAxLjEuMSBmb3IgYm90aCB0 aGUgY2xpZW50IGFuZCBzZXJ2ZXI6Cj4KPjViYmNiMjgyIGNvbm5lY3Rpb25fcmVhZCgxNCk6IGNo ZWNraW5nIGZvciBpbnB1dCBvbiBpZD0xMDAxCj5UTFMgdHJhY2U6IFNTTF9hY2NlcHQ6VExTdjEu MyBlYXJseSBkYXRhCj5UTFMgdHJhY2U6IFNTTF9hY2NlcHQ6U1NMdjMvVExTIHJlYWQgZmluaXNo ZWQKPlRMUyB0cmFjZTogU1NMX2FjY2VwdDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQK PlRMUyB0cmFjZTogU1NMX2FjY2VwdDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKPgo+ UGVyaGFwcyB0aGUgbGRhcHNlYXJjaCB5b3UgcGlja2VkIHVwIHdhcyBub3QgdGhlIG9uZSBsaW5r ZWQgdG8gT3BlblNTTCAKPjEuMS4xLgo+Cj5Zb3UgbWF5IGFsc28gd2FudCB0byByZWFkIHRoZSBz bGFwZC5jb25mKDUpIG9yIHNsYXBkLWNvbmZpZyg1KSBtYW4gcGFnZXMgb24gCj5ob3cgdG8gc2V0 IGEgbWluaW11bSByZXF1aXJlZCBUTFMgcHJvdG9jb2wgdmVyc2lvbi4KPgo+UmVnYXJkcywKPlF1 YW5haAo+Cj4tLQo+Cj5RdWFuYWggR2lic29uLU1vdW50Cj5Qcm9kdWN0IEFyY2hpdGVjdAo+U3lt YXMgQ29ycG9yYXRpb24KPlBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBz b2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoKPjxodHRwOi8vd3d3LnN5bWFzLmNvbT4K ------=_Part_53823_903760140.1539140876552 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7 Zm9udC1mYW1pbHk6QXJpYWwiPjxkaXY+SGkgUXVhbmFoLDwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+QWZ0ZXIgSSBzZXQgYSBwYXJhbWV0ZXIgaW4gc2VydmVyOiZuYnNwOyBUTFNQcm90b2NvbE1p biAzLjQsIHJlc3RhcnQgdGhlIGxkYXAgc2VydmVyLCBpdCB3b3JrcyB0aGF0IHRoZSBzZXJ2ZXIg d2lsbCBub3QgbmVnb3RpYXRlZCB3aXRoIGxvd2VyIFRMUyB2ZXJzaW9uLjxicj48L2Rpdj48ZGl2 Pkkgc2V0IHRoZSBwYXJhbWV0ZXIgaW4gY2xpZW50OiBUTFNfUFJPVE9DT0xfTUlOIDMuNCwgdGhl IGNsaWVudCBzdGlsbCBzdGFydCBhIGNsaWVudCBoZWxsbyB3aXRoIFRMUzEuMiwgaSBkb3VidCB0 aGF0IHRoZSBwYXJhbWV0ZXIgbm90IHdvcmsgaW4gbXkgY29uZmlndXJhdGlvbi48L2Rpdj48ZGl2 PmhlcmUgaXMgbXkgbGRhcC5jb25mOjwvZGl2PjxkaXY+PGJyPnNzbCBzdGFydF90bHM8YnI+VExT X0NBQ0VSVERJUiZuYnNwOyAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9jYWNlcnRzPGJyPlRMU19D QUNFUlQgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2FjZXJ0cy9jYWNlcnQucGVtPGJyPlRMU19S RVFDRVJUIG5ldmVyPGJyPlRMU19QUk9UT0NPTF9NSU4gMy40PGJyPiNTSVpFTElNSVQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTI8YnI+I1RJTUVMSU1JVCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAxNTxicj4jREVSRUYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmV2ZXI8YnI+U0FTTF9OT0NBTk9OJm5ic3A7Jm5ic3A7 Jm5ic3A7IG9uPGJyPkJBU0UgY249bG9jYWxob3N0PGJyPmRlYnVnIDk8YnI+bG9jYWw0LiombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgL3Zhci9sb2cvbGRhcC5sb2c8L2Rpdj48ZGl2PkkgdXNlZCAib3BlbnNzbCBzX2NsaWVu dCAtY29ubmVjdCBteWRvbWFpbi5jb206NjM2IC10bHMxXzMiICZuYnNwOyB0byBjb25uZWN0IHRo ZSBzYW1lIHNlcnZlciBmcm9tIHRoZSBzYW1lIGNsaWVudCwgaXQgd2lsbCB1c2VkIFRMUzEuMyBz dWNjZXNzZnVsbHkuIEkgdGhpbmsgdGhlIG9wZW5zc2wgZm9yIFRMUzEuMyB3b3JrcyB3ZWxsLiA8 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Ib3cgY2FuIEkgbWFrZSBzdXJlIG91ciBjbGll bnQgYW5kIHNlcnZlciBsaW5rIHRvIHRoZSBvcGVuc3NsID8mbmJzcDsgQW5kIGNvdWxkIHlvdSBw bGVhc2UmbmJzcDsgc2hvdyB5b3VyIGNvbmZpZ3VyYXRpb24gYWJvdXQgVExTIGluIGxkYXAuY29u ZiBhbmQgc2xhcC5jb25mIHRvIG1lLCBpZiB5b3UgYXJlIGNvbnZlbmllbnQuIDxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyBhIGxvdC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PmJlc3QgcmVnYXJkcyA8YnI+PC9kaXY+PGRpdj5uYW5jeTxicj48L2Rpdj48YnI+PGRpdiBzdHls ZT0icG9zaXRpb246cmVsYXRpdmU7em9vbToxIj48L2Rpdj48ZGl2IGlkPSJkaXZOZXRlYXNlTWFp bENhcmQiPjwvZGl2PjxwcmU+PGJyPkF0IDIwMTgtMTAtMDkgMjE6NTY6MjMsICJRdWFuYWggR2li c29uLU1vdW50IiAmbHQ7cXVhbmFoQHN5bWFzLmNvbSZndDsgd3JvdGU6CiZndDstLU9uIFR1ZXNk YXksIE9jdG9iZXIgMDksIDIwMTggMTA6MDIgQU0gKzAwMDAgbmFubW9yQDEyNi5jb20gd3JvdGU6 CiZndDsKJmd0OyZndDsgV2UgY2FuIGdldCB0aGUgcmVzdWx0LCBidXQgZnJvbSBXaXJlc2hhcmsg cmVzdWx0LCB3ZSBmaW5kIHRoYXQgdGhleSB1c2VkCiZndDsmZ3Q7IFRMUzEuMiB0byBuZWdvdGlh dGVkLgomZ3Q7CiZndDtJIGRvIG5vdCBmaW5kIHRoaXMgdG8gYmUgdGhlIGNhc2Ugd2l0aCBPcGVu TERBUCAyLjQuNDYuCiZndDsKJmd0OyZndDsgVGhlIG9wZW5TU0wgaXMgc3VwcG9ydCBmb3IgVExT MS4zLGhvd2V2ZXIgb3BlbmxkYXAtMi40LjQ2IGlzIHN0aWxsIHVzZWQKJmd0OyZndDsgVExTMS4y IGJ5IGRlZmF1bHQuIE5lZWQgc29tZSBwYXJhbWV0ZXJzIHRvIHNwZWNpZnkgVExTMS4zIGluIG9w ZW5sZGFwCiZndDsmZ3Q7IGNvbmZpZ3VyYXRpb24/CiZndDsKJmd0O05vcGUuCiZndDsKJmd0OyZn dDsgQnkgdGhlIHdheSwgSSBoYXZlIHRlc3RlZCB0aGF0IG90aGVyIGFwcGxpY2F0aW9uIGNhbiBu ZWdvdGlhdGVkIHdpdGgKJmd0OyZndDsgVExTMS4zIGJ5IGRlZmF1bHQgd2hlbiB0aGUgY2xpZW50 IGFuZCBzZXJ2ZXIgYm90aCB1c2Ugb3BlbnNzbC0xLjEuMS4KJmd0OwomZ3Q7VGhhdCBpcyB0aGUg YmVoYXZpb3IgSSBzZWUuCiZndDsKJmd0O09wZW5MREFQIDIuNC40NiBsaW5rZWQgdG8gT3BlblNT TCAxLjEuMSBmb3IgYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXI6CiZndDsKJmd0OzViYmNiMjgy IGNvbm5lY3Rpb25fcmVhZCgxNCk6IGNoZWNraW5nIGZvciBpbnB1dCBvbiBpZD0xMDAxCiZndDtU TFMgdHJhY2U6IFNTTF9hY2NlcHQ6VExTdjEuMyBlYXJseSBkYXRhCiZndDtUTFMgdHJhY2U6IFNT TF9hY2NlcHQ6U1NMdjMvVExTIHJlYWQgZmluaXNoZWQKJmd0O1RMUyB0cmFjZTogU1NMX2FjY2Vw dDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKJmd0O1RMUyB0cmFjZTogU1NMX2FjY2Vw dDpTU0x2My9UTFMgd3JpdGUgc2Vzc2lvbiB0aWNrZXQKJmd0OwomZ3Q7UGVyaGFwcyB0aGUgbGRh cHNlYXJjaCB5b3UgcGlja2VkIHVwIHdhcyBub3QgdGhlIG9uZSBsaW5rZWQgdG8gT3BlblNTTCAK Jmd0OzEuMS4xLgomZ3Q7CiZndDtZb3UgbWF5IGFsc28gd2FudCB0byByZWFkIHRoZSBzbGFwZC5j b25mKDUpIG9yIHNsYXBkLWNvbmZpZyg1KSBtYW4gcGFnZXMgb24gCiZndDtob3cgdG8gc2V0IGEg bWluaW11bSByZXF1aXJlZCBUTFMgcHJvdG9jb2wgdmVyc2lvbi4KJmd0OwomZ3Q7UmVnYXJkcywK Jmd0O1F1YW5haAomZ3Q7CiZndDstLQomZ3Q7CiZndDtRdWFuYWggR2lic29uLU1vdW50CiZndDtQ cm9kdWN0IEFyY2hpdGVjdAomZ3Q7U3ltYXMgQ29ycG9yYXRpb24KJmd0O1BhY2thZ2VkLCBjZXJ0 aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUDoK Jmd0OyZsdDtodHRwOi8vd3d3LnN5bWFzLmNvbSZndDsKPC9wcmU+PC9kaXY+PGJyPjxicj48c3Bh biB0aXRsZT0ibmV0ZWFzZWZvb3RlciI+PHA+Jm5ic3A7PC9wPjwvc3Bhbj4= ------=_Part_53823_903760140.1539140876552--

1 0

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

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