openldap-bugs September 2013

openldap-bugs@openldap.org

30 participants
114 discussions

Re: (ITS#7595) OpenLDAP lacks a ECDHE key generation callback
by hyc＠symas.com 07 Sep '13

07 Sep '13

crest(a)tzi.de wrote: > Full_Name: Jan Bramkamp > Version: 2.4.35 > OS: FreeBSD 9.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.230.127.217) > > > OpenLDAP supports PFS TLS cipher suites using DHE with the > DH *tlso_tmp_dh_cb(SSL*,int,int) callback in libraries/libldap/tls_o.c. > DHE-RSA/DSS cipher suites are very CPU intensive and noticeably increase latency > on low-power hardware. While OpenLDAP supports ECDH-ECDSA cipher suites these > lack the PFS offered by DHE-RSA/DSS cipher suites. > >>From my initial search it looks like the correct API to register such a callback > would be SSL_CTX_set_tmp_ecdh_callback(), but im not familiar the OpenLDAP code > base so patching it my self could have unintended consequences. > > This how the CA was generated: > CURVE=secp384r1 > > openssl ecparam -out private/ca-key.pem -name $CURVE -genkey && > openssl req -new -x509 -days 365 -key private/ca-key.pem -out > certs/ca-cert.pem > > openssl ecparam -out private/auth1-key.pem -name $CURVE -genkey && > openssl req -new -key private/auth1-key.pem -out newcerts/auth1-csr.pem && > openssl ca -config /usr/local/openssl/openssl.cnf -out certs/auth1-cert.pem > -infiles newcerts/auth1-csr.pem > > The (EC)DH paramter file was generated with: > openssl ecparam -name $CURVE > > This was tested with slapd linked against OpenSSL 1.0.1e from ports on FreeBSD > 9.1/amd64. It seems that current events have focused more attention on Perfect Forward Secrecy, now that news about NSA eavesdropping is everywhere. It's worth noting Bruce Schneier's recommendation to avoid Elliptic Curve algorithms, since their design has been heavily influenced by the NSA. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surve… (Section 5.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7506) Diffie-Hellman parameters (DHParamFile) are improperly handled
by hyc＠symas.com 07 Sep '13

07 Sep '13

Howard Chu wrote: > ben(a)bjencks.net wrote: >> I suppose I should attach a test case: > > Thanks, patches applied to master (with some tweaks). >> >> 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. For future reference, you can check this just using openssl s_client -connect localhost:6636 -debug -state SSL_connect:SSLv3 read server certificate A read from 0x16b0c20 [0x16b6cf3] (5 bytes => 5 (0x5)) 0000 - 16 03 02 03 0d ..... read from 0x16b0c20 [0x16b6cf8] (781 bytes => 781 (0x30D)) 0000 - 0c 00 03 09 01 00 a8 e0-4a 3d d1 d2 73 a8 bd 2e ........J=..s... In this case 0c 00 03 09 marks the Server Key Exchange and length, and 01 00 indicates 2048 bits (which matches the dhparams I used). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7506) Diffie-Hellman parameters (DHParamFile) are improperly handled
by hyc＠symas.com 07 Sep '13

07 Sep '13

ben(a)bjencks.net wrote: > I suppose I should attach a test case: Thanks, patches applied to master (with some tweaks). > > 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7685) Config directive TLSProtocolMin not converted to attribute olcTLSProtocolMin
by michael＠stroeder.com 06 Sep '13

06 Sep '13

Full_Name: Version: OS: URL: Submission from: (NULL) (79.219.124.115) I have in my static slapd.conf: TLSProtocolMin 3.2 I'd expect this to appear as attribute 'olcTLSProtocolMin' in cn=config but it's missing.

1 0

(ITS#7684) Admin Guide: Correct 'TLSEphemeralDHParamFile' to 'TLSDHParamFile'
by michael＠stroeder.com 06 Sep '13

06 Sep '13

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.124.115) The admin guide incorrectly mentions the configuration directive name 'TLSEphemeralDHParamFile' instead of 'TLSDHParamFile' like described in slapd.conf(5). See: http://www.openldap.org/doc/admin24/tls.html See this trivial patch: diff --git a/doc/guide/admin/aspell.en.pws b/doc/guide/admin/aspell.en.pws index 3683f98..9921963 100644 --- a/doc/guide/admin/aspell.en.pws +++ b/doc/guide/admin/aspell.en.pws @@ -23,7 +23,7 @@ ddd DAs TLSCACertificateFile BNF -TLSEphemeralDHParamFile +TLSDHParamFile ppolicy gavin ASN diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf index 00bf83c..9e3243e 100644 --- a/doc/guide/admin/tls.sdf +++ b/doc/guide/admin/tls.sdf @@ -188,7 +188,7 @@ and it doesn't need very much data to work. This directive is ignored with GnuTLS and Mozilla NSS. -H4: TLSEphemeralDHParamFile <filename> +H4: TLSDHParamFile <filename> This directive specifies the file that contains parameters for Diffie-Hellman ephemeral key exchange. This is required in order

