openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#7506) Diffie-Hellman parameters (DHParamFile) are improperly handled
by ben＠bjencks.net 27 Jan '13

27 Jan '13

I suppose I should attach a test case: cd $WORKDIR openssl dhparam 1536 > dh1536.pem openssl req -new -newkey rsa:2048 -keyout server.key \ -out server.crt -sha256 -nodes -subj '/CN=localhost/' -x509 For GnuTLS, load the following config: dn: cn=config objectClass: olcGlobal cn: config olcTLSCertificateFile: $WORKDIR/server.crt olcTLSCertificateKeyFile: $WORKDIR/server.key olcTLSCipherSuite: NONE:+VERS-TLS1.1:+VERS-TLS1.0:+AES-128-CBC: +DHE-RSA:+SHA1:+COMP-NULL olcTLSDHParamFile: $WORKDIR/dh1536.pem dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config For Openssl, change olcTLSCipherSuite to: olcTLSCipherSuite: aRSA+AES128+kEDH Start up slapd with the config, listening on ldaps://localhost:6636. openssl s_client -connect localhost:6636 With GnuTLS this will fail negotiation; with OpenSSL it will use 1024 bit parameters rather than the 1536 bits params we specified. The only way I've found to find the actual parameter size is to tcpdump the negotiation. First, verify that the negotiated cipher suite is DHE-RSA-AES128-SHA according to s_client, then: tcpdump -i lo -wldap.pcap port 6636 wireshark ldap.pcap Apply the SSL decode to the traffic (right click on packet, Decode As, Transport tab, SSL), find the Server Key Exchange packet, select the Server Key Exchange portion of the handshake message, and look at the hex dump. It should start with 0c, followed by a three byte size, then the next two bytes are the length of the DH parameters: 0080 for 1024 bits, 00c0 for 1536 bits. On 01/27/2013 07:13 PM, openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7506. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7506) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#7506) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=7506 > > Please remember to retain your issue tracking number (ITS#7506) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

(ITS#7506) Diffie-Hellman parameters (DHParamFile) are improperly handled
by ben＠bjencks.net 27 Jan '13

27 Jan '13

Full_Name: Ben Jencks Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:8:580:1d:5e6:2c43:96d0:4503) Both tls_g.c for GnuTLS and tls_o.c for OpenSSL have major problems in their handling of DHParamFile. Additionally, the documentation is not entirely accurate. For GnuTLS, DH parameters are entirely unimplemented. There appears to be an attempt at generating them in tlsg_ctx_init, but they're never attached to ctx->cred, so they're unused. Additionally, the size is hardcoded. For OpenSSL, there's an attempt to support multiple sizes, but unfortunately it's misusing the OpenSSL API and only 512 or 1024 bit parameters will ever be used. The callback with specified size is only useful for export ciphers: the size isn't negotiated, it's only specified as a maximum when the export flag is set [1]. You want to specify exactly one size and parameter set. The documentation refers to a non-existent TLSEphemeralDHParamFile option. Patches are available below: http://www.bjencks.net/openldap/0001-tls_g.c-Properly-support-DHParamFile.p… http://www.bjencks.net/openldap/0002-tls_o.c-Fix-Diffie-Hellman-parameter-u… http://www.bjencks.net/openldap/0003-DHParamFile-Update-docs.patch I'm a little uncomfortable with leaving a hardcoded parameter set in the OpenSSL code, but I figured it would break compatibility to remove it. A better solution (and the one recommended by OpenSSL) is to add parameter generation to the install scripts. If you'd prefer that, I can modify the patch to get rid of the hardcoded parameter and just not set a DH on the SSL_CTX without a file specified. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Meddius. Meddius has not assigned rights and/or interest in this work to any party. I, Ben Jencks am authorized by Meddius, my employer, to release this work under the following terms. Meddius hereby places the attached modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. [1] http://permalink.gmane.org/gmane.comp.encryption.openssl.user/45805

1 0

Re: (ITS#7503) slapcat: retry a few times when retrieving an entry
by quanah＠zimbra.com 27 Jan '13

27 Jan '13

--On Sunday, January 27, 2013 10:03 PM +0100 Bálint Réczey <balint(a)balintreczey.hu> wrote: > I'll let OpenLDAP developers fix the problem where they find it > appropriate instead. > My intention was adding a retry logic where there was a skip and > continue logic already, in slapcat. Hi Balint, I understand your intent, I'm simply noting it was the wrong approach. Supplying a patch that fixes the actual issue, if you choose to do so, simply means it will have a greater chance of being fixed sooner than later. I.e., it is not a high priority issue at this time for the openldap devs. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7501) added TCP keepalive support to back_ldap
by quanah＠zimbra.com 27 Jan '13

27 Jan '13

