openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

(ITS#7681) Bugfix for MDB_SET_RANGE
by claude.brisson＠gmail.com 05 Sep '13

05 Sep '13

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.

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