1 0

(ITS#7683) Feature request: write TLS prot/cipher to syslog
by michael＠stroeder.com 06 Sep '13

06 Sep '13

Full_Name: Version: HEAD OS: URL: Submission from: (NULL) (79.219.124.115) For debugging which TLS protocol version and cipher suites were actually negotiated with several LDAP clients this information would be written to the syslog message. Current logging: conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 Suggestion: conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.1 tls_cipher=DHE-RSA-AES256-SHA256

1 0

Re: (ITS#7381) Dynamically added chaining configuration stops working after restart
by hyc＠symas.com 06 Sep '13

06 Sep '13

ian(a)uns.ac.rs wrote: > Full_Name: Ivan Nejgebauer > Version: 2.4.32 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ivannejgebauer-120905.tgz > Submission from: (NULL) (2001:4170:2000:2:213:d3ff:fecf:b9ea) > > > If a minimal chaining configuration is dynamically added to a consumer server in > a provider/consumer pair running delta-syncrepl, it will stop working when the > consumer is restarted. The configuration is modelled after the one used in > test022 in the OpenLDAP source distribution: Sorry this report was neglected for so long, and thanks for the excellent test case. This is now fixed in git master. > > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcOverlayConfig > objectClass: olcChainConfig > olcOverlay: {0}chain > > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectClass: olcLDAPConfig > objectClass: olcChainDatabase > olcDatabase: {0}ldap > olcDbIDAssertBind: bindmethod=simple binddn="cn=Manager,dc=example,dc=com" > credentials="secret" mode=self > olcDbURI: "ldap://localhost:6389" > > Scripts and data for replicating the issue are in the referenced archive. Quick > summary: > > # make clean-all master replica > # ./start-master.sh > # ./start-replica.sh > # ./replica-apply.sh pmod-add.ldif # returns referral > # ./replica-conf.sh chain.ldif # adds chaining configuration > # ./replica-apply.sh pmod-add.ldif # chains to master > # ./stop-replica.sh > # ./start-replica.sh > # ./replica-apply.sh pmod-del.ldif # returns referral, but shouldn't > > I have tested both 2.4.32 and git master > (54a111907b48900e1ce5de12a9d87818a334423d). > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by hyc＠symas.com 05 Sep '13

05 Sep '13

sog(a)msg.com.mx wrote: > Full_Name: Salvador Ortiz > Version: 24 > OS: Linux > URL: ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch > Submission from: (NULL) (187.162.45.111) > > > If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but according > to open(2): "Some file systems may not implement the flag and open() will > fail with EINVAL if it is used." > > In this cases mdb_env_copy should retry without the flag. > > The attached patch implements that. > > Thanks, applied. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by sog＠msg.com.mx 05 Sep '13

05 Sep '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch Submission from: (NULL) (187.162.45.111) If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but according to open(2): "Some file systems may not implement the flag and open() will fail with EINVAL if it is used." In this cases mdb_env_copy should retry without the flag. The attached patch implements that.

1 0

Re: (ITS#7681) Bugfix for MDB_SET_RANGE
by hyc＠symas.com 05 Sep '13

05 Sep '13

claude.brisson(a)gmail.com wrote: > Full_Name: Claude Brisson > Version: HEAD > OS: linux 64 > URL: ftp://ftp.openldap.org/incoming/0001-fix-mdb_cursor_set-behaviour-for-MDB_S… > Submission from: (NULL) (84.103.74.195) > > > When no other page was found while provided key is less than found key, > mdb_cursor_get should not return MDB_NOTFOUND. > > The attached patch is a proposal to fix the behaviour of mdb_cursor_set for > MDB_SET_RANGE. Please review that it is correct before integration. Thanks. exactp is always NULL when using SET_RANGE, so that part of the patch is unnecessary. Otherwise looks OK. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2013