--On Sunday, January 27, 2013 7:56 PM +0000 tedcheng(a)symas.com wrote: > Hi Quanah, > > On Jan 27, 2013, at 10:02 AM, Quanah Gibson-Mount wrote: >> >> This has been applied to HEAD and RE24, but it has exposed two issues. >> >> 1) This has broken back-ldap with dynamic configuration > > I got a bug report that the static configuration of the keepalive > parameter does not get successfully converted to dynamic configuration. > Is this the same issue as yours? If not, could you elaborate further? Hi Ted, Yes, the same issue. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7503) slapcat: retry a few times when retrieving an entry
by balint＠balintreczey.hu 27 Jan '13

27 Jan '13

2013/1/27 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, January 25, 2013 10:26 PM +0000 balint(a)balintreczey.hu wrote: > >> Full_Name: Balint Reczey >> Version: master >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.0.168.17) > > > Hi Balint, > > The patch as submitted is rejected, due to the fact that it changes slapadd, > rather than fixing back-bdb/hdb, which is where the actual problem occurs. > I.e., your change is too broad. Feel free to submit an updated patch > correctly updating the back-bdb/hdb code rather than slapadd. > > Thanks, > Quanah > Hi Quanah, I'll let OpenLDAP developers fix the problem where they find it appropriate instead. My intention was adding a retry logic where there was a skip and continue logic already, in slapcat. Cheers, Balint

1 0

Re: (ITS#7501) added TCP keepalive support to back_ldap
by tedcheng＠symas.com 27 Jan '13

27 Jan '13

Hi Quanah, On Jan 27, 2013, at 10:02 AM, Quanah Gibson-Mount wrote: > > This has been applied to HEAD and RE24, but it has exposed two issues. > > 1) This has broken back-ldap with dynamic configuration I got a bug report that the static configuration of the keepalive parameter does not get successfully converted to dynamic configuration. Is this the same issue as yours? If not, could you elaborate further? Thanks, Ted C. Cheng Symas Corporation

1 0

Re: (ITS#7503) slapcat: retry a few times when retrieving an entry
by quanah＠zimbra.com 27 Jan '13

27 Jan '13

--On Sunday, January 27, 2013 6:09 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, January 25, 2013 10:26 PM +0000 balint(a)balintreczey.hu wrote: > >> Full_Name: Balint Reczey >> Version: master >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.0.168.17) > > Hi Balint, > > The patch as submitted is rejected, due to the fact that it changes > slapadd, rather than fixing back-bdb/hdb, which is where the actual > problem occurs. I.e., your change is too broad. Feel free to submit > an updated patch correctly updating the back-bdb/hdb code rather than > slapadd. s/slapadd/slapcat/g ;) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7503) slapcat: retry a few times when retrieving an entry
by quanah＠zimbra.com 27 Jan '13

27 Jan '13

--On Friday, January 25, 2013 10:26 PM +0000 balint(a)balintreczey.hu wrote: > Full_Name: Balint Reczey > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.0.168.17) Hi Balint, The patch as submitted is rejected, due to the fact that it changes slapadd, rather than fixing back-bdb/hdb, which is where the actual problem occurs. I.e., your change is too broad. Feel free to submit an updated patch correctly updating the back-bdb/hdb code rather than slapadd. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7501) added TCP keepalive support to back_ldap
by quanah＠zimbra.com 27 Jan '13

27 Jan '13

--On Thursday, January 24, 2013 4:16 PM +0000 tedcheng(a)symas.com wrote: > > On Jan 24, 2013, at 5:32 AM, Howard Chu wrote: > >> tedcheng(a)symas.com wrote: >>> Full_Name: Ted C. Cheng >>> Version: master >>> OS: Linux/Solaris >>> URL: https://dl.dropbox.com/u/94235048/back_ldap_tcp_keepalive.patch >>> Submission from: (NULL) (76.174.253.197) Hi Ted, This has been applied to HEAD and RE24, but it has exposed two issues. 1) This has broken back-ldap with dynamic configuration 2) back-meta should be updated to support this parameter as well. Can you please supply an updated patch based off current RE24 and HEAD addressing these two issues. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7505) liblmdb can fail with MDB_PAGE_FULL on a delete
by hyc＠OpenLDAP.org 27 Jan '13

27 Jan '13

Full_Name: Howard Chu Version: RE24/master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc This is the last remaining FIXME in liblmdb/mdb.c... mdb_rebalance() is always called after a delete operation. If the tree needs balancing and it needs to move a node from one page to its sibling, the parent page's separator keys will need updating. If the new separator key is larger than the old one, it may not fit into the parent page, and mdb_update_key() will return MDB_PAGE_FULL. Instead of giving up, mdb_update_key() should invoke mdb_page_split() to make room for the new key.

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