openldap-devel

openldap-devel@openldap.org

1 participants
1421 discussions

Re: Bug in tlso_session_chkhost?
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Wednesday, May 10, 2017 7:01 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> --On Wednesday, May 10, 2017 4:21 PM +0100 Howard Chu <hyc(a)symas.com> >> wrote: >> >>> No. One or the other must match, but the CN must be an FQDN. The point >>> of alternatives is to support wildcards, aliases, and non-DNS name forms >>> (such as IP address). >> >> RFC reference? > > RFC 6125 which in turn mentions RFC 4513. Thanks. >From RFC 6125: 6.4.4. Checking of Common Names As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client. Therefore, as I noted, the certcn is immaterial since I have a DNS: value specified, and it is then required that the certcn be ignored. The rest of the RFC doesn't really cover special cases like localhost. I still see nothing in the RFC that states what's I'm doing is invalid. It does appear to be outside of what's normally done, but that's not surprising. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

Re: Bug in tlso_session_chkhost?
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Wednesday, May 10, 2017 10:49 AM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > On Wed, May 10, 2017 at 09:32:59AM -0700, Quanah Gibson-Mount wrote: >> RFC 6761 specifically notes that "localhost." is in fact a domain name >> (Section 6.3). Therefore, my certificates are in fact correct, and >> the OpenLDAP code check is indeed a bug. > > "localhost." is a perfectly valid FQDN (as is the relatively common > "localhost.localdomain."), but from earlier in the thread I gathered your > system's FQDN is actually "u16build." or "u16build.some.domain.". The FQDN of the system is immaterial. The point is to have a certificate without *any* reference to the system hostname, and be entirely based on localhost. The RFCs seem to indicate that is perfectly legitimate. It is the OpenLDAP code check that breaks this ability. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Bug in tlso_session_chkhost?
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Wednesday, May 10, 2017 10:11 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> RFC 6125 which in turn mentions RFC 4513. > > Thanks. > >> From RFC 6125: > > 6.4.4. Checking of Common Names > > As noted, a client MUST NOT seek a match for a reference identifier > of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, > URI-ID, or any application-specific identifier types supported by the > client. > > > Therefore, as I noted, the certcn is immaterial since I have a DNS: value > specified, and it is then required that the certcn be ignored. The rest > of the RFC doesn't really cover special cases like localhost. I still > see nothing in the RFC that states what's I'm doing is invalid. It does > appear to be outside of what's normally done, but that's not surprising. RFC 6761 specifically notes that "localhost." is in fact a domain name (Section 6.3). Therefore, my certificates are in fact correct, and the OpenLDAP code check is indeed a bug. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Bug in tlso_session_chkhost?
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Tuesday, May 09, 2017 10:58 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: >> "subjectAltName" means *alternative* name. It is totally correct for >> libldap to reject your cert with a hostname mismatch when the cert cn is >> incorrect. > > Human language can cause misunderstandings. So maybe I misread your > statement. But I'm reading your sentence that the CN must always match or > at least be a FQDN even if a subjectAltName value already matched. Right now, it requires that a value in subjectAltName match the local host name, which is also invalid. I know the purpose of the check is to allow someone to use -H ldap://localhost to the ldap client, where the cert only exists for the hostname (I.e., it has no DNS:localhost value). However, the current code I maintain is incorrect in that it invalidates the current case, where everything is restricted to "localhost". Quite frankly, the certcn can technically be anything, as long as at least one value in subjectAltName matches. Unfortunately, I can't do an IP based cert either, since I've no idea what "localhost" will actually map to on the system. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

Re: Bug in tlso_session_chkhost?
by Howard Chu 09 May '17

09 May '17

Quanah Gibson-Mount wrote: > For the test suite, I've generated a server cert with: > > Subject: C=US, ST=CA, O=OpenLDAP Foundation, OU=OpenLDAP Test Suite, CN=localhost > > and > > X509v3 Subject Alternative Name: > DNS:localhost > > slapd is listening as: > > /home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/servers/slapd/.libs/lt-slapd > -s0 -f > /home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/tests/testrun/slapd.1.conf > -h ldap://localhost:9011/ ldaps://localhost:9012/ -d 0x4105 > > > I.e., slapd is referring to itself as "localhost", and the cert fully refers > to itself as "localhost". > > However, if I do a startTLS op to this host with reqcert set to "demand", it > fails with: > > TLS: hostname (u16build) does not match common name in certificate (localhost). > > Given that everything is using "localhost", it seems to me it should succeed > rather than fail, and that this error is incorrect. > > The issue seems to be this if statement in tls_o.c: > > if( ldap_int_hostname && > ( !name_in || !strcasecmp( name_in, "localhost" ) ) ) > { > > > if I remove the check against the "localhost" name, things succeed as expected. Fwiw, I routinely test with a localhost cert, and this check has never tripped for me. But my ldap_int_hostname is also "localhost" - apparently something on your system insists that your hostname is "u16build". -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 3

Re: Bug in tlso_session_chkhost?
by Quanah Gibson-Mount 09 May '17

09 May '17

