openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: ITS#8654 - Option for LDAP client to bind to a local address
by Howard Chu 22 May '17

22 May '17

Daniel Le wrote: > Hello, > > In reference to the enhancement request ITS#865, please comment on the following to add support for binding a local IP address to client socket. This is just an outline of changes for one local address. I am not sure whether a list of local addresses is necessary. If it is, then a new function, similarly to ldap_url_parsehosts, may be written to parse the list of local addresses and store them into a linked list. In my use case, only one IPv4 or IPv6 local address is used for binding. As I commented in the ITS, since there is no existing IETF spec for this option, and since there is an existing implementation in Microsoft's API, we should copy the Microsoft API behavior, to maintain source level compatibility and make app developers' lives easier. Since they support a list of IP addresses, so should we. > > - Modify ldap.h and ldap_set_option to handle the new option LDAP_OPT_LOCAL_ADDRESS. > Should it be named LDAP_OPT_CLIENT_ADDRESS, LDAP_OPT_SOCKET_BIND_ADDRESS...? > > - Modify struct ldapoptions in ldap-int.h to add element "char *ldo_local_address" to hold client local address when ldap_set_option(LDAP_OPT_LOCAL_ADDRESS...) is executed. > This can char pointer can point to an IPv4 address or IPv6 address. > > - ldap_connect_to_host() in os-ip.c > After the connection socket is created (ldap_int_socket) and before it is connected (ldap_pvt_connect), extract the local IP address. > If local address family (AF_INET/ AF_INET6) matches the one of the host, bind socket to the local address. > > Regards, > Daniel > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: ITS#8654 - Option for LDAP client to bind to a local address
by Quanah Gibson-Mount 22 May '17

22 May '17

--On Monday, May 22, 2017 2:56 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > Daniel Le wrote: >> Hello, >> >> In reference to the enhancement request ITS#865, please comment on the >> following to add support for binding a local IP address to client >> socket. This is just an outline of changes for one local address. I am >> not sure whether a list of local addresses is necessary. If it is, then >> a new function, similarly to ldap_url_parsehosts, may be written to >> parse the list of local addresses and store them into a linked list. In >> my use case, only one IPv4 or IPv6 local address is used for binding. > > As I commented in the ITS, since there is no existing IETF spec for this > option, and since there is an existing implementation in Microsoft's API, > we should copy the Microsoft API behavior, to maintain source level > compatibility and make app developers' lives easier. It would be nice to able to set the option for client tools via the "-o" flag as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Additional bug in OpenLDAP TLS code
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Wednesday, May 10, 2017 11:19 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Quanah Gibson-Mount wrote: >> Attempting to connect via ldapsearch to ldap://127.0.0.1 and initiate >> startTLS will fail, as the IP gets mapped to "localhost", and then the >> FQDN check fails. > > Yes, this is a bug. Especially since the mapping to "localhost" does not > have a trustable source for this mapping. Bah, never mind. I had a runaway slapd with old cert info running. It does work in this scenario correctly. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Additional bug in OpenLDAP TLS code
by Quanah Gibson-Mount 10 May '17

10 May '17

In testing a suggestion from Howard, it appears that OpenLDAP code is broken for IP based certs (where the IP: <addr> is in subject Alternative Name), as it does a hostname lookup prior to validating the cert. This is trivially demonstrable using a cert with: X509v3 Subject Alternative Name: DNS:localhost, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1 Attempting to connect via ldapsearch to ldap://127.0.0.1 and initiate startTLS will fail, as the IP gets mapped to "localhost", and then the FQDN check fails. But this would imply any attempt to use the IP: values in subject Alternative Name will be a problem, since "name_in" is translated. --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 Howard Chu 10 May '17

10 May '17

Quanah Gibson-Mount wrote: > --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. Wrong. The FQDN of the system is the entire point of this discussion. Cert verification is based first and primarily on hostnames. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel