Full_Name: Singam Sudhir Reddy Version: master branch OS: fedora URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180506.patch Submission from: (NULL) (61.1.232.154) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA hereby place the following 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. **** Description: This is minor enhancement to introduce a new LDAP option "LDAP_OPT_X_TLS_DEMAND_EXCL_HOSTNAME_CHECK" to ignore hostname checking by client in TLS communication mode. This is very similar to "LDAP_OPT_X_TLS_DEMAND" LDAP option except that HOSTNAME checking is ignored. This option can be set by client either by using LDAP API "ldap_set_option" or can be globally set in the configuration file /etc/openldap/ldap.conf like below. TLS_REQCERT demand_excl_hostname_check Purpose: Generally operators use same set of certificates for different services (from different hosts) which support TLS communication. When such certificates are used, this option gives facility for openldap based services to ignore hostname checking at client side. ****
sudhir.singam@nokia.com wrote: > Full_Name: Singam Sudhir Reddy > Version: master branch > OS: fedora > URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180506.patch > Submission from: (NULL) (61.1.232.154) > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. > I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work > under the following terms. > > NOKIA hereby place the following 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. > > **** > Description: > > This is minor enhancement to introduce a new LDAP option > "LDAP_OPT_X_TLS_DEMAND_EXCL_HOSTNAME_CHECK" to ignore hostname checking by > client in TLS communication mode. This is very similar to > "LDAP_OPT_X_TLS_DEMAND" LDAP option except that HOSTNAME checking is ignored. > > This option can be set by client either by using LDAP API "ldap_set_option" or > can be globally set in the configuration file /etc/openldap/ldap.conf like > below. > > TLS_REQCERT demand_excl_hostname_check > > Purpose: > > Generally operators use same set of certificates for different services (from > different hosts) which support TLS communication. When such certificates are > used, this option gives facility for openldap based services to ignore hostname > checking at client side. No. If you're using a single set of certificates for multiple hosts you should be using a wildcard cert. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi, Thanks for your response. Basically our use case can be below or any similar one where we want to disable hostname checking. a) We want use the same certs from multi domains b) We want use the same certs for all sub domains under a main domain. c) DNS server is not set up I.e., the certificate could be issued with a name like “netact.operator”, but we’d be using 10.2.3.7, and DNS has not been setup in the operator internal network But what we feel is that there should be an option to be chosen by user to either ignore or enable hostname checking. Already we know that HTTP clients, for example, browsers provide such option to user and it's up to the user that whether to continue communication to the server or not, if hostname mismatch occurs. RFC http://www.ietf.org/rfc/rfc2818.txt (for HTTP) says below, which means for interactive or AUTOMATED clients option should be provided. " If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. " RFC https://tools.ietf.org/html/rfc4513 (LDAP) says below, that AUTOMATED client should log error but not provide any configurable option. “ If the server identity check fails, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect or both. “ Not sure how the AUTOMATED clients differ for HTTP or LDAP. So I would like to know why this is not implemented or can't be implemented for openLDAP. Regards, Sudhir Singam DELIVERING BEST-IN-CLASS PLATFORM is our vision -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Sunday, May 06, 2018 11:45 PM To: Singam, Sudhir (Nokia - IN/Bangalore) <sudhir.singam@nokia.com>; openldap-its@OpenLDAP.org Subject: Re: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode sudhir.singam@nokia.com wrote: > Full_Name: Singam Sudhir Reddy > Version: master branch > OS: fedora > URL: ftp://ftp.openldap.org/incoming/sudhirsingam-180506.patch > Submission from: (NULL) (61.1.232.154) > > > The attached file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. > I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work > under the following terms. > > NOKIA hereby place the following 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. > > **** > Description: > > This is minor enhancement to introduce a new LDAP option > "LDAP_OPT_X_TLS_DEMAND_EXCL_HOSTNAME_CHECK" to ignore hostname checking by > client in TLS communication mode. This is very similar to > "LDAP_OPT_X_TLS_DEMAND" LDAP option except that HOSTNAME checking is ignored. > > This option can be set by client either by using LDAP API "ldap_set_option" or > can be globally set in the configuration file /etc/openldap/ldap.conf like > below. > > TLS_REQCERT demand_excl_hostname_check > > Purpose: > > Generally operators use same set of certificates for different services (from > different hosts) which support TLS communication. When such certificates are > used, this option gives facility for openldap based services to ignore hostname > checking at client side. No. If you're using a single set of certificates for multiple hosts you should be using a wildcard cert. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi, Thanks for your response. Basically our use case can be below or any similar one where we want to disable hostname checking. a) We want use the same certs from multi domains b) We want use the same certs for all sub domains under a main domain. c) DNS server is not set up I.e., the certificate could be issued with a name like “netact.operator”, but we’d be using 10.2.3.7, and DNS has not been setup in the operator internal network But what we feel is that there should be an option to be chosen by user to either ignore or enable hostname checking. Already we know that HTTP clients, for example, browsers provide such option to user and it's up to the user that whether to continue communication to the server or not, if hostname mismatch occurs. RFC http://www.ietf.org/rfc/rfc2818.txt (for HTTP) says below, which means for interactive or AUTOMATED clients option should be provided. " If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. " RFC https://tools.ietf.org/html/rfc4513 (LDAP) says below, that AUTOMATED client should log error but not provide any configurable option. “ If the server identity check fails, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect or both. “ Not sure how the AUTOMATED clients differ for HTTP or LDAP. So I would like to know why this is not implemented or can't be implemented for openLDAP.
Hi, Kindly please reply. Regards, Sudhir Singam DELIVERING BEST-IN-CLASS PLATFORM is our vision -----Original Message----- From: Singam, Sudhir (Nokia - IN/Bangalore) Sent: Wednesday, May 09, 2018 11:26 AM To: 'Howard Chu' <hyc@symas.com>; 'openldap-its@OpenLDAP.org' <openldap-its@OpenLDAP.org> Subject: RE: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode Hi, Thanks for your response. Basically our use case can be below or any similar one where we want to disable hostname checking. a) We want use the same certs from multi domains b) We want use the same certs for all sub domains under a main domain. c) DNS server is not set up I.e., the certificate could be issued with a name like “netact.operator”, but we’d be using 10.2.3.7, and DNS has not been setup in the operator internal network But what we feel is that there should be an option to be chosen by user to either ignore or enable hostname checking. Already we know that HTTP clients, for example, browsers provide such option to user and it's up to the user that whether to continue communication to the server or not, if hostname mismatch occurs. RFC http://www.ietf.org/rfc/rfc2818.txt (for HTTP) says below, which means for interactive or AUTOMATED clients option should be provided. " If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. " RFC https://tools.ietf.org/html/rfc4513 (LDAP) says below, that AUTOMATED client should log error but not provide any configurable option. “ If the server identity check fails, user-oriented clients SHOULD either notify the user (clients may give the user the opportunity to continue with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect. Automated clients SHOULD close the transport connection and then return or log an error indicating that the server's identity is suspect or both. “ Not sure how the AUTOMATED clients differ for HTTP or LDAP. So I would like to know why this is not implemented or can't be implemented for openLDAP.
> c) DNS server is not set up I.e., the certificate could be issued > with a name like “netact.operator”, but we’d be using 10.2.3.7, and > DNS has not been setup in the operator internal network > > But what we feel is that there should be an option to be chosen by > user to either ignore or enable hostname checking. If you're using ldaps://10.2.3.7 for connecting without DNS resolving you could add a subjectAltName extension to your server cert containing this particular IP address. That's basically just another GeneralName type. You could also tweak your local /etc/hosts (preferrably with decent config mgt.) to correctly map FQDN "netact.operator" to the IP address. > Already we know > that HTTP clients, for example, browsers provide such option to user > and it's up to the user that whether to continue communication to the > server or not, if hostname mismatch occurs. Note that web browsers are driven interactively by users whereas LDAP clients are most times systems without direct user interaction. In the interactive case you simply delegate the informed trust decision to the user which is a bad thing to do anyway. Therefore web browsers will also limit this functionality in the not so far future. Ciao, Michael. P.S.: Due to MIME processing deficiencies of the ITS your messages are displayed base64-encoded and therefore hard to read: https://www.openldap.org/its/index.cgi?findid=8846#followup4
Hi,
Hi, Thanks for the reply. For DNS use case, " Operator may make certificates only once in a while (as they cost), and at that point it is not certain that all IP addresses are known. They likely might now only know the current literal address, but the numeric address can change in the lifetime of the certificate Changing /etc/hosts is not possible, as this configuration is not supported for operators. " Still we feel configuration is a good thing, i.e., if one explicitly wants to allow a connection despite of warnings (i.e., has analysed the warning to be a false positive), that should still be acceptable, and not unilaterally bad. Also, one needs to be able to distinguish between “normal” network (open for everyone), and an operator-internal network: requirements for these two are different, and if one library is to serve both, it should be able to handle (=being configurable) both use cases. System configuration setup is anyway also done by a human, so if someone wants explicitly disable some checks for automated clients, it is logically similar to a human pressing some “acknowledge” button. And i don't think the browsers are going to remove it, at most they may move this option to settings. I think nobody wants a monolithic browser that cannot be tailored for user needs, which anyway cannot be anticipated by the browser maker. Whether it is interactive or configuration based does not matter as long as the configuration is there somehow. And the same logic applies also for LDAP ;) But then openLDAP or openSSL is already providing options to ignore some of the certificate errors, for example, i can set SSL verify call back function via LDAP options to ignore certificate CRL errors and continue the connection. So i still wonder why it is not possible in this case and feel it has to be user configurable. Regards, Sudhir, NOKIA
Hi, Reference to SOAP, where we have the option of SOAP_SSL_SKIP_HOST_CHECK https://www.genivia.com/doc/soapdoc2.html
Created attachment 678 [details] sudhirsingam-2018-05-06.patch
Works as per RFC defined behavior