--On Tuesday, May 09, 2017 9:09 AM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, May 09, 2017 11:01 AM +0100 Howard Chu <hyc(a)symas.com> > wrote: > >>> if I remove the check against the "localhost" name, things succeed as >>> expected. >> >> Fwiw, I routinely test with a localhost cert, and this check has never >> tripped for me. But my ldap_int_hostname is also "localhost" - apparently >> something on your system insists that your hostname is "u16build". > > One of the main tenants ugh, tenets even. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Bug in tlso_session_chkhost?
by Howard Chu 09 May '17

09 May '17

Quanah Gibson-Mount wrote: > For the test suite, I've generated a server cert with: > > Subject: C=US, ST=CA, O=OpenLDAP Foundation, OU=OpenLDAP Test Suite, CN=localhost > > and > > X509v3 Subject Alternative Name: > DNS:localhost > > slapd is listening as: > > /home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/servers/slapd/.libs/lt-slapd > -s0 -f > /home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/tests/testrun/slapd.1.conf > -h ldap://localhost:9011/ ldaps://localhost:9012/ -d 0x4105 > > > I.e., slapd is referring to itself as "localhost", and the cert fully refers > to itself as "localhost". > > However, if I do a startTLS op to this host with reqcert set to "demand", it > fails with: > > TLS: hostname (u16build) does not match common name in certificate (localhost). > > Given that everything is using "localhost", it seems to me it should succeed > rather than fail, and that this error is incorrect. > > The issue seems to be this if statement in tls_o.c: > > if( ldap_int_hostname && > ( !name_in || !strcasecmp( name_in, "localhost" ) ) ) > { > > > if I remove the check against the "localhost" name, things succeed as expected. > > Is there something valid we are trying to protect against here? "localhost" isn't a real hostname. If your host has a real hostname, it gets used. That code has existed since 2001: commit 943800a53433989fdf6e65ac8971459c48301399 > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > -- -- 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

Bug in tlso_session_chkhost?
by Quanah Gibson-Mount 08 May '17

08 May '17

For the test suite, I've generated a server cert with: Subject: C=US, ST=CA, O=OpenLDAP Foundation, OU=OpenLDAP Test Suite, CN=localhost and X509v3 Subject Alternative Name: DNS:localhost slapd is listening as: /home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/servers/slapd/.libs/lt-slapd -s0 -f /home/build/git/symas-packages/thirdparty/openldap/build/UBUNTU16_64/symas-openldap/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ ldaps://localhost:9012/ -d 0x4105 I.e., slapd is referring to itself as "localhost", and the cert fully refers to itself as "localhost". However, if I do a startTLS op to this host with reqcert set to "demand", it fails with: TLS: hostname (u16build) does not match common name in certificate (localhost). Given that everything is using "localhost", it seems to me it should succeed rather than fail, and that this error is incorrect. The issue seems to be this if statement in tls_o.c: if( ldap_int_hostname && ( !name_in || !strcasecmp( name_in, "localhost" ) ) ) { if I remove the check against the "localhost" name, things succeed as expected. Is there something valid we are trying to protect against here? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Fwd: Discussion on Hacker News about CMU discontinuing Cyrus
by Howard Chu 08 May '17

08 May '17

I wonder if we should look into adopting a different SASL library. FastMail may create a new home for Cyrus IMAP, but they don't seem to spend much attention on SASL.

1 0

Re: RE24 testing call #2 (2.4.45) LMDB RE0.9 testing call #2 (0.9.20)
by Quanah Gibson-Mount 30 Apr '17

30 Apr '17

Please upload the testrun directory as a tar.gz to ftp.openldap.org/incoming/ with a relevant filename, and let us know what it is so it can be examined. It may simply be a timing issue, but I'd like to confirm. Thanks! --Quanah --On Friday, April 28, 2017 3:31 PM +0200 Abdelkader Chelouah <a.chelouah(a)gmail.com> wrote: > > Built and tested OPENLDAP_REL_ENG_2_4-g66d107e (OS RHEL 7) > > "make mdb-its" succeded but "make mdb" failed on test018 with error > > >>>>>> Starting test018-syncreplication-persist for mdb... > running defines.sh > Starting provider slapd on TCP/IP port 9011... > Using ldapsearch to check that provider slapd is running... > Using ldapadd to create the context prefix entry in the provider... > Starting consumer slapd on TCP/IP port 9014... > Using ldapsearch to check that consumer slapd is running... > Waiting 5 seconds for slapd to start... > Using ldapadd to populate the provider directory... > Waiting 7 seconds for syncrepl to receive changes... > Using ldapsearch to read all the entries from the provider... > Using ldapsearch to read all the entries from the consumer... > Filtering provider results... > Filtering consumer results... > Comparing retrieved entries from provider and consumer... > Stopping the provider, sleeping 10 seconds and restarting it... > Using ldapsearch to check that provider slapd is running... > Waiting 7 seconds for consumer to reconnect... > Using ldapmodify to modify provider directory... > Using ldappasswd to change some passwords... > Waiting 7 seconds for syncrepl to receive changes... > Using ldapsearch to read all the entries from the provider... > Using ldapsearch to read all the entries from the consumer... > Filtering provider results... > Filtering consumer results... > Comparing retrieved entries from provider and consumer... > test failed - provider and consumer databases differ >>>>>> test018-syncreplication-persist failed for mdb > (exit 1) > make: *** [mdb-mod] Error 1 > > > > On Fri, Apr 28, 2017 at 12:33 AM, Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > > For this testing call, we particularly need folks to test OpenLDAP with > startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and > with the 1.1 series). This was reworked since the prior testing call, > as the OpenSSL 1.1.0 work was not correct. There is currenly nothing in > the test suite that covers encrypted connections (Although it's on my > todo list). To build against OpenSSL 1.1 may also require cyrus-sasl HEAD > out of the cyrus-sasl GIT repository, depending on your build options as > the current cyrus-sasl release does not support the OpenSSL 1.1 series. > It can be found at <https://github.com/cyrusimap/cyrus-sasl>. If you > build with GSSAPI and use Heimdal, you will also need the Heimdal 7.1.0 > or later release (as that is where OpenSSL 1.1 support was added). It > can be obtained from <http://h5l.org/>. > > Also new with this release is the ability to run "make its" in the tests/ > directory. This will run a specific set of tests around past bugs to > ensure there are no regressions. While I've tested this with modular > openldap builds, it has not been tested with the modules and backends > built into slapd, so there could be some issues in that scenario. > > OpenLDAP 2.4.45 Engineering > Added slapd support for OpenSSL 1.1.0 series (ITS#8353, > ITS#8533, ITS#8634) > Fixed libldap to fail ldap_result if the handle is already bad > (ITS#8585) > Fixed libldap to expose error if user specified CA doesn't > exist (ITS#8529) > Fixed libldap handling of Diffie-Hellman parameters (ITS#7506) > Fixed libldap GnuTLS use after free (ITS#8385) > Fixed slapd bconfig rDN escape handling (ITS#8574) > Fixed slapd segfault with invalid hostname (ITS#8631) > Fixed slapd sasl SEGV rebind in same session (ITS#8568) > Fixed slapd syncrepl filter handling (ITS#8413) > Fixed slapd syncrepl infinite looping mods with delta-sync MMR > (ITS#8432) > Fixed slapd callback struct so older modules without writewait > should function. > Custom modules may need to be updated for > sc_writewait callback (ITS#8435) > Fixed slapd-ldap/meta broken LDAP_TAILQ macro (ITS#8576) > Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794) > Fixed slapd-meta uninitialized diagnostic message (ITS#8442) > Fixed slapo-accesslog to honor pauses during purge for > cn=config update (ITS#8423) > Fixed slapo-accesslog with multiple modifications to the same > attribute (ITS#6545) > Fixed slapo-relay to correctly initialize sc_writewait > (ITS#8428) > Fixed slapo-sssvlv double free (ITS#8592) > Fixed slapo-unique with empty modifications (ITS#8266) > Build Environment > Added test065 for proxyauthz (ITS#8571) > Fix test008 to be portable (ITS#8414) > Fix test064 to wait for slapd to start (ITS#8644) > Fix its4336 regression test (ITS#8534) > Fix its4337 regression test (ITS#8535) > Fix regression tests to execute on all backends > (ITS#8539) > Contrib > Added slapo-autogroup(5) man page (ITS#8569) > Added passwd missing conversion scripts for apr1 > (ITS#6826) > Fixed contrib modules where the writewait callback > was not correctly initialized (ITS#8435) > Fixed smbk5pwd to build with newer OpenSSL > releases (ITS#8525) > Documentation > admin24 fixed tls_cipher_suite bindconf option > (ITS#8099) > admin24 fixed typo cn=config to be slapd.d > (ITS#8449) > admin24 fixed slapo-syncprov information to be > curent (ITS#8253) > admin24 fixed typo in access control docs > (ITS#7341, ITS#8391) > admin24 fixed minor typo in tuning guide (ITS#8499) > admin24 fixed information about the limits option > (ITS#7700) > admin24 fixed missing options for syncrepl > configuration (ITS#7700) > admin24 fixed accesslog documentation to note it > should not be replicated (ITS#8344) > Fixed ldap.conf(5) missing information on > SASL_NOCANON option (ITS#7177) > Fixed ldapsearch(1) information on the V[V] flag > behavior (ITS#7177, ITS#6339) > Fixed slapd-config(5), slapd.conf(5) clarification > on interval keyword for refreshAndPersist (ITS#8538) > Fixed slapd-config(5), slapd.conf(5) clarify > serverID requirements (ITS#8635) > Fixed slapd-config(5), slapd.conf(5) clarification > on loglevel settings (ITS#8123) > Fixed slapo-ppolicy(5) to clearly note rootdn > requirement (ITS#8565) > Fixed slapo-memberof(5) to note it is not safe to > use with replication (ITS#8613) > Fixed slapo-syncprov(5) documentation to be > current (ITS#8253) > Fixed slapadd(8) manpage to note slapd-mdb > (ITS#8215) > Fixed various minor grammar issues in the man > pages (ITS#8544) > Fixed various typos (ITS#8587) > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel