[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
Thanks for getting back to us! Just to be sure, I also checked xenial and trusty, and the results are the same: ubuntu@xenial-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://xenial-ldap-start-tls-1835181.lxd/ -d -1 2>&1 | grep ^TLS TLS: hostname (xenial-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). ubuntu@xenial-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h xenial-ldap-start-tls-1835181.lxd -d -1 2>&1 | grep ^TLS TLS: hostname (xenial-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). ubuntu@xenial-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://ubuntu anonymous ubuntu@xenial-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h ubuntu anonymous Trusty is also fine: ubuntu@trusty-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://ubuntu anonymous ubuntu@trusty-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://trusty-ldap-start-tls-1835181.lxd ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ubuntu@trusty-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://trusty-ldap-start-tls-1835181.lxd -d -1 2>&1 | grep ^TLS TLS: hostname (trusty-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). ubuntu@trusty-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h ubuntu anonymous ubuntu@trusty-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h trusty-ldap-start-tls-1835181.lxd ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate ubuntu@trusty-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h trusty-ldap-start-tls-1835181.lxd -d -1 2>&1 | grep ^TLS TLS: hostname (trusty-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). ubuntu@trusty-ldap-start-tls-1835181:~$ Cheers! ** Changed in: openldap (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: Invalid Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
Thanks for all the debug effort! I've gone back and double-checked the code that was causing the failure, and at some point during the testing it had been changed so that the return from ldap_start_tls_s wasn't being checked (as it always returned true), and instead a check was being made against the presence of an OPENSSL context (which was always succeeding). I've reinstated the check and it responds as expected now. On that basis it looks like the issue was indeed resolved at some point since it was first reported (and isn't present in bionic). Happy to close. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: Incomplete Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
Same thing on bionic now. a) SSL with incorrect name fails as expected: ubuntu@bionic-ldap-start-tls-1835181:~$ sudo truncate -s 0 /var/log/syslog ubuntu@bionic-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://bionic-ldap-start-tls-1835181.lxd ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ubuntu@bionic-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://bionic-ldap-start-tls-1835181.lxd -d -1 2>&1 | grep ^TLS TLS: hostname (bionic-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). ubuntu@bionic-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 21:02:07 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1015 fd=14 ACCEPT from IP=10.0.100.234:45518 (IP=0.0.0.0:636) Jul 9 21:02:07 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1015 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 21:02:07 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1015 fd=14 closed (connection lost) Jul 9 21:02:13 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1016 fd=14 ACCEPT from IP=10.0.100.234:45520 (IP=0.0.0.0:636) Jul 9 21:02:13 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1016 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 21:02:13 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1016 fd=14 closed (connection lost) b) START_TLS with incorrect hostname fails as expected: ubuntu@bionic-ldap-start-tls-1835181:~$ sudo truncate -s 0 /var/log/syslog ubuntu@bionic-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h bionic-ldap-start-tls-1835181.lxd ldap_start_tls: Connect error (-11) additional info: TLS: hostname does not match CN in peer certificate ubuntu@bionic-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h bionic-ldap-start-tls-1835181.lxd -d -1 2>&1 | grep ^TLS TLS: hostname (bionic-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). ubuntu@bionic-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 21:03:01 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1017 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 21:03:01 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1017 op=1 UNBIND Jul 9 21:03:01 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1017 fd=14 closed Jul 9 21:03:09 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1018 fd=14 ACCEPT from IP=10.0.100.234:37820 (IP=0.0.0.0:389) Jul 9 21:03:09 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1018 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 21:03:09 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1018 op=0 STARTTLS Jul 9 21:03:09 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1018 op=0 RESULT oid= err=0 text= Jul 9 21:03:09 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1018 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 21:03:09 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1018 op=1 UNBIND Jul 9 21:03:09 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1018 fd=14 closed Now the good cases, to show the ssl setup is correct: a) SSL with ubuntu host: ubuntu@bionic-ldap-start-tls-1835181:~$ sudo truncate -s 0 /var/log/syslog ubuntu@bionic-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://ubuntu/ anonymous ubuntu@bionic-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 fd=14 ACCEPT from IP=10.0.100.234:45528 (IP=0.0.0.0:636) Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 op=0 BIND dn="" method=128 Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 op=0 RESULT tag=97 err=0 text= Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 op=1 WHOAMI Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 op=1 RESULT oid= err=0 text= Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 op=2 UNBIND Jul 9 21:03:48 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1019 fd=14 closed b) START_TLS with ubuntu host: ubuntu@bionic-ldap-start-tls-1835181:~$ sudo truncate -s 0 /var/log/syslog ubuntu@bionic-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h ubuntu anonymous ubuntu@bionic-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 21:04:14 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1020 op=0 STARTTLS Jul 9 21:04:14 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1020 op=0 RESULT oid= err=0 text= Jul 9 21:04:14 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1020 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 21:04:14 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1020 op=1 BIND dn="" method=128 Jul 9 21:04:14 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1020 op=1 RESULT tag=97 err=0 text= Jul 9 21:04:14 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1020 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jul 9 21:04:14 bionic-ldap-start-tls-1835181 slapd[2600]: conn=1020 op=2 WHOAMI Jul 9
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
I didn't have TLS_REQCERT set in /etc/ldap/ldap.conf during these tests, but the manpage says the value "demand" (equal to "hard") is the default in eoan at least. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: Incomplete Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
It seems to be working fine in eoan. I setup a CA and issued a server certificate, and setup openldap with ssl/start_tls. The hostname of the container: ubuntu@eoan-ldap-start-tls-1835181:~$ hostname -f eoan-ldap-start-tls-1835181.lxd ubuntu@eoan-ldap-start-tls-1835181:~$ ping -c 1 $(hostname -f) PING eoan-ldap-start-tls-1835181.lxd (10.0.100.137) 56(84) bytes of data. 64 bytes from ubuntu (10.0.100.137): icmp_seq=1 ttl=64 time=0.009 ms The certificate has a CN of "ubuntu", however, so I expect all ssl related connections to fail unless I use that name: ubuntu@eoan-ldap-start-tls-1835181:~$ openssl x509 -in /etc/ldap/ubuntu.pem -noout -subject subject=C = UK, ST = Some-State, O = Internet Widgits Pty Ltd, CN = ubuntu Via /etc/hosts, ubuntu points at the same ip as the hostname: ubuntu@eoan-ldap-start-tls-1835181:~$ ping -c 1 ubuntu PING ubuntu (10.0.100.137) 56(84) bytes of data. 64 bytes from ubuntu (10.0.100.137): icmp_seq=1 ttl=64 time=0.034 ms So let's begin! a) SSL with incorrect name fails as expected: ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://eoan-ldap-start-tls-1835181.lxd/ ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 20:39:30 eoan-ldap-start-tls-1835181 slapd[220]: conn=1002 fd=14 ACCEPT from IP=10.0.100.137:58498 (IP=0.0.0.0:636) Jul 9 20:39:30 eoan-ldap-start-tls-1835181 slapd[220]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 20:39:30 eoan-ldap-start-tls-1835181 slapd[220]: conn=1002 fd=14 closed (connection lost) Debugging shows: ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://eoan-ldap-start-tls-1835181.lxd/ -d -1 2>&1|grep ^TLS TLS: hostname (eoan-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). TLS: can't connect: (unknown error code). b) START TLS with incorrect name also fails as expected: ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h eoan-ldap-start-tls-1835181.lxd ldap_start_tls: Connect error (-11) additional info: (unknown error code) Note that the log confirms start tls was used: ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 fd=14 ACCEPT from IP=10.0.100.137:52990 (IP=0.0.0.0:389) Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 op=0 STARTTLS Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 op=0 RESULT oid= err=0 text= Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 fd=14 closed (connection lost) Debugging explains why, and it's the same reason: ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h eoan-ldap-start-tls-1835181.lxd -d -1 2>&1 | grep ^TLS TLS: hostname (eoan-ldap-start-tls-1835181.lxd) does not match common name in certificate (ubuntu). TLS: can't connect: (unknown error code). Now let's try the working case, by using "ubuntu" as the target hostname. a) SSL works fine: ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://ubuntu/ anonymous ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 fd=14 ACCEPT from IP=10.0.100.137:58524 (IP=0.0.0.0:636) Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=0 BIND dn="" method=128 Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=0 RESULT tag=97 err=0 text= Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=1 WHOAMI Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=1 RESULT oid= err=0 text= Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=2 UNBIND Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 fd=14 closed b) START_TLS too: ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h ubuntu anonymous ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=0 STARTTLS Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=0 RESULT oid= err=0 text= Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 fd=14 TLS established tls_ssf=256 ssf=256 Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=1 BIND dn="" method=128 Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=1 RESULT tag=97 err=0 text= Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.3 Jul 9 20:43:28 eoan-ldap-start-tls-1835181
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
I think it falls into the gaps between the various packaging approaches and distributions. >From the discussions with the OpenLDAP chaps, they were pretty confident that they couldn't replicate the issue with the package built against OpenSSL, plus there was some talk of issue being related to a GNUTLS bug that was resolved. So between the two the thread went dead at that end. To replicate, run up a code snipped that connects to a destination WITH AN INVALID CERT: ldap_initialize ldap_set_option (enumerate the various LDAP_OPT_X_TLS_REQUIRE_CERT values) if uri != ldaps: then ldap_start_tls_s ldap_sasl_bind_s The LDAPS connections fail as expected. The STARTTLS connections all succeed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: Incomplete Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
** Changed in: openldap (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: Incomplete Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
Apologies for misinterpreting this issue when initially triaging it - I have re-marked it as Security. I notice from your linked bug report that this was still happening with the upstream code as of September 2016 - but upstream did not appear to engage on the issue. Can you confirm whether this appears to be a Ubuntu (packaging or otherwise) specific issue or whether this is also affects upstream? If so, then this should be handled by upstream first and we can backport any fixes as appropriate. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: New Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: New Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
https://cwe.mitre.org/data/definitions/295.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: New Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
And just to add a real world example. If you use one of the dependent packages (apache, exim, squid, samaba, php, postress etc.) and use LDAP for your auth, then the SSL is worthless and anyone with access to the network can intercept and recover the credentials in the request/response. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: New Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
De nada: my pleasure. Just to make sure that the issue is clear though, it's worth spelling it out. The core of the issue is that in it's present form (and going back multiple distributions) the default configuration for connections using SSL via STARTTLS (which is the norm) does not check the validity of the server certificate at all. This means that the connection can simply be MITMed, then the contents accessed (sensitive authentication credentials etc). From my perspective, this kind of issue is actually worse than having no SSL at all, because no-one would use an unencrypted connection anywhere exposed, whereas people will now be deploying connections thinking the SSL is offering some form of protection, where as they are not. It's a false sense of security. Obviously all the packages that have this library as a dependency are insecure and vulnerable to interception too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: New Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835181] Re: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS
** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1835181 Title: OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and ldap:// with STARTTLS Status in openldap package in Ubuntu: New Bug description: This is the same bug as https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which has been closed. Tested and confirmed present with vivid, wily, xenial and bionic Also logged with openldap as http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think that this is a packaging issue caused by using GNUTLS rather than OpenSSL. Important: to replicate the issue you need to connect to an LDAP server which presents a certificate with a CN that DOES NOT MATCH the connection URI passed to the OpenLDAP client. In practice, this is simple enough to achieve by using the IP address of a server rather than the FQDN. The core of the issue is that the handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with an invalid certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK tryError: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK tryOK Based on all the documentation, the results should be the same between approaches